Ok the text below seems to mandate rfc822 SubjectAltName in all cases.
How about just removing the reference to the emailAddress RDN from that
paragraph.  Perhaps replacing it by:

"If subject naming information is present only in the subject name field
and the peer identity represents a host or device the subject name field
SHOULD contain a CN RDN or serialNumber RDN.  It is RECOMMENDED that
when the peer identity represents a user the Subject distinguished name
should not contain an emailAddress RDN, but rather use the rfc822
SubjectAltName as described above." 

Joe


> -----Original Message-----
> From: Bernard Aboba [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 07, 2007 10:48 AM
> To: Joseph Salowey (jsalowey); [email protected]
> Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
> 
> Right.  The RFC 3280 statement only applies to RFC 822 names. 
>  That's why I think that the text should focus on those names. 
> 
> > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS 
> certificates
> > Date: Thu, 7 Jun 2007 08:57:49 -0700
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]; [email protected]
> > 
> > Not all identities are an RFC822 Name so using an RFC822 
> name is not 
> > always appropriate. If you are going to include an RFC822 
> name in the 
> > certificate then it should be in the RFC822 SubjecAltName. 
> The Subject 
> > distinguished name may include other name elements.
> > 
> > > -----Original Message-----
> > > From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, June 07, 2007 7:54 AM
> > > To: [email protected]
> > > Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
> > > 
> > > 
> > > RFC 3280 Section 4.1.2.6 says:
> > > 
> > > 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.
> > > 
> > > This leads me to believe that the statement below from 
> Section 5.2 
> > > isn't quite right:
> > > 
> > > "Although the use of the subject name field is existing practice, 
> > > its use in EAP-TLS is deprecated and Certification 
> Authorities are 
> > > encouraged to use the subjectAltName field instead. "
> > > 
> > > An RFC 3280-equivalent statement would be:
> > > 
> > > 
> > > _______________________________________________
> > > Emu mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/emu
> > > 
> 
> 

_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu

Reply via email to