Re: [certid] CN-ID and name constraints

[Matt McCutchen <[e-mail]>]

On Sat, 2010-09-25 at 05:09 +0200, Martin Rex wrote: 
> Matt McCutchen wrote:
> > Matching a reference server name against a CN-ID that violates a dNSName
> > constraint defeats the purpose of name constraints.  With respect to
> > clients willing to do this, a name constraint is a security no-op.
> 
> No, it is not.  If there is anything wrong, then it is the
> server endpoint identification algorithm that is abusing X.509.
> 
> Name Constraints processing, as specified by PKIX, is NONE of the
> apps business.  Processing of name constraints is exclusively
> the task of the certificate path validation implementation
> within the PKI software, and the app doesn't need to know or
> care whether and which subtrees were collected while
> building the certification path and later processed during
> certificate path validation.

I was making an observation, not discussing blame or design.  Do you
deny the truth of the observation?

> 10 years ago, the use of CN-ID has been deprecated by rfc-2818 and
> been specified to not be used when DNSName SAN is present.

Unfortunately, CN-IDs are still widely used, and the browser vendors
have little power to push for their eradication.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=552346 .

> It seems like a bad idea to massively increase the complexity
> of a long deprecated server identification scheme, and in a
> fashion that is not only a magnitude more complex, but
> also amounts to a gruesome breach of the PKIX architecture.

Yes, this is a really ugly situation, but I think making name
constraints secure should be the first priority.

> I'm sorry for having totally missed the TLS&IETF consenus to abandon
> subjectAltNames for server-id-check and to resurrect CN-IDs.

That is not what is happening.  SANs have not been abandoned, and CN-IDs
have not been resurrected (they have been carried over from RFC 2818).

> There may not be an API in the PKI software for returning to
> the app the hierarchy of dNSName name constraints collected while
> composing the cert path and processed during cert path validation,
> which the app would need for a seconds constraints check
> when it decides to try a CN-ID matching fallback.
> 
> If doing DNSName constraints checking proactively during cert path
> validation should be allowed, then a REALLY big warning label
> would be necessary that CN AVAs must either contain a valid f.q.d.n
> or be ABSENT from the server cert subject DName to prevent false
> negatives (i.e. name constraints violation errors) in those
> new TLS implementations that adopt this fancy logic.

Or the server cert can include a dNSName SAN.  In that case, the CN is
not constrained because it is not used for matching anyway.

> > > NSS now enforces name constraints on the CN-ID
> > > (https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains
> > > backward compatible with the web by virtue of the fact that the public
> > > CAs aren't using name constraints yet.  If the CAs start doing so, all
> > > an inferior CA has to do for things to work is to include a dNSName SAN,
> > > which is a SHOULD anyway.
> 
> I think it would be more sensible to let CN-IDs rest in peace and
> simply skip the CN-ID matching fallback entirely if the CA cert,
> which signed the server cert, contains a name constraints extension.

That's another fine approach, though the NSS behavior has the advantage
of making it possible to cross-certify an existing CA that uses CN-IDs
and apply name constraints, which is a huge win for me.  I deal with
several organizational CAs that I don't want to trust for the entire web
but would gladly cross-certify for their own domains, and currently I am
adding a certificate exception for each server after manual
verification, which is a huge PITA.

So there are four viable approaches:

0. Don't use the CN-ID.
1. Use the CN-ID only if there are no name constraints.
2. Use the CN-ID only if it satisfies the name constraints (if any).
3. Have certificate validation apply name constraints to the CN unless
there are dNSName SANs or it has some other reason to believe that the
CN will not be used as a CN-ID.  (Implemented in NSS.)

#0 is incompatible with much of today's web.  #1 and #2 require the
server ID check to know about name constraints.  #3 risks rejecting
certificates that contain no dNSName SAN and a CN that was not intended
as a CN-ID.

I propose that section 4.4.4 be changed as follows:

Old: "...the client MAY as a fallback check for a string whose form
matches that of a fully-qualified DNS domain name in the CN-ID."

New: "...the client MAY as a fallback check for a string whose form
matches that of a fully-qualified DNS domain name in the CN-ID, provided
that this domain name satisfies any name constraints on the
certification path as defined by [PKIX] section 4.2.1.10."

On a tangent, I'm unhappy with the idea that the server ID check should
be separate from certificate validation, or even implemented in the
application rather than the TLS library.  Applications will screw it up;
I'd rather the TLS library get it right once and provide an API that
accepts the list of reference identifiers and any other flags necessary
to address the needs of applications.  And combining the server ID check
with certificate validation makes it possible (if desired) to apply name
constraints only to the presented identifier that is actually used,
which could be useful in some cross-certification scenarios.

-- 
Matt