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

[Nelson B Bolyard <[e-mail]>]

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