Ian G wrote:
IMHO, the policy has served remarkably well, and of course issues will arise with more experience.
I wouldn't go so far as to say "the policy has served remarkably well". However I think it has served as a useful document in terms of providing a context for our discussions, has helped in surfacing some long-standing CA-related issues, and has I think shed more light on what for many years was sort of a overlooked part of the overall Internet/web infrastructure.
One way to short-circuit this is to simply state that the root CA is responsible for any/all subroots. So this would imply that the root CA's policies and audit drill down through the subroots, and they apply. Then, it would be up to the root auditor to decide whether a subroot needed a separate audit or not.
I think this approach would be good if we were starting from a greenfield environment. However I think in the current CA environment we're faced with a situation where in practice roots don't necessarily always accept direct responsibility for the actions of their subordinates (or for those of other root CAs that they've issued cross certificates for). From a practical standpoint the issuance of subordinate CA certificates or cross certificates has been seen as more of a technical issue: "A needs to treat B as a subordinate CA because B wants/needs to take advantage of A's inclusion in IE/Firefox/etc."
This predominant attitude toward subordinates is a defect to be sure. The question is, to what extent (and in what circumstances) is it a security-relevant defect.
One problem with this is that it might also not be realistic. Consider two CAs, one of which does "style A" and another does "style B". In the doco and audit for the root CA, there will be a need somehow to capture that distinction. The natural direction here will end up that the root's policies will tend to say "see the subroot's policies for more detail."
Right, and that's a quite common situation: There will be a root CA that really acts just as a convenient "gathering point" for a bunch of different subordinates to get CA certs from, with the root's policies just having to do with subordinates, and every relevant to end-entity certs pushed down to the subordinate CAs. This is the model for a lot of government-sponsored PKIs where the PKI is not just government-specific but serves as an unmbrella for commercial and nonprofit groups to set up their own CAs under the government-operated and-authorized root.
Either way we look at it, I feel that the more controls are put in place, the more we end up putting in "paper fixes" and the more we complicate things for a gain that we don't fully understand.
Yes, and I'm going to use your comment as a jumping off point for a broader comment:
We have traditionally treated CA inclusion as a security issue, with the purpose of evaluating CAs for inclusion to ensure that we didn't suffer major security vulnerabilities due to CA actions or omissions. However I could also make the case that the CA is less like the other security-related stuff we do (e.g., security testing, fixing reported vulnerabilities in the code, etc.) and more like what we've been doing in the licensing/copyright area.
I think there's general agreement that browser exploits are a "clear and present danger", and it's worth our spending whatever time it takes to make sure they're fixed as expeditiously as possible. Over on the legal/licensing/copyright front, there are certainly bad things that could happen to us, like getting code in the tree that was not authorized by the creator, getting code in that was under an incompatible license, and so on. Based on our experience and judgment over time, we've deemed it adequate to set up some safeguards in place: having formal license policies and a formal committers agreement, having people vouch for others seeking commit access, and so on. However we haven't gone overboard with double- and triple-checking everyone who contributes code, vetting every single code contribution for legal issues, and so on. This would greatly raise the bar to getting code contributions from people, and we just don't see that as being justified based on experience and the perceived risks.
So, which is the better model for including CAs? I'm beginning to think that the licensing/copyright situation is perhaps a better model for us: set up a documented framework, perform some reasonable due diligence, and be transparent in terms of what we're doing (as happens when approving new committers), but when making judgment calls err on the side of inclusion rather than exclusion.
This does somewhat put the finger on the relationship between the CA and Mozilla. Currently, this is an informal agreement based on the policy, bug filing, and other communications. What might be better is a single document (or mod to the policy) that specified what the complete agreement was (listing the others). In this we could typically include the disclaimers of liability, and how we would deal with the disputes, e.g., over the activities of the CA's wilder subroots, and at an extreme level, any root revocation at Mozilla's discretion.
I'd like at some point to consider formalizing our relationships with CAs, e.g., through some sort of formal legal agreement associated with Mozilla including a root. That would take a bit of work and involve a number of people to get it done right, and unfortunately I have more pressing priorities right now in the CA area. (Basically: getting requests processed in a timely manner and doing the work necessary to have someone else take over these duties sometime in 2009.)
However I think these sorts of discussions are useful, as they will provide good context if/when we actually get down to drafting a formal CA agreement.
Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
