> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 07, 2007 7:40 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Cc: [EMAIL PROTECTED] > Subject: RE: [Emu] Proposed Resolution to multiple > Peer-Id/Server-Id Issue > > > 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? > [Joe] No, the EmailAddress RDN may not be included in the Subject DN.
> > > > > ---------------------------------------- > > 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]; > emu@ietf.org > > 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; emu@ietf.org > > > 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; emu@ietf.org > > > 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: emu@ietf.org > > > > 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 > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
