The mozilla organization/foundation needs a policy concerning the criteria for admission of root certificates from Certificate Authorities into mozilla's list of trusted root certificates. The policy needs to be published (a web page would be good). It should be well thought out. It MUST be uniformly applied to applicants. It must consider the public trust and confidence in PKI. It should consider the liabilities that the mozilla foundation might incur from it. This bug blocks bug 204839, bug 215243, bug 232695, and possibly others, all bugs representing requests for the addition of new root CA certs. I will add some comments below on some suggested questions, from among which Mozilla Foundation may wish to chose its .critia
On 2003-12-09 18:58 PST, Chris Hofmann, apparently speaking for mozilla foundation (MF) wrote, in http://bugzilla.mozilla.org/show_bug.cgi?id=215243#c14 > MF requires all CAs > (a) be root CAs; > (b) offer services to the general public; > (c) provide public info about CA and > (d) its policies and procedures. > MF may in addition include root CAs that do not provide services to > the general public (e.g., for an intranet customer). > MF won't distribute non-CA-certs (e.g., self-signed web server certs). By those standards, any issuer of certificates who offers services to the public, and provides public info about itself, its policies and procedures, is elligible for inclusion in mozilla's root CA list, regardless of the content of that public information, since the policy sets no requirements for that content. Those standards do not require - any conformance to any standard for certificates. - any assurances that the CA's private keys are well protected. - any minimum (or maximum) key sizes - any Identification and Authentication (I&A) of parties wishing to apply for certificates. - any provision for revocation of certificates for compromised private keys, or provision to make revocation available to relying parties in a timely manner A CA that uses only 256-bit RSA public keys, that requires no proof of identity whatsoever, makes its private key *publicly* available on a web page, provides no revocation, and discloses all of this publicly, would qualify by the requirements given above. I offer here a set of questions, from which mozilla foundation might choose a subset to ask CA list applicants. mozilla foundation would have to decide what answers constitue an acceptable minimum (or maximum). 1. How do you protect your single most valuable asset, the private key(s) for your root CA cert(s)? - Do you store them in a tamperproof hardware security device? - Is two-factor authentication required to make that device perform operations with the private key? - Could an armed robber steal it and then use it? - Could a house burglar steal it, not even realizing what it was? - Is it on some computer's hard drive, as a "PEM" or "PKCS8" file, where it could be copied? - is it even encrypted? - How many people and/or machines would have to be compromised in order for a "bad guy" to get a false cert issued with your private key? - Do you issue intermediate CA certs? and how do you protect them? 2. What (if any) provision have you made for certificate revocation? - if the private key associated with a cert issued by your CA is compromised, (e.g. copied by someone else), is there any way for the private key's rightful holder to have your CA revoke that certificate? Or can the wrongful taker of the private keys victimize the rightful holder from that time forward until the cert expires? - And what is the validity period of new certs? - How can parties who rely on certs issued by your CA obtain information from your CA about revoked certificates? - Does Your CA maintain a Certificate Revocation List that is accessible by ANY MEANS? - Does Your CA operate an OCSP server, by which relying parties may obtain up-to-the-minute revocation information? - What authentication method is used to ensure that someone cannot cause another person's private key to be revoked? 3. Will someone keep your CA operating if the principal dies, or is incapacitated, or divorced, or an earthquake or tsunami occurs? Or if the power goes out? Or the cable modem? Or liability lawsuit? - Might the equipment with the private key be sold at auction (an estate sale), or inherited by some teenage nephew? - any liability insurance? 4. What evidence can you offer of your answers?
Some additional questions occurred to me today. 5. Do all your certs and CRLs conform to RFC 3280? (or when will they?) 6. mozilla honors "wildcards" and "shell regular expressions" in an SSL server cert's Subject Common Name, and in an SSL server cert's Subject Alt Name extensions. This power feature can be abused by the issuance of certs with unduely "wild" wildcards and regular expressions. 6a. Is it true that all the certs issued by (or subordinate to) the root CAs that you want in the trust list, do not abuse the wildcards and regular expressions? (obviously, we need to define abuse) 6b. Do you promise that you will not henceforth issue certs that abuse this feature?
See my posting in n.p.m.crypto of such a proposed public policy on CA certs. I'll respond to questions, etc., in that forum.
Maybe CAs already present in a majority of browsers deployed ( for the time being IE, this is) can be presumed to meet most ( or all) tehnical requirements, as being "standard industry practice" If the said CAs are willing to indemnify mozilla foundation for any and all liabilities which may arise from their inclusion, they may be included at once. OTOH, a lot of countries ( especially in EU ) have regulated the operation of CAs (http://www.securityfocus.com/infocus/1756). Also, if a CA is registered with such a autority, it have already proved that it implements standard practices ( and is legaly obligated to follow them), and may even be required to provide idemnification for damages that may arise from their activity. Of course the policy for further admissions should be published, for new CAs which may want to enter the market.
(In reply to comment #4) > Maybe CAs already present in a majority of browsers deployed ( for the time > being IE, this is) can be presumed to meet most ( or all) tehnical requirements, > as being "standard industry practice" So if the billing process is the focus of the audit and security is secondary or not checked at all this is ok then? shouldn't these processes be examined before accepting anything as fine and dandy when it may not be?
WebTrust is not a financial audit -- it's focus is explicitly on security assurance. The Certification Authority Control Objectives were developed based on the existing body of ANSI, ISO, IETF, and other existing standards. You can see v1 of the requirements here: http://www.webtrust.org/CertAuth_fin.htm Microsoft has adopted WebTrust for inclusion in Windows: http://www.microsoft.com/technet/security/news/rootcert.mspx "Certification authority (CA) providers are required to complete a WebTrust for Certification Authorities audit or provide an equivalent third-party attestation. If you have received an audit from a different program, that is, not the WebTrust for CAs, the burden is on the CA to prove equivalency to WebTrust for CAs." Commercial CAs have pursued WebTrust as its standards are sufficiently high and internationally accepted to reduce the need for some of the audit procedures conducted by individual corporate customers. Also, the national standards (such as the Bermuda CSP authorisation that my company holds) or T Scheme (in the UK) are also a good gage of the security practices and policy enforcement of CAs. Our root cert is embedded in several browsers/OS and I don't recall that liability/indemnification of the browser has been a concern before.
This bug is not the place to conduct this discussion. Please use the newsgroup. Thanks.
I note that currently there are 7 bugs that depend on this policy, for 7 different root CAs to be added. They are assigned to 3 different people, Wan-Teh, Stephane, and myself. Stephane no longer works on PSM/NSS . I think it would make a lot of sense if we had one person in charge of doing all the check-ins for the new root CAs instead of splitting the work, at least for all the pending ones, and perhaps even for all roots in the future. I can't volunteer for this at the moment because the policy isn't final and there are legal liability issues to be sorted. Perhaps someone from mozilla.org staff would like to volunteer, however ?
Today I reassigned the bugs that depend on this one (with one exception) to Frack Hecker, and moved them to product mozilla.org and component "CA Certificates". The exception is bug 179716. That appears to be a case wherein it was previously decided to admit the CA's certs, but then only the lower class certs were put in. I am investigating that one.
Added a number of new bugs for requests not previously entered, and marked them as blocked by this bug.
Some time ago I developed a policy for browser vendors, which I would like to provide you, perhaps you can take some ideas from it. ---------- There are several things that MF can do: 1. The CA Policy Every CA has to publish a policy, that tells, what they are doing, what they are offering, and which rules they adhere to. There are two things you can do with the policy: Check it, whether it is ok for you, and audit it, whether the CA is really adhering to those rules. If the rules are ok for you, and the CA is following the rules, than the CA is trustworthy for you. You should read that policy, and decide, whether you can support with that policy, or not. (I don't think that you should outsource that part) If you have any questions or problems with the policy, you should contact the CA directly for clarification/improvement. The second thing is auditing the CA, whether they are following the rules or not. You can trust third parties like security specialists or certified public accountants for auditing it here. 2. There are several certifications for parts of the CA: For the Web-Application, it would make sense to use the criterias from OWASP.org (Open Web Application Security). http://www.owasp.org/ For the server, the operating system on it, a CommonCriteria/ITSEC certificate could make sense. http://csrc.nist.gov/cc/ And for the cryptomodule that stores the root certificate a FIPS140 certificate would be useful. http://www.nist.gov/ CA WebTrust, is a certificate dedicated for the whole certification authorities. http://www.webtrust.org/certauth.htm The problem with the certificates is that some of them cost a lot, and that it does not mean that a CA is untrustworthy, if it hasn´t been certified. Regarding the ressources, the only thing you really should do yourself is checking the policy. Everything else can be up to the CA to provide it to you. So for your policy, I would suggest the following as base principles: 1. The CA MUST provide its policy, if possible RFC2527 conform. 2. MF MUST verify whether the policy is acceptable. 3. The CA MUST provide third party audits that show the conformance of the CA to its policy, and thats good practices. 4. The CA SHOULD provide certificates/audits like CA-WebTrust, OWASP, CC, ITSEC, FIPS140, and other applicable ones.
We now have a policy: http://www.hecker.org/mozilla/ca-certificate-policy Gerv
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Now that the policy is official, what is the status of the Metapolicy and FAQ?
The metapolicy is and will remain purely an informal document; I mainly created it as a way to focus my own thinking, and secondarily as a way to justify my arguments to others. It doesn't have any official Mozilla Foundation status. The FAQ I never had time to finish. If and when I do get a chance to finish it, I'd consider it an official supplement to the policy itself. Also, at some point the policy itself will be posted to mozilla.org; I just haven't had time to do that yet.
Now that the policy is finally official (thanks!), shouldn't it be on www.mozilla.org instead of (or in addition to) hecker.org?
The policy has been published at http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html.
Component: Miscellaneous → CA Certificates
You need to log in before you can comment on or make changes to this bug.