17 solid points, addressing just about all concerns voiced so far. I agree with 16.5 of them :)
Actually I think there were 19 points, unless I misnumbered :-)
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.
OK, I think we're actually agreeing here, but I definitely need to clarify what I was trying to say.
As I see it, deciding which CA certificates to include is a specific instance of the general case of deciding what the default "security configuration" should be for Mozilla. Such decisions may involve how to set an actual Mozilla preference, or they may involve deeper design issues concerning how particular features should work. Examples of such decisions include:
* Whether or not Mozilla should automatically download and run executable programs when users click on links to such programs.
* Whether or not JavaScript should be enabled by default when displaying HTML mail messages.
* Exactly which types of DOM manipulations, etc., should JavaScript code on downloaded web pages be allowed to do, and in what contexts.
I an *not* comparing decisions about CA certs to, e.g., decisions on how to sort email messages by default, or decisions about exactly which fonts to use in displaying web content, or other decisions which are less security-relevant.
All of the decisions referred to above are "up front" decisions, i.e., they are made (whether explicitly or by default) by Mozilla developers and/or distributors prior to shipping Mozilla.
The reference I made to security vulnerabilities is thus somewhat confusing, for two reasons:
* Security vulnerabilities in general can arise from Mozilla features that have nothing obviously to do with security as discussed above -- for example, potential exploits made possible by buffer overruns in code that displays downloaded images.
* Many decisions relating to security vulnerabilities are "after the fact" decisions arising once the product has shipped: how to work around a vulnerability, how to fix it for good, whether and when to disclose information about the vulnerability, and so on.
I'm not exactly sure how I should change the metapolicy to clarify these issues, but I'll come up with something.
<snip>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.
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.
I understand your point here, but I'm not sure in practice what to do about it. I am reluctant to say to CAs, "sorry, we've got enough CA certs already", particularly since we will almost certainly be "grandfathering in" all the CA certificates that are already included in Mozilla because they were selected under the prior regime.
Frank
-- Frank Hecker hecker.org _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
