RFC 3280 says: " In addition, legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name as an EmailAddress attribute. The attribute value for EmailAddress is of type IA5String to permit inclusion of the character '@', which is not part of the PrintableString character set. EmailAddress attribute values are not case sensitive (e.g., "[EMAIL PROTECTED]" is the same as "[EMAIL PROTECTED]").
Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted." Based on this, if the certificate is encoding an NAI as a name, then the subject alternative name field MUST be used. Simultaneous inclusion of the NAI within an EmailAddress attribute in the subject distinguished name is deprecated, but permitted. So in the case where an NAI is encoded in the subjectAltName field, the subject DN would be a duplicate, no? ---------------------------------------- > Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue > Date: Wed, 6 Jun 2007 16:37:08 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] > CC: > > I agree, my intent wasn't to mandate a DN, my text needs to be improved. > > > Does this help? > > "It is possible for more than one subjectAltName field to be present in > a peer or server certificate in addition to an empty or non-empty > subject distinguished name. EAP-TLS implementations SHOULD export all > the subjectAltName fields within Peer-Ids or Server-Ids. If the Subject > distinguished name is non-empty then it SHOULD be exported within the > Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are > considered valid. " > > Thanks, > > Joe > > > -----Original Message----- > > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 06, 2007 4:17 PM > > To: Joseph Salowey (jsalowey); Bernard Aboba; [email protected] > > Subject: RE: [Emu] Proposed Resolution to multiple > > Peer-Id/Server-Id Issue > > > > Your right, there can be only one distinguished name. > > > > However there are also cases where there are more than one > > subjectAltName may be present with a empty DN also; I don't > > think mandating a DN is a good idea since 3280 doesn't do that. > > > > Ryan > > > > > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 06, 2007 3:53 PM > > To: Bernard Aboba; [email protected] > > Subject: RE: [Emu] Proposed Resolution to multiple > > Peer-Id/Server-Id Issue > > > > Hi Bernard, > > > > I don't think a valid certificate can have multiple subject > > distinguished names. I think it would be more in line with > > RFC 3280 to treat the subject distinguished name as part of > > the valid name set if it is non-empty. > > > > "It is possible for more than one subjectAltName field to be > > present in a peer or server certificate in addition to a > > non-empty subject distinguished name. EAP-TLS > > implementations SHOULD export a non-empty Subject > > distinguished name along with all the subjectAltName fields > > within Peer-Ids or Server-Ids; all of the exported Peer-Ids > > and Server-Ids are considered valid. " > > > > Joe > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 05, 2007 10:05 PM > > > To: [email protected] > > > Subject: [Emu] Proposed Resolution to multiple > > Peer-Id/Server-Id Issue > > > > > > It has been pointed out that an EAP-TLS certificate can contain > > > multiple subject or subjectAltName fields. > > > > > > To address this, I propose that we add the following text > > to Section > > > 5.2: > > > > > > It is possible for more than one subjectAltName field to be > > present in > > > a peer or server certificate. Where more than one subjectAltName > > > field is present in a certificate, EAP-TLS implementations SHOULD > > > export all the subjectAltName fields within Peer-Ids or > > > Server-Ids; all of the exported Peer-Ids and > > > Server-Ids are considered valid. > > > > > > Similarly, if more than one subject field is present in a peer or > > > server certificate, and no subjectAltName field is present, then > > > EAP-TLS implementations SHOULD export all of the subject fields > > > within Peer-Ids and Server-Ids; all of the exported Peer-Ids and > > > Server-Ids are considered valid. > > > > > > > > > > _______________________________________________ > > Emu mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
