Subject: Re: [certid] Name constraints and legacy clients

From: Matt McCutchen <[email-masked]>
Date: Sun, 03 Oct 2010 22:50:11 -0400

On Fri, 2010-07-16 at 12:02 -0600, Paul Tiemann wrote:
> On the topic of name constraints: What if there are ways to push Name
> Constraints forward without necessarily having to wait for all legacy
> clients to die and all the niche clients to become compatible?  Here's
> one idea (admittedly not past v0.1 in my head)
> 
> 1) Have the major browser vendors add a small mechanism to detect
> certificates with Name Constraint violations, and give them a central,
> automated way to "report" a certificate found with violated name
> constraints which might pose a risk for all the non-compliant browsers
> and clients.  With something like that in place, the major browsers
> will be able to handle name constraints correctly, and the constraints
> policing feature would help to erase the incentive that the operator
> of a constrained CA certificate would have for violating the
> constraints to trick legacy devices.  
> 2) NetCraft could possibly help with Name Constraints monitoring, at
> least for the public internet.

And at this point it becomes safe to give someone we don't fully trust a
name-constrained intermediate certificate?  I'm skeptical.  An attacker
may be able to target some subset of legacy clients with a false
certificate (by source IP address or ClientHello content) without ever
sending the certificate to a violation-reporting client and thereby
evade detection.

Another approach is to have name-constrained intermediate certificates
include a critical extension that means "name constraints must be
applied to the CN-ID".  EE certificates under such an intermediate
certificate will only be accepted by clients that properly enforce the
name constraints.  An organization could use a name-constrained
intermediate certificate for servers that don't need to support legacy
clients and get a certificate directly from a public CA for servers that
do.  I previously proposed this here:

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 03 Oct 2010 22:50:59 -0400

> do.  I previously proposed this here:

Sorry.

https://bugzilla.mozilla.org/show_bug.cgi?id=554442

-- 
Matt

---

From: Paul Tiemann <[email-masked]>
Date: Mon, 4 Oct 2010 07:45:48 -0600

> sending the certificate to a violation-reporting client and thereby

Here's my cue to admit that I didn't think too long about that kind of risk before sending it out.  

Just to be clear about my intent: DigiCert hasn't ever issued an intermediate cert to an external entity, and we've never yet had any interest in issuing name-constrained intermediate certs either.  "Trust is good, but control is better."  This was just part of a thread where Name Constraints were being discussed, and I thought I'd go ahead and toss out some ideas about Name Constraints while I was at it. 

> https://bugzilla.mozilla.org/show_bug.cgi?id=554442

Hmm, my guess is that there won't be enough demand for an intermediate cert that causes all legacy browsers to choke.  (Not enough demand for a CA to want to build it is what I'm guessing...)

Paul Tiemann
CTO, DigiCert