> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Monday, June 11, 2007 10:54 PM > To: [email protected] > Subject: RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates > > > > > 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). >
[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. > 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]. > [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." > 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 protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
