Frank,
I think you have just opened a big can of worms with this Certificate policy.
- It should be called a Mozilla Certificate authority policy, not Certificate policy. I don't think there is any plan to include any non-CA certificates.
I originally called it the Mozilla CA Certificate Policy, but changed it just to have a shorter name. I can certainly change it back.
But to play devil's advocate: It is 100% guaranteed that we would never ever want to include a non-CA cert in Mozilla?
- I think the term "default certificate database" is somewhat ambiguous. Technically, there is a built-in PKCS#11 module containing a database of root certificates and trust. This module is separate from the certificate database associated with each Mozilla profile. In fact, the root certs module/database can be removed by the user altogether and security in Mozilla can continue to function without it. I just had to point that out. The CA certs don't get added to the profile certificate database, unless their trust is modified.
I am open to using different terms and a simple way to explain what actually is done. Suggestions welcome.
- I am not a lawyer, but I really think you are underestimating the liability issues for the foundation if it chooses to select certificates.
That may well be. As I said before, I will certainly submit any proposed policy to the Mozilla Foundation for approval by the appropriate people (MF officers, and the MF board if necessary), and recommend that they have appropriate legal counsel review the policy. But I am not going to attempt to do the lawyers' job for them; that is not what I'm being paid to do (well, I'm not being paid anything at all, but you get the point).
Please forgive me now if I rant for a bit: I'd like to have a conversation about mitigating security risks, but people keep dragging me off to start a conversation about legal risks. Why is that? What is it about CA certs (as opposed to a host of other important security-related issues) that prompts this relentlessly single-minded focus on bad things that can happen from a legal point of view? (I am tempted to say, "because with PKI and CAs the lawyers got there first", but I'll hold that thought for now.)
You may recall that I was the lead on mozilla.org creating a policy on addressing and disclosing security vulnerabilities in Mozilla. We had plenty of hard-hitting discussions on how best to mitigate security risks to Mozilla users. We spent very little time (if any) worrying about how to mitigate legal risks. But the types of security vulnerabilities under discussion were fully as serious as the types of vulnerabilities resulting from breakdowns in the CA cert scheme. (In fact on first impression I'd take the vulnerabilities to be formally equivalent: a Mozilla exploit allowing file writing could lead to CA certs being invisibly added and/or trust flags reset, and a bad CA cert, e.g., for object signing, could lead to a user downloading exploit code.)
I guess the difference is that with "normal" vulnerabilities we've internalized the idea that license liability disclaimers do at least a reasonable job of mitigating any legal risks to developers and distributors, and we focus primarily on security risks. If we consider things like formal security certifications (e.g., Common Criteria), it's as a potentially-useful option for customers who care about it, but of a somewhat different nature than standard "designing for security", and not a substitute for it. On the other hand with CA certs we seem to get paralyzed by the sheer amount and complexity of the legal paperwork and audit frameworks, to the point where we feel we can't move without consulting a lawyer.
Past a certain point I just don't understand why this is the case. I don't understand why we have to consult a lawyer before deciding whether to add a CA cert, and not when deciding how to best configure Mozilla security options for the typical user. (And in fact isn't the former just an special case of the latter?)
As a final point, I've actually looked at the ABA documents, and I can't figure out how their whole legal discussion applies in the case of something like Mozilla. IIRC it is organized around the concept of CAs, certificate holders, and "relying parties". We are certainly not a CA and not a certificate holder. It's possible that we would be considered a "relying party", but that role really seems to be played by Mozilla users, e.g., who connect to certificate-presenting web sites and so on. I guess we could be considered a sort of agent acting on behalf of a relying party, but I don't recall the ABA documents addressing that situation. I'd be interested in any online references that actually discuss this.
Anyway, that's the end of my rant (at least for now).
- As the (soon-to-be-former) AOL/Netscape employee who has been doing most of the check-ins to the built-in root certs for NSS in recent years, I know I would not feel comfortable at all with a policy that is so arbitrary and void of verifiable objective criteria - section 4.1 in particular.
Then let's come up with some verifiable objective criteria -- but let's focus on criteria that mitigate security risks, as opposed to legal risks. The lawyers can take care of themselves.
- The current official certifications for commercial CAs such as WebTrust are extensive and expensive. They don't match 1 to 1 with the spirit of the Mozilla foundation, in that they may be overly restrictive on who can join the party. So they shouldn't be a sine qua non condition for inclusion.
Glad to hear it.
- Most users don't understand PKI security and are not able to make CA certificate trust decisions. And it would be indeed laughable to except them to be able to do so with a pop-up that simply shows a few fields in the certificate. Ever tried to verify a root CA certificate just by looking its contents ? What did you do, call a company's 800 number and check the fingerprint and public key to make sure it matched ? The point is, you need an external source of trust to help with the decision.
There is no one-size-fits-all list of trusted CAs.
But of course the problem is that in this respect the Mozilla Foundation offers Mozilla as a one-size-fits-all product, in large part as a consequence of the design of the underlying security/crypto mechanisms. We can't easily offer "Mozilla for casual Internet use", "Mozilla for onlinke banking", "Mozilla for Federal government agencies and contractors", and so on.
Ideally we could handle this through the extension model being implemented by Firefox and Thunderbird -- download an extension to enable a particular set of CA certs for a particular purpose. (Of course we'd have to address the bootstrap problem of validating such extensions, e.g., by signing them with an object signing cert issued by a CA whose cert is present in the base product.) But this is speculation about the ideal, not the reality we have to deal with right now.
That's why trust is editable, and not static. People are using Mozilla in diverse environments. I personally use Mozilla as if it were commercial software, for personal needs such as banking, and wouldn't expect it to include MyFriendlyNonProfitCAWhoCan'tAffordWebTrust, Joe'sPersonalCA, or MilitarySecretCA.
In the later two cases, the end-users are savvy enough to install the certificates themselves, before they actually start to use them (ie. long before the browser pops-up an "unknown CA - do you want to trust it?" pop-up).
The example of MilitarySecretCA reminds me of a point worth emphasizing: IMO the most significant legal implications of CA certs come in situations where the certificate holders are large enterprises engaging in large-dollar-volume commerce or similar activities with relatively severe consequences if things go awry, and where the parties involved (the certificate holders) operate in a fairly heavyweight pre-existing
legal frameworks of contracts, etc. To a large extent these parties can and IMO should be able to "take care of themselves" with regard to CA certs, by actively vetting the software they use to perform these activities, including consulting independent auditors, and reconfiguring it if necessary (e.g., deleting/adding CA certs and setting trust flags appropriately).
You on the other hand might want to use MyFriendlyNonProfitCAWhoCan'tAffordWebTrust without being presented a trust pop-up that is very hard to act upon.
Unfortunately, I don't know of any organization that will vouch for CAs in the MyFriendlyNonProfitCAWhoCan'tAffordWebTrust category, but it sounds like that's what you need here. I don't think it can or should be the Mozilla foundation itself doing it through its policy.
I also don't think they should be blanket included together with all the commercial CAs that passed a certification.
Above you wrote "The current official certifications for commercial CAs such as WebTrust ... shouldn't be a sine qua non condition for inclusion", implying that a CA could be included without going through such a certificate. But here you write "I also don't think [non-certified CAs] should be blanket included together with all the commercial CAs that passed a certification." So I assume that you are using "blanket included" to mean something different than plain "included", and the that difference is defined in your next statement: "blanket included" means included in the same PKCS#11 module.
I think MF should defer to such a CA verification organization when one is created. When it does, these CA certs can be compiled into a separate PKCS#11 module containing only certificates CAs in this category.
The Mozilla browser could then prompt the user for the security policy he wants to adopt when creating his profile : there could be a checkbox for the commercial CAs, which would basically be the current built-in module, and another checkbox for MyFriendlyNonProfitCAWhoCan'tAffordWebTrustCAs(for lack of a better term) who did not go through the WebTrust (or other) commercial certification required to be included in the first group.
The effect of each checkbox would be to load or not load a given PKCS#11 modules containing a set of trusted CA certificates. 0, 1, 2 or n PKCS#11 modules containing trusted CA certificates can be loaded in Mozilla in any one profile.
This way, the user makes the decision of which CAs he trusts on a rational basis when creating his profile with a question that he can answer.
This is a fine idea, and it matches my naive conception of an extension-style mechanism to let users customize Mozilla in terms of accepted CAs as they customize it in terms of features.
But this mechanism doesn't exist today, and may never exist if nobody does the work of creating it. I want to create a policy now, and what you seem to be recommending is the policy must mandate independent audits of CAs until whatever point in the (possibly far distant) future that the Mozilla implementation provides a way to group CAs in this way. I don't agree with that.
Frank
-- Frank Hecker hecker.org _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
