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
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
- 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
- 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
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:
Microsoft has adopted WebTrust for inclusion in Windows:
"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
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).
For the server, the operating system on it, a CommonCriteria/ITSEC certificate
could make sense.
And for the cryptomodule that stores the root certificate a FIPS140
certificate would be useful.
CA WebTrust, is a certificate dedicated for the whole certification
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:
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.