I'd like to try to up-level some of the discussions we're having about name constraints, to see if we can find some higher-level consensus.
The thing that was driving my earlier proposal with regard to name constraints was a feeling of imbalance. With every CA we add to our program we add risk for every site on the web. That cost is supposed to be offset by the benefit that a CA provides in terms of adding security for its subscriber sites. But when a CA exists to serve only a small slice of the web, this equation seems unbalanced. Small CAs are a bad risk/reward trade-off. One way to balance this equation better is to scope the risk to the scope of the CA. If a CA is only serving a small slice of the web, then they should only be able to harm a small slice of the web. A CA should only be able to harm the entire web if it's providing benefit to a significant part of it. I wonder if we can agree on this general point -- That it would be beneficial to the PKI if we could create a mechanism by which CAs could disclose the scope of their operations, so that relying parties could recognize when the CA makes a mistake or a compromise that goes outside that scope, and prevent harm being done. I think of this as CA scope transparency. Not constraining what the CAs do, but asking them to be transparent about what they do. That way if they do something they said they don't do, we can recognize it and reject it proactively. Obviously, this mechanism would have to be flexible. To the degree that it's based on information being provided to running browser instances, that information has to propagate quickly. Based on our experience with things like CRLsets and OneCRL, I think that's possible. With our migration to SalesForce for CA interactions, it's easy to imagine a mostly automated path from CA-provided information to information pushed out to browsers. Update your CA's SalesForce records with some new scope, and it gets picked up The hard problem is how to define "scope". We've taken a couple of stabs at using name constraints as one definition of scope. I still have some hope that if we can get the adaptability right, this might be viable, but clearly it's not going to match well for all cases. I honestly don't have much in the way of other ideas. Suggestions welcome. If we get this right, I think it could actually make the PKI work better. If we can ensure that small CAs present small risks, then it could make it easier for new CAs to get started. If we can adapt these protections as CAs change, it will provided a smoother path for CAs to grow. It may be that there's not a technical framework that can accurately and flexibly capture the type of risk reduction I'm talking about here. But it seems worth trying to figure out what the requirements are here, and seeing if it's possible to meet them or not. Thanks, --Richard _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
