Re: [certid] Name constraints and legacy clients

[Matt McCutchen <[e-mail]>]

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