Julien Pierre wrote:
- 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.
Well "CA cerificate" is somewhat redundant (it includes "Certificate" twice). I would say "Mozilla [built-in] Certificate Authority Policy" would be a good name.
But to play devil's advocate: It is 100% guaranteed that we would never ever want to include a non-CA cert in Mozilla?
It is not guaranteed. You can use the built-ins module for anything you want, including negative trust on some known compromised popular server certs (ie. like a global CRL). But I would not recommend such use. I think in practice you would only ever want root CA certs on it.
- 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.
Well, I don't know yet what the right name should be, but if we choose to have several modules with different set of certs, then the distinction becomes more important since there won't be a single "default certificate database".
(MF officers, and the MF board if necessary), and recommend that they
Make that "require".
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.)
Does it really need spelling out ? If you have a rogue or compromised trusted CA in Mozilla, which willingly signs fake server certificates, that opens the door to all kinds of scams, where Mozilla users will think they are doing business with somebody when in fact they are not. Remember that one of the most common uses of SSL is for financial transactions. If Mozilla users suffer financial losses due to a rogue trusted CA, you can bet they will sue whoever approved that trusted CA, disclaimer or not. So it is in the interest of the Foundation not to make the decision itself.
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?)
You have a point. And I think the MF should have a good answer to that question, since it distributes all the security code, not just the CA certs. The liability situation is different now that there is an MF, rather than a corporate distributor of the open-source code.
- 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 policy will have to address both risks, for the sake of the MF and the contributors editing the database.
- 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.
That single product could still offer the user a choice of several security policies for the various types of users.
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.)
Downloading a set of certs and asking the user to trust them all is an even more difficult decision to do than asking the user to trust one cert ... I think we should limit this discussion to the built-in certs that are distributed with Mozilla.
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).
I agree. For these applications, the environment is not an open one, and these Mozilla users can customize the software with their own built-in list of trusted certs compiled in, as opposed to the one that comes with Mozilla.
Alternatively, if they want to use the binaries distributed on Mozilla.org, they can delete the built-in root certs module altogether, and add their trusted root certs obtained from a known reliable source manually.
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.
Yes, I mean that there should be different groups of trusted certs for these categories, in separate PKCS#11 modules, clearly marked and named. There wouldn't be one default module that would be always trusted.
You could ask the user during profile creation if he wants to trust
X "commercial CAs (entities verified by WebTrust, Inc)"
X "other non-profit CAs (entities verified by MyCheaperAuditCompany, Inc)"
One, both, or neither of those checkboxes could be set by default, but the user would have to be presented with this choice when creating his Mozilla profile to make sure he chooses the set he wants.
To preserve compatibility with the current way Mozilla operates, and to protect non-security savvy Mozilla users, I think the preferred default would be to have a checkbox next to the commercial CAs, and no checkbox next to the non-profit CAs.
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.
My take on this is, the policy should be carefully examined before it is decided, it's not something to do in a hurry just because there are a couple CAs that are shouting that they want to be included right away. It may well be that the right policy requires some work to actually implement.
Let's examine the work that's actually required to implement my proposal :
- NSS already has the ability to load any number of PKCS#11 modules. No code changes needed here.
- It is quite trivial work to generate multiple PKCS#11 root-cert modules from multiple CA cert lists. All that needs to be done is to rebuild the builtins directory with a different certdata.txt, and a different DLL/.so target name . That's mostly scripting/Makefile work. Again, no code changes are needed.
- PSM already has a UI and code to load PKCS#11 modules manually, under "Security Devices", which could be used to load alternate/additional root certificate modules. This is not very user-friendly and buried in the preferences/privacy and security dialog, but it actually does the job.
- The only real new code that needs to be written to make the process seamless for Mozilla users is a GUI prompt in the Mozilla profile creation to ask the user to choose the CA policy(s) he wants to use, and load the corresponding PKCS#11 module(s), which is done by a single existing NSS API call. Now, it's been a long time since I wrote any GUI code, and I have never written any for Mozilla itself, but it does not strike me as a lot of work.
Of course there is still the dependency on finding a third party to verify the non-commercial CAs. I think that's something that is inevitable, and you should start looking for one now. If you can't find one, somebody else suggested creating a separate legal entity tasked with that specific role, which would protect the MF from any bad calls on the CAs included.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
