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

[Martin Rex <[e-mail]>]

Nelson B Bolyard wrote:
> 
> On 2010/05/31 08:18 PDT, Martin Rex wrote:
> 
> > While there have been few implementations checking for multiple
> > CN= parts, the guideline in rfc-2818 for subjectAltNames seems
> > to be much clearer, that there can be more than one, and more
> > than one needs to be checked.
> 
> That is precisely what it says NOT to do.  It says
> 
> >    If a subjectAltName extension of type dNSName is present, that MUST
> >    be used as the identity. Otherwise, the (most specific) Common Name
> >    field in the Subject field of the certificate MUST be used.
> 
> The phrease "the (most specific) Common Name field in the subject field"
> is not plural.  There is at most one Common Name attribute in the name
> that is *the* most specific one.  The words "most specific" refer to its
> position in the list of RDNs, which are arranged (as encoded in the
> certificate Name field) from most general (first) to most specific
> (last).  So, the most specific Common Name is the last of the Common
> Name attributes in the sequence of RDNs, as encoded in the certificate.


I am perfectly well aware of the wording in rfc-2818.

But security-wise an X.509 Cert containing

  CN=host1.example.com, CN=host2.example.com, CN=host3.example.com

is significantly less dangerous that an X.509 Cert containing

  CN=*.example.com

and therefore this wording in rfc-2818 is unreasonable in several
aspects and I chose to completely and deliberately ignore it in my
implementation.

Btw. I did not understand the meaning of "most specific" anyway,
so I considered it unlikely that this could be interoperably
implement by only matching a single CN= entry.  While the initial
definition of distinguished names might have had a hierarchical
directory structure in mind, one does find distinguished names
in "unusal" ordering out there, as well as distinguished names
entirely without country AVA, even ones with only CN=


-Martin