Re: [certid] Need to define "most specific RDN"

[Martin Rex <[e-mail]>]

Kaspar Brand wrote:
> 
> On 14.07.2010 17:47, Nelson B Bolyard wrote:
> > 
> > SANs solve this whole problem.  They have a component that may ONLY contain
> > DNS names, and therefore is easily constrained.  DNS name constraints would
> > be effective if certs ONLY put DNS names into SANs.
> 
> That's an argument for completely banning CN-IDs, in the first place.
> But I fail to see how it is relevant for the decision whether to only
> check the "(most specific) Common Name field" or all of the CNs.

In the PKIX specs implementing name constraints for DNames is a MUST,
while implementation of DNSName SANs officially "RECOMMENDED" and
in reality probably a MAY.


> 
> > But putting DNS names
> > into SANs effectively bypasses name constraints (at least, in
> > implementations I tested last year).
>
> Should read "... into CNs", I guess?

AFAIK, Name constraints conceptually are supposed to work at the certificate
path validation level.  So a name constraint imposed by a rootCA for an
intermediate CA works for exactly that particular type of name.

If applications check for acceptable names in certs by comparing with
different types of names (like DNSName SAN and CN-ID), then a name
constraint on only one of them is obviously ineffective from preventing
the intermediate CA to bypass the name constraint.


> 
>                                       In any case, if you disregard CNs
> in the subject for name matching as soon as there is a subjectAltName
> extension with at least one dNSName (as
> draft-saintandre-tls-server-id-check-08 does), then it's becoming a
> non-issue.

I don't think this is an appropriate characterization of the issues
at hand.  There are a number of parties involved, each with
very different objectives.


Name constraints is tool for a multi-CA hierarchy that a CA higher up
the hierarchy can use to impose limits to the authority of CAs closer
to or issuing the EE certs.

name constraints are not in the interest of the server, not in the
interest of the client and not necessarily in the interest of the
issuing CA (the presencs of name constraints is evidence that
it is not in the interest of the issuing CA -- but instead in the
interest of the higher up CA).

The inclusion of DNSName SANs or CN-IDs in a Servers EE-Cert might be
in the interest of the Server, might be in the interest of the issuing CA
or might be a mere technical restriction of the CA's software or the
CA's configuration.

A Server that intentionally uses an EE-Cert with DNSName SANs has no
control over the clients that connect to that server.  Whether these
clients understand DNSName SANs or only CN-IDs, or whether these
clients ignore CN-IDs when DNSName SANs are present or always check
both, is also completely outside of the control of the server.

The server and the issuing CA might consent to not put a CN-ID into
the server's EE-Cert, but that is likely result is a number of clients
rejecting the server's cert.

> 
> > IMO, we should be attempting to drive a stake in the heart of DNS names in
> > subject CNs, and moving all CAs to use SANs exclusively for DNS names.

That decision, and the risk management for the resulting interop problems,
should be left to the combined decision of the Server operator and
issuing CA to no longer include CN-IDs in EE-Certs on a case-by-case
basis.

> 
> -08 already does this in several places:
> 
>        The certificate SHOULD NOT represent the server's fully-qualified
>        DNS domain name in a CN-ID, even though many deployed clients
>        still check for this legacy identifier configuration within
>        certificate subjectName. [...]
> 
>       Notwithstanding any of the foregoing rules, reference identifiers
>       of type CN-ID (if included) MUST always be the lowest-priority
>       reference identifiers in the list. [...]

It has been recently asked (I think by Paul Hoffman) why there is
an ordering when checking is going to be performed as a linear search,
and similarly I'm wondering what "lowest-priority reference identifiers"
is supposed to mean here.

I assumed the matching was about a Boolean decision, either it matches
the servers identity or it doesn't match.  "lowest-priority" sounds
like a XX% acceptable match instead of a Boolean.  

> 
>       Security Note: A client MUST NOT seek a match for a reference
>       identifier of CN-ID if the presented identifiers include an
>       SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
>       entry types supported by the client.

This MUST NOT is an unnecessary a violation of rfc-2119 section 6,
and completely ignorant of the situation that software updates must
not break the installed base.


It is trivial for the server&CA to make this happen by having the
CA issue a Cert without CN-ID.  


-Martin