Wow! I'm very impressed with this draft of a metapolicy.
17 solid points, addressing just about all concerns voiced so far. I agree with 16.5 of them :) Thanks for all your work on it.
Here are some suggestions about metapolicy point 5.
5. The policy should take into account both the risks and benefits of including CA certificates in Mozilla, and the creators and implementors of the policy should attempt to balance the risk and benefits in a manner consistent with that employed elsewhere in the Mozilla project in regard to non-CA-related security features and vulnerabilities.
Perhaps if you said "... consistent with the balance employed for *security vulnerabilities* elsewhere in the Mozilla project..."
Rationale: MOST of what is dicussed and developed by mozilla developers is UI or directly related to UI. And there just isn't must real risk to getting UI wrong. If clicking the subject column header in the email reader sorts the messages by author instead of subject, well, there's not much risk. So, MOST mozilla developers and staffers are accustomed to thinking of risk in terms of a little embarrasment (when a feature doesn't work), a little annoyance (if moz crashes), and not much worse. THAT common sort of risk/reward thinking is inapplicable to security issues, IMO, whether crypto or just the buffer overrun variety.
Rationale: Doing risk/benefit analysis is (or should be) standard practice for any policy addressing security issues. In addition, in the case of the Mozilla project there are other areas where comparable risk/benefit tradeoffs must be made, most notably in decisions relating to potential Mozilla security vulnerabilities that have nothing to do with CAs or certificates.
Agreed. These are other SECURITY areas. The level of risk analysis done there is about the only other area in mozilla where it is comparable to what is needed for crypto security, IMO.
Given that some of those vulnerabilities have consequences that are comparable in nature and severity to those resulting from problems with CA certificates, it doesn't make sense to do risk/benefit analysis for one set of vulnerabilities in a way that's wildly different than for the other set. In particular, it doesn't make sense to give much greater weight to risks over benefits in the case of CA certificates.
I agree, in principle to the *weight* argument. But crypto risks have potentially greater costs associated with them. A broken UI feature has a risk that is near zero in terms of dollars and cents. A broken trust system could cost big $$. One doesn't need to "weight" the crypto risks higher than other risks (in the sense of giving the crypto risks some coefficient multiplier greater than 1) - one merely needs to appreciate that they are (or, some of them are) inherently higher risks.
One more point about benefits/rewards. Once mozilla has a sufficient number of trusted CAs that are acceptable to the community of mozilla users (which I think implies that their costs are low enough for mozilla users), then the benefit of adding more such CAs rapidly diminishes. Once a mozilla user can easily get a cert at a price to his liking, and at a level of effort to his liking, and having to reveal no more personal info than to his liking, then adding many more CAs to the list is like adding more Send buttons to email composer UI, or more Back buttons to the browser UI. Not much additional benefit. I don't know what number will be sufficient, but I'd guess it's rather small.
But while more CAs don't add much value to mozilla users, they do add more risk. Since all trusted issuers of (say) SSL server certs are trusted equally, adding another SSL server CA mostly adds to the risk of a fraudulent cert being issued.
So, while there is no need to specially WEIGHT the benefits and risks of adding new CAs, I believe that those benefits and risks are inherently rather one-sided, (again, after the initial benefit is provided). And so I think it may be worthwhile to state that it is expected that more effort will be expended looking for risks than looking for benefits when adding new CAs to the list.
BTW, I'm not advocating that mozilla should cut off admission to the list after any fixed number of CAs are admitted. I am suggesting, however, that after the list contains some number, MF might not be strongly motivated to continue to evaluate new candidates, so it's worth choose those candidates well.
/Nelson
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
