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

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Jun 2007 22:54:23 -0700

> > This looks ok.  I think the analog for the server side is as follows:
> >  
> > "If subject naming information is present only in the subject 
> > name field of a server certificate, then the subject name 
> > field MUST contain a CN RDN or serialNumber RDN."
> >  
> [Joe] Should this be 'MUST' or 'SHOULD'?

Are there alternatives to the CN or serialNumber RDN?  If so, then it probably should be a 'SHOULD'.  

> > > 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."
> > 
> > Are we saying that the Subject DN should contain something 
> > other than an emailAddress RDN, or are we saying that it 
> > should not be present at all? 
> >  
> > The analog of the RFC 3280 language would appear to be the following:
> >  
> > "Conforming implementations generating new certificates with 
> > network access identifiers MUST use the rfc822Name in the 
> > subject alternative name field to describe such identities.  
> > The use of the subject name field to contain an emailAddress 
> > RDN is deprecated, and MUST NOT be used."
> >  
> > This says that new certificates utilizing rfc822Names always 
> > use the subjectAltName field, rather than the subject DN. 
> > 
> [Joe] OK this is for NAI.  How about adding a sentence for non NAI
> identities.  
> 
> "The subject name field MAY contain RDNs for representing non-NAI
> identities."  

I think this raises the question of what a "non-NAI" identity is.  Would this be an identity not expressible in the NAI syntax defined in RFC 4282?   I ask because a serialNumber RDN might well be expressable within the NAI syntax (e.g. if it only contains numbers, but no realm, that would be a valid NAI).  

How about this? 

   Conforming implementations generating new certificates
   with network access identifiers MUST use the rfc822Name in the
   subject alternative name field to describe such identities.  The use
   of the subject name field to contain an emailAddress RDN is
   deprecated, and MUST NOT be used.  The subject name field
   MAY contain RDNs for representing identities not expressible
   using the NAI syntax defined in [RFC4282]. 

   Where it is non-empty, the subject name field MUST contain an X.500
   distinguished name (DN).  If subject naming information is present
   only in the subject name field of a peer certificate and the peer
   identity represents a host or device the subject name field SHOULD
   contain a CN RDN or serialNumber RDN.  If subject naming information
   is present only in the subject name field of a server certificate,
   then the subject name field SHOULD contain a CN RDN or serialNumber
   RDN.

   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.

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 12 Jun 2007 11:53:06 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, June 11, 2007 10:54 PM
> To: [email-masked]
> Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates
> 
> 
> > > "If subject naming information is present only in the 
> subject name 
> > > field of a server certificate, then the subject name field MUST 
> > > contain a CN RDN or serialNumber RDN."
> > >  
> > > Are we saying that the Subject DN should contain something other 
> > > than an emailAddress RDN, or are we saying that it should not be 
> > > present at all?
> > >  
> > > "Conforming implementations generating new certificates 
> with network 
> > > access identifiers MUST use the rfc822Name in the subject 
> > > alternative name field to describe such identities.
> > > The use of the subject name field to contain an 
> emailAddress RDN is 
> > > deprecated, and MUST NOT be used."
> > >  
> > > This says that new certificates utilizing rfc822Names 
> always use the 
> > > subjectAltName field, rather than the subject DN.
> > > 
> I think this raises the question of what a "non-NAI" identity 
> is.  Would this be an identity not expressible in the NAI 
> syntax defined in RFC 4282?   I ask because a serialNumber 
> RDN might well be expressable within the NAI syntax (e.g. if 
> it only contains numbers, but no realm, that would be a valid NAI).  
> 

[Joe] An NAI represents a specific type of identity. A certificate may
contain other types of identities that may not be NAIs.  Just because it
fits a particular format does not mean that it is an NAI. 

>    using the NAI syntax defined in [RFC4282]. 
[Joe] I think the main issue is emailAddress should not be used and
anything that you would put in the emailAddress RDN should go in the
SubjectaltName of type rfc822Name instead.  Other parts of the subject
name should be allowed.  

"The subject name field MAY contain other RDNs for representing the
subject's identity."