Re: [certid] Name constraints and legacy clients

[Paul Tiemann <[e-mail]>]

On Oct 3, 2010, at 8:50 PM, Matt McCutchen wrote:

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

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. 

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