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