Re: [certid] Comments on draft-saintandre-tls-server-id-check-03

[Peter Saint-Andre <[e-mail]>]

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/