Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2007 10:47:59 -0700

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-masked]> To: [email-masked]; [email-masked]> > 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-masked]] > > Sent: Thursday, June 07, 2007 7:54 AM> > To: [email-masked]> > 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:> > > > "Conforming implementations generating new certificates with > > network access identifiers MUST use the rfc822Name in the > > subject alternative name field to describe such identities."> > _______________________________________________> > Emu mailing list> > [email-masked]> > https://www1.ietf.org/mailman/listinfo/emu> > 

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 7 Jun 2007 14:59:23 -0700

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-masked]] 
> Sent: Thursday, June 07, 2007 10:48 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> 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-masked]
> > To: [email-masked]; [email-masked]
> > 
> > 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-masked]]
> > > Sent: Thursday, June 07, 2007 7:54 AM
> > > To: [email-masked]
> > > 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:
> > > 
> > >