Hello certid, In sections 3.8, 4.2.4, and in Appendix A.3 section 3.1.3 , reference is made to > the "leaf" (left-most) position within the Relative Distinguished Names > (RDNs) of the subjectName I would like to comment on that terminology, and suggest different terminology.
I am the chief SSL developer for NSS, the crypto libraries used in Mozilla products (Firefox, Thunderbird), and before that, Netscape products. I have been an NSS SSL developer for 13 years. In that time I have seen numerous problems with CAs issuing certs with RDNs in the "wrong order". There are (or have been, during my career) MANY CAs that do not understand that RDNs describe a path through a hierarchy, and that the order of the RDNs, AS ENCODED IN THE CERTIFICATE, is from "most general" to "most specific". The various standards for translating a DER encoded Name into a string call for the RDNs to be ordered, left to right, from most specific to most general, the reverse of the order in which they appear in the DER encoded certificate. But sadly there are a number of popularly used programs that do not conform, and translate between DER and string form (in both directions) without reversing the order. This contributes to the problem of CAs putting CNs in the wrong places or wrong orders. So, I suggest that this document not specify the CN's position among the RDNs by its position in the string form, but rather by its position in the DER encoded form in the certificate. I suggest that the document state that it must be the LAST of the CNs within the RDNs, as those RDNs are found in the DER encoded Name in the certificate. It may be useful for the document to explain, in an appendix, that the order in which the RDNs appear in string form is supposed to be the reverse of the order in which they are found in the DER encoded Name form in the certificate, and that consequently, when seen in string form, the CN should be the first (left-most) CN found in the RDNs. But I'd add that as informative text, not normative. Also, Please add an additional sentence to section 4.2.4 saying: A client MUST NOT check the Common Name if the identity set includes any subjectAltName extension of type dNSName, SRVName, uniformResourceIdentifier (or other application-specific subjectAltName extensions). This may seem redundant, given the first sentence of 4.2.4, but there are many developers who will ignore any statement that does not say MUST or MUST NOT. Hopefully, the sentence I suggest above makes it clear. Thanks for your consideration. Please reply to the list. /Nelson Bolyard _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
