> > 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 protected] https://www1.ietf.org/mailman/listinfo/emu
