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?

> > > Go kick the PKIX folks if you don't like how it is spec'ed,
> > > but leave the apps folks alone.  I believe that asking the apps
> > > folks to regurgitate and re-chew stuff that the PKIX part didn't
> > > process to someone's satisfaction is an _extremely_ bad idea.
> > 
> > server-id-check is built on PKIX, not vice versa, so server-id-check is
> > responsible for the security consequences of the CN-ID that it defines
> > for the name constraints defined by PKIX.  It has the option to solve
> > the problem or say "this breaks the security of name constraints and we
> > know it", which would be laughable for a standard.
> 
> 
> 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.
> 
> 
> I'm sorry for having totally missed the TLS&IETF consenus to abandon
> subjectAltNames for server-id-check and to resurrect CN-IDs.
> 
> 
> 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 option, though it has the same problem 

-- 
Matt