On 4/3/10 11:53 AM, Nelson B Bolyard wrote: > 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.
Done in my working copy. > 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. Added in my working copy. Thanks for the feedback. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
