Re: [certid] CN-ID and name constraints

[Matt McCutchen <[e-mail]>]

On Fri, 2010-09-24 at 04:39 +0200, Martin Rex wrote:
> Matt McCutchen wrote:
> > 
> > > A CA with name constraints for DNSName SANs (required critical according
> > > to rfc5280, mind you) in its own CA certificate that issues TLS server
> > > certificates without dNSName SANs yields "fubar" on my scorecard.
> > 
> > But if by doing that they can issue certificates that clients will
> > accept for server names the superior CA did not intend, that's a big
> > security problem.
> 
> No, there is absolutely no security problem involved.
> 
> This is a plain and simple liability issue.  If the superior CA
> can not manage the risk appropriately so that the issuing CA will
> not do this, then either the superior CA MUST NOT certify that
> issuing CA, or the clients MUST NOT trust the superior CA.

Name constraints are designed to support secure delegation of the
ability to issue certificates for a portion of the namespace.  Why
wouldn't CAs use them for that purpose?  Just because you said so?

A certificate that violates a name constraint is invalid, and under any
sane contract or legal system, the superior CA will not be liable to
anyone who relies on an invalid certificate.

> Btw. is it completely ridiculous to put Constraints into
> certificates for a resource that is managed aribraritly on a
> first-come, first-served basis such as DNS hostnames and
> think of it as a security feature.

What exact use case do you speak of?  The typical use case is to give
the owner of a DNS zone the ability to issue certificates for names
within that zone that will validate for the duration of the ownership.

> What some entirely fail to understand is that this is about
> a backwards compatibility issue with the installed base,
> and no amount of praying, cursing and issuing of new Specs with
> MUST NOTs in them will change the behaviour of the installed base
> in any way or form.
> 
> New specs affect only new stuff (implementations and CAs),
> and to a very limited amount patches into the installed base,
> under the condition that the change DOES NOT BREAK existing
> productive usage scenarios.

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.

In general, IETF seeks to make the features that it introduces work as
intended.  So it makes complete sense to me that secure handling of name
constraints would be a condition of conformance to the server-id-check
standard.  Old clients that take a useless interpretation of name
constraints can continue to exist, they just can't claim conformance to
the standard, and that's their problem.

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.

> NameConstraints are ill-designed to support what some people
> intend to do with them.

In what way are they ill-designed to support secure delegation of the
ability to issue certificates for a portion of the namespace?

> They're specify to constrain only
> name components that are present, not name components that
> are absent.

What do you mean?

> 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.

> As far as Joe Average User is concerned, which of the CAs shipping
> in current Browsers does have the alleged security problem anyway?

None; obviously the CAs won't use a feature that presents a security
problem.  The relevant question is whether they would start using it if
the problem were solved, and that I can't answer.  Those that charge for
each end-entity certificate would certainly charge through the roof to
delegate an entire domain.

> The way they're specified, NameConstraints are not a security feature,
> but rather a means to enforce a business model, because NameConstraints
> can no longer securely if there is more than one trust anchor.
> TLS as used on the internet is approaching 100 seperate trust anchors...

No.  All name constraints do is constrain sub-CAs, and they are secure
for that purpose.  PKIX assumes you trust your trust anchors.  If you
don't, that's a problem that has to be solved by other means.
 
> > The idea is that by including a dNSName SAN, the CA opts out of the
> > backward compatibility.  I don't think anyone issues certificates with
> > both dNSName SAN and CN with the intent that the CN be honored as a
> > server name.
> 
> Well no, this is another absolute nonsense, because again it
> completely ignores the (behaviour of) the installed base.
> The only way to opt out of CN-ID matching is to issue server
> certs entirely without CN AVAs in the subject name.
> Anything else than CN=f.q.d.n or NO CN AVA is non-sensical.

I'm not sure what installed base you are talking about, but the
interpretation I described is stated in RFC 2818 and followed by all
major browsers.  server-id-check is right to choose it.  But this is a
separate issue from name constraints on the CN-ID.

> I'm not aware of a reasonable justification for the existance
> of PolicyConstraints and NameConstraints in certificates other
> than governmental agencies and military would like to use it
> eventually and still be able to procure on the commodity market.

I gave one above.  A public CAs can give a DNS zone owner the ability to
issue certificates within the zone without posing a risk to anyone else.

-- 
Matt