SSL certificate verification: "most specific"

[David Fifield <david () bamsoftware com>]

Hi,

I just committed some new code and tests for Ncat SSL certificate
verification. The code had been lax with respect to this paragraph from
RFC 2818:

    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. Although
    the use of the Common Name is existing practice, it is deprecated
    and Certification Authorities are encouraged to use the dNSName
    instead.

Ncat used to check the Common Name even if there were dNSNames and none
of them matched, and it would match against the first Common Name that
appeared in the certificate, not the "most specific" one. These are now
both fixed.

The "most specific" terminology is a problem. It's used in several
standards, but I haven't been able to find a definition of it anywhere.
I implemented code that follows this definition, which I think is
reasonable:
    Wildcard patterns are always less specific than non-wildcard
    patterns. If both patterns are wildcard or both are non-wildcard,
    the one with more name components is more specific. If two names
    have the same number of components, the one that comes later in the
    certificate is more specific.
The reason later patterns are preferred is that I remember reading
somewhere that names are supposed to be arranged in order of increasing
specificity, but I can't remember where I saw that.

Here's an example from the test program. If a certificate contains these
Common Names in this order,
    a.com
    *.b.com
    sub.c.com
    sub.d.com
    *.sub.e.com
    *.sub.f.com
    sub.sub.g.com
they would be, from most specific to least specific,
    sub.sub.g.com
    sub.d.com
    sub.c.com
    a.com
    *.sub.f.com
    *.sub.e.com
    *.b.com

Comments on this are welcome.

It should be noted that RFC 2818 is not the only place that defines how
the data in a certificate are to be interpreted. For instance, some
protocols disallow wildcards entirely. I believe this behavior is mostly
correct for HTTPS, but it won't be for all protocols. By "mostly
correct" here I mean it's correct in every respect except where we have
chosen to be more strict.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/