I've done a new draft 12 of the proposed CA certificate policy; you can find it at the usual place:
http://www.hecker.org/mozilla/ca-certificate-policy
(A blog post will follow shortly.)
The two major changes in the draft are as outlined in my previous post:
* I provided examples in clause 4 of certificate-related problems that might cause us to reject a CA's application for inclusion or to consider removing an already-included CA certificate. Note that I accepted Ram's suggestion to mention cases where there are CDP or OSCP AIA extensions in issued certs but no working CRL or OSCP service.
* I added a new clause 13 that recommends CA consider using separate root or intermediate CAs when issuing certificates according to different policies.
See the attached file for complete diffs from draft 11. Note that I also made two other non-substantive changes, one to the initial paragraph to focus on Firefox and Thunderbird as the main products of interest and one to fix an HTML validation error.
As usual, comments are welcome and encouraged. At this point I think that the policy is basically in a state to be submitted to the Mozilla Foundation for approval as a 1.0 policy, and I plan to do do absent any strong objections. I could always mess about with the policy some more, but I don't believe that at this time there's a consensus to make additional substantive changes beyond what I've already made. (As I've said before, we can always revisit the policy later if/when events warrant doing so.)
Frank
-- Frank Hecker [EMAIL PROTECTED]
Index: mozilla/ca-certificate-policy.html =================================================================== --- mozilla/ca-certificate-policy.html (revision 364) +++ mozilla/ca-certificate-policy.html (working copy) @@ -28,15 +28,15 @@ href="mailto:[EMAIL PROTECTED]">Frank Hecker</a>.</p> </div> -<p>When distributing binary and source code versions of -Mozilla-related software products (e.g., Firefox, Thunderbird, the -Mozilla Suite, and Camino) the Mozilla Foundation includes with such -software a default set of X.509v3 certificates for various -Certification Authorities (CAs). The certificates included by default -have their "trust bits" set for various purposes, so that the software -in question can use the CA certificates to verify certificates for SSL -servers, S/MIME email users, and digitally-signed code objects without -having to ask users for further permission or information.</p> +<p>When distributing binary and source code versions of Firefox, +Thunderbird, and other Mozilla-related software products the Mozilla +Foundation includes with such software a default set of X.509v3 +certificates for various Certification Authorities (CAs). The +certificates included by default have their "trust bits" set for +various purposes, so that the software in question can use the CA +certificates to verify certificates for SSL servers, S/MIME email +users, and digitally-signed code objects without having to ask users +for further permission or information.</p> <div class="para"> <p>This is the official Mozilla Foundation policy for CA certificates @@ -54,16 +54,53 @@ <li>We will not charge any fees to have a CA's certificate(s) distributed with our software products.</li> - <li>We reserve the right to not include a particular CA certificate - in our software products, to discontinue including a particular CA - certificate in our products, <em>or</em> to modify the "trust bits" - for a particular CA certificate included in our products, at any - time and for any reason. This may include (but is not limited to) - cases where we believe that including a CA certificate (or setting - its "trust bits" in a particular way) would cause undue risks to - users' security <em>or</em> cause technical problems with the - operation of our software.</li> + <li> + We reserve the right to not include a particular CA certificate + in our software products, to discontinue including a particular CA + certificate in our products, <em>or</em> to modify the "trust + bits" for a particular CA certificate included in our products, at + any time and for any reason. + This includes (but is not limited to) cases where we believe + that including a CA certificate (or setting its "trust bits" in a + particular way) would cause undue risks to users' security, for + example, with CAs that + + <ul> + <li>knowingly issue certificates without the knowledge of the + entities whose information is referenced in the certificates; + <em>or</em></li> + + <li>knowingly issue certificates that appear to be intended + for fraudulent use.</li> + </ul> + + This also includes (but again is not limited to) cases where we + believe that including a CA certificate (or setting its "trust + bits" in a particular way) might cause technical problems with the + operation of our software, for example, with CAs that issue + certificates that have + + <ul> + <li>ASN.1 DER encoding errors;</li> + + <li>invalid public keys (e.g., DSA certificates with 2048-bit + primes, or RSA certificates with public exponent equal to + 1);</li> + + <li>duplicate issuer names and serial numbers;</li> + + <li>incorrect extensions (e.g., SSL certificates that exclude + SSL usage, or authority key IDs that include both the key ID + and the issuer's issuer name and serial number); + <em>or</em></li> + + <li>cRLDistributionPoints or OCSP authorityInfoAccess + extensions for which no operational CRL or OCSP service + exists.</li> + </ul> + </li> + <li>We will consider adding certificates for additional CAs to the default certificate set upon request.</li> @@ -94,7 +131,7 @@ </ul></li> <li>We consider verification of certificate signing requests to be - acceptable if it meets or exceeds the following requirements:</li> + acceptable if it meets or exceeds the following requirements: <ul> <li>for a certificate to be used for digitally signing and/or @@ -200,6 +237,20 @@ competent independent party or parties by which it proposes to meet the requirements of this policy.</li> + <li>In addition to the requirements outlined above, we also + recommend that CAs consider using separate root CA certificates with + separate public keys (or separate intermediate CA certificates with + separate public keys under a single root) when issuing certificates + according to different Certificate Policies, so that we or others + may selectively enable or disable acceptance of certificates issued + according to a particular policy, or may otherwise treat such + certificates differently (e.g., in our products' user + interfaces). We reserve the right to make this a requirement in the + future, and to not include a particular CA certificate in our + software products, to discontinue including a particular CA + certificate, or to modify the "trust bits" for a particular CA + certificate, based on the CA's practices in this regard.</li> + <li>To request that its certificate(s) be added to the default set a CA should submit a formal request as follows: @@ -279,6 +330,12 @@ to related questions.</p> <div class="important"> +<p>Version 0.12, April 9, 2005. Added examples of CA practices that +might prompt us to not accept requests for inclusion of CA +certificates (or to remove existing CA certificates). Added +recommendation on separation of certificates issued according to +different policies.</p> + <p>Version 0.11, February 27, 2005. Added requirements relating to subscriber vetting. Added blanket statement reserrving right not to include certificates. Added note about appointment of module
