233453 - mozilla.org needs a public policy on root CA certs

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 3

[Frank Hecker]

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.

Comment 4

[Mihai Amariutei]

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.

Comment 5

[Duane]

(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?

Comment 6

[Stephen Davidson]

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.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

This bug is not the place to conduct this discussion.  
Please use the newsgroup.  Thanks.

Comment 8

[Julien Pierre]

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 ?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 10

[Frank Hecker]

Added a number of new bugs for requests not previously entered, and marked them
as blocked by this bug.

Comment 11

[Philipp Gühring]

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. 
 

Comment 12

[Gervase Markham [:gerv]]

We now have a policy:
http://www.hecker.org/mozilla/ca-certificate-policy

Gerv

Comment 13

[David E. Ross]

Now that the policy is official, what is the status of the Metapolicy and FAQ?  

Comment 14

[Frank Hecker]

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.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Now that the policy is finally official (thanks!), shouldn't it be on
www.mozilla.org instead of (or in addition to) hecker.org?

Comment 16

[Steffen Wilberg]

The policy has been published at http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html.