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 _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
