You have a lot of ideas in here, Richard! Asking the question "what is the increased risk we face by introducing new CA's and new roots into the trust store?" is a good idea. How we go about answering that gets tricky. It might be helpful to articulate some threat models facing CA's, both governmental and commercial, big and small. A few that come to mind:
1) Externally-driven attack on a CA's internal network and systems. 2) Internal mis-management of the CA's network and systems (e.g. firewall settings, software configs, credentials, etc.). 3) Physical breach of the CA's offices and/or data centers. 4) Bad actors within the CA who have malicious intent (or maybe just don't care). 5) Someone within the CA who makes a simple (or not-so-simple) mistake. 6) Legal statutes or authoritarian dictates which obligate a CA to perform bad acts. 7) As Moudrick mentioned, a CA might seek legislation that provides some sort of legal cover for bad acts they are committing. 8) Coercion between CA's to issue certs that one might not be able to do itself for some reason. I imagine others exist so I hope people will feel free to add or otherwise comment on them. But in terms of risk, it's a question of what tools and mechanisms are available to us that help prevent, detect, mitigate these various situations. Some CA's will raise more concerns in one area than a different CA will, so it might be necessary to consider these on a per-organization basis instead of coming up with different categories. But maybe it's helpful to have the categories anyway if for no other reason than to guide these discussions? In terms of the tools available, the ones I can think of are: audits (of course), other public declarations/disclosures, technical constraints in the certs, certificate transparency, key pinning (maybe?), domain validation (maybe)? To your specific question of defining scope, I think it's a combination of the following: - relative size of the CA (number of roots, number of active certs, expected size of the customer base, ???) - affiliations with government bodies - affiliations with domain name registrars - affiliations with Internet infrastructure operators (which needs refinement in terms of what that means) There are probably others so again I hope people will add to that list. But I agree that our ability to identify or quantify or characterize the above will help us decide which threats are of greatest concern. From there we should be able to identify constraints we want to impose that provides the right balance. I'll leave it here for now. I look forward to continuing this discussion. Original Message From: Richard Barnes Sent: Thursday, June 4, 2015 1:44 PM 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
