Updating the Mozilla CA Cert Policy - Version 2.0

RESOLVED FIXED

Status

NSS
CA Certificate Root Program
--
enhancement
RESOLVED FIXED
8 years ago
a year ago

People

(Reporter: Kathleen Wilson, Assigned: Kathleen Wilson)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Published)

(Assignee)

Description

8 years ago
A proposed first draft of updating the Mozilla CA Certificate Policy is here:

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress

The red text indicates the changes (except for the links). The changes include a general reorganization as proposed in
https://wiki.mozilla.org/CA:CertPolicyUpdates#General_Ideas.2FComments
and the items that were proposed to be included in the First Phase of updating the policy
https://wiki.mozilla.org/CA:CertPolicyUpdates#First_Phase

The First Phase items were incorporated as follows.

* CP/CPS documents must be publicly available
** Added to Inclusion Section, #14.

* Compromised Certificates
** Added to Maintenance Section, #2.
** Copied majority of text from the CABForum minimum requirements document.

* Audit Renewals
** Added to Maintenance Section, #4.

* Root Changes
** Added to Maintenance Section, #8.
** Added to Enforcement Section, #4.

* OCSP Max Expiration
** Added to Maintenance Section, #3.

* nextUpdate for CRLs
** Added to Maintenance Section, #3.

* Validate all Data included in Certificates
** Added to Inclusion Section, #7.

* Long-lived DV certificates
** Added to Inclusion Section, #8.

* Email Address Prefixes for DV Certs
** Added to Inclusion Section, #8
** Copied majority of text from the CABForum minimum requirements document.

* Specify the types of signatures and moduli that are supported
** Added to Maintenance Section, #7.

* Fix issues in sections 7 and 8 of the Mozilla CA Certificate Policy…
** Inclusion Section, #7: removed references to June 30, 2008; fixed link.
** Inclusion Section, #9: updated WebTrust link, added ETSI TS 102 042 EV criteria.
** Inclusion Section #14: public audit attestation

* Add link to CA:How_to_apply wiki page
** Added to Inclusion Section, #16.
(Assignee)

Comment 1

8 years ago
I have started the public discussion of this proposed first draft in the mozilla.dev.security.policy forum.

After the discussion and changes settle down, I plan to attach some diff information to this bug to clarify the exact changes as much as possible.
Status: NEW → ASSIGNED
Whiteboard: In public discussion
(Assignee)

Comment 2

7 years ago
I have change the new version number from 1.3 to 2.0.
Summary: Updating the Mozilla CA Cert Policy - Version 1.3 → Updating the Mozilla CA Cert Policy - Version 2.0
(Assignee)

Comment 3

7 years ago
The first round of public discussion is complete. I will now summarize the proposed changes between version 1.2 and version 2.0 of the policy.

The Policy has been divided into three sections:

1. Applying for Inclusion of Root Certificates in Mozilla Products

This is mostly the original policy, so I will provide diff information between this section and version 1.2 of the policy.

2. Maintaining Confidence in Included Root Certificates

This section is completely new. 

3. Enforcing the Mozilla CA Certificate Policy

This section is completely new.
(Assignee)

Comment 4

7 years ago
Here follows the differences between 
> version 1.2 of the current policy
and
< section 1 of the new policy 

The following paragraph remains (with no changes) in the main page of the policy. It was not moved to section 1 of the policy.

> When distributing binary and source code versions of Firefox, 
> Thunderbird, and other Mozilla-related software products the Mozilla 
> Foundation and its wholly-owned subsidiary the Mozilla Corporation 
> include 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.

The following paragraph is all new. It is the first paragraph of section 1 of the updated policy.

< This section of the Mozilla CA Certificate Policy describes the obligations 
< of Certification Authorities applying for inclusion of their root 
< certificates in Mozilla Products. This includes considerations that are taken 
< into account such as the CA's publicly available documentation about their 
< policies, and audits of the CA's operations in support of the documented 
< policies.


> This is the official Mozilla Foundation policy for CA certificates that 
> the Mozilla Foundation and Mozilla Corporation distribute with our 
> software products:

< This is the official Mozilla Foundation policy for Certification Authorities 
< applying for inclusion of their CA Certificates to be distributed in Mozilla 
< products:

> 4. 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, or 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

< 4. We reserve the right to not include a particular CA certificate in our 
< software products. 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

Note: the text that was removed from #4 is covered in section 3 of the updated policy.

> 5. We will consider adding certificates for additional CAs to the default 
> certificate set upon request.

< 5. We will consider adding certificates for additional CAs to the default 
< certificate set upon request by an authorized representative of the 
< subject CA.

In #6:

< limit the validity period of end-entity certificates to thirty-nine months 
< or less;

> provide attestation of their conformance 

< provide public attestation of their conformance

In #7: 

< all information that is supplied by the certificate subscriber must be 
< verified by using an independent source of information and an 
< alternative communication channel before it is included in the certificate;

> for a certificate to be used for digitally signing and/or encrypting 
> email messages,

< for a certificate to be used for digitally signing or encrypting 
< email messages,

> for certificates to be used for and marked as Extended Validation, 
> the CA complies with Guidelines for the Issuance and Management 
> of Extended Validation Certificates (as modified by the erratum 
> published by the CAB Forum) (or, for CA requests submitted on or 
> before June 30, 2008, draft 11 of these guidelines), and has its 
> compliance attested to in accordance with the requirements of 
> Section J of that document.

< for certificates to be used for and marked as Extended Validation, 
< the CA complies with Guidelines for the Issuance and Management 
< of Extended Validation Certificates version 1.2 or later.

Added:

< 8. When the CA uses an email challenge-response mechanism to 
< validate that the certificate subscriber has control of the requested 
< domain, the CA must either use a mail system address from the 
< technical or administrative contact information in the domain's WHOIS 
< record, or one formed by prefacing the requested domain with one of the
<  following local parts: admin, administrator, webmaster, hostmaster, 
< or postmaster.

In new #9, previously #8:

< ISO 21188:2006 Public key infrastructure for financial services – 
< Practices and policy framework.

> "WebTrust Principles and Criteria for Certification Authorities" 
> in AICPA/CICA WebTrust Program for Certification Authorities, 
> Version 1.0; or

< "WebTrust Principles and Criteria for Certification Authorities" 
< in WebTrust Program for Certification Authorities, 
< Version 1.0 or later; or

> "WebTrust for Certification Authorities—Extended Validation Audit 
> Criteria" in WebTrust for Certification Authorities—Extended 
> Validation Audit Criteria (or, for CA requests received on or before 
> June 30, 2008, the November 20, 2006 draft of these criteria) 
> (in conjunction with "WebTrust Principles and Criteria for 
> Certification Authorities").

< "WebTrust for Certification Authorities—Extended Validation Audit 
< Criteria" in WebTrust for Certification Authorities—Extended 
< Validation Audit Criteria Version 1.1 or later

< Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V2.1.2 
< (2010-04) or later version, Policy requirements for certification 
< authorities issuing public key certificates (as applicable to the "EVCP" 
< and "EVCP+" certificate policies, and any of the "NCP", "NCP+", or "LCP" 
< certificate policies);

Added:

< 14. We rely on publicly disclosed documentation (e.g., in a Certificate 
< Policy and Certification Practice Statement) and publicly disclosed audit 
< statements to ascertain that the above requirements are met. Therefore, 
< inclusion requests will only be considered if the following are true:
< 
<    - the publicly disclosed documentation provides sufficient information 
< for Mozilla to determine whether and how the CA complies with this policy, 
< including a description of the steps taken by the CA to verify certificate 
< signing requests;
 <   - the documentation is available from the CA's official website; and
<     the public attestation of the CA's conformance to the stated verification
<  requirements by a competent independent party indicates which 
< policy documents were included in the review.

Previous #13 removed:

> 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.

In new #15, previous #14:

> To request that its certificate(s) be added to the default set a CA 
> should submit a formal request by submitting a bug report into the 
> mozilla.org Bugzilla system, filed against the "CA Certificates" component 
> of the "mozilla.org" product. The request should include the following:

< To request that its certificate(s) be added to the default set a CA 
< should submit a formal request by submitting a bug report into the 
< mozilla.org Bugzilla system, filed against the "CA Certificates" component 
< of the "mozilla.org" product. Mozilla's wiki page, Applying for root 
< inclusion in Mozilla products, provides further details about how to 
< submit a formal request. The request must be made by an authorized 
< representative of the subject CA, and should include the following:

In new #16, previous #15:

> We will appoint a CA certificate "module owner" to evaluate CA 
> requests on our behalf and make decisions regarding all matters 
> relating to CA certificates included in our products. CAs or others 
> objecting to a particular decision may appeal to mozilla.org staff, 
> who will make a final decision.

<  We have appointed a CA certificate "module owner" and (optionally) 
< one or more "peers" to evaluate CA requests on our behalf and make 
< decisions regarding all matters relating to CA certificates included in our 
< products. CAs or others objecting to a particular decision may appeal to the 
< Mozilla governance module owner or peer(s), who will make a final decision.

Previous #16 is verbatim the last paragraph on the new page:

> 16. We reserve the right to change this policy in the future. We will do 
> so only after consulting with the public Mozilla community, in order to 
> ensure that all views are taken into account.
(Assignee)

Updated

7 years ago
Whiteboard: In public discussion → In Final Review
(Assignee)

Comment 5

7 years ago
The final round of discussion of the updated policy is nearing completion. Here are changes that were made as a result of the discussion.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Section 6:

Removed
> limit the validity period of end-entity certificates to  
> thirty-nine months or less;

Added
< verify that all of the information that is included in SSL 
< certificates is current and correct at time intervals of 
< thirty-nine months or less;

Section 7: 
Changed the “and” to “or” in the first bullet.

> all information that is supplied by the certificate subscriber must  
> be verified by using an independent source of information and an 
> alternative communication channel before it is included in the 
> certificate;

< all information that is supplied by the certificate subscriber must  
< be verified by using an independent source of information or an  
< alternative communication channel before it is included in the 
< certificate;

Section 8: 
Changed "requested" to "registered" 

> either use a mail system address from the technical or 
> administrative contact information in the domain's WHOIS 
> record, or one formed by prefacing the requested domain 
> with one of the following local parts: 

< either use a mail system address from the technical or 
< administrative contact information in the domain's WHOIS 
< record, or one formed by prefacing the registered domain 
< with one of the following local parts:

Section 9: 

Removed
> Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V1.1.1 
> (2002-04) or later version, Policy requirements for certification 
> authorities issuing public key certificates (as applicable to any of 
> the "NCP", "NCP+", or "LCP" certificate policies);

Moved this item up in the list, taking the place of the removed item.
< Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V2.1.2 
< (2010-04) or later version, Policy requirements for certification 
< authorities issuing public key certificates (as applicable to the 
< "EVCP" and "EVCP+" certificate policies, and any of 
< the "NCP", "NCP+", or "LCP" certificate policies);


http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html

Section 2:

Removed
> the CA receives notice or otherwise becomes aware that a wildcard  
> certificate has been used to authenticate a subdomain name that 
> appears to be intended to mislead users as to the identity of 
> the site's operator;

Section 9:

Changed
> all new certificates must contain at least 20 bits of 
> cryptographically secure randomness (preferably in the serial number) 
> generated from a random number generator using an algorithm that is 
> eligible for FIPS 140-2 validation at the time the certificate is 
> generated, especially when using the SHA-1 hash function or an RSA 
> key size smaller than 2048 bits.

To
< all new end-entity certificates must contain at least 20 bits of 
< unpredictable random data (preferably in the serial number).
(Assignee)

Comment 6

7 years ago
The final discussion of Mozilla CA Certificate Policy Version 2.0 is now closed.

The draft version of the policy with red text indicating changes may be found in the following versions of the files.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/index.html
Revision ID: 80599

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
Revision ID: 81358

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html
Revision ID: 81285

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/EnforcementPolicy.html
Revision ID: 80601

I am going to remove the red highlighting now, so that a final review may be done as part of the approval phase.
Whiteboard: In Final Review → Pending Approval
(Assignee)

Comment 7

7 years ago
Version 2.0 of the Mozilla CA Certificate Policy is ready for final review and approval. (I have removed the red highlighting and "DRAFT".)

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/
(Assignee)

Comment 8

7 years ago
During this final review phase, I have made the following changes.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Section 1: Changed “through mozilla.org” to “by Mozilla”.

> 1. We will determine which CA certificates are included 
> in software products distributed through mozilla.org,

< 1. We will determine which CA certificates are included 
< in software products distributed by Mozilla,

Section 5: Added “only”.

> 5. We will consider adding certificates for additional CAs 
> to the default certificate set upon request by an authorized 
> representative of the subject CA.

< 5. We will consider adding certificates for additional CAs 
< to the default certificate set upon request only by an authorized 
< representative of the subject CA.

4th bullet in #6: Changed “is” to “remains”.

> verify that all of the information that is included in SSL 
> certificates is current and correct at time intervals of 
> thirty-nine months or less;

< verify that all of the information that is included in SSL 
< certificates remains current and correct at time intervals of 
< thirty-nine months or less;

Comment 9

7 years ago
I have reviewed the proposed 2.0 version of the Mozilla CA Certificate Policy as currently posted at

  http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/

and have also reviewed the discussions of the policy that took place in mozilla.dev.security.policy.

As module owner of record for the Mozilla CA certificate policy governance submodule, I hereby formally approve adoption of the new version as official Mozilla policy. (Kathleen, note that this is somewhat of a redundant formality, since you could have approved it on your own in your capacity as peer for that module.)

Kathleen, thanks for all your great work on this new revision! To everybody else who participated in the discussion and provided feedback on the proposed chances, thanks for your help!
(Assignee)

Comment 10

7 years ago
Thanks! I will publish the new policy now.
Whiteboard: Pending Approval → Approved
(Assignee)

Comment 11

7 years ago
Version 2.0 of the Mozilla CA Certificate Policy has been published.

http://www.mozilla.org/projects/security/certs/policy/
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: Approved → Published

Updated

a year ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.