CA/Root Store Policy Archive

Process for Updating the Policy

The general process that will be followed to update the Mozilla CA Certificate Policy is as follows. Issues and potential changes will be tracked in the policy issue tracker.

1. A Mozilla representative will bring forward an item for discussion in the mozilla.dev.security.policy forum.
2. There will be a discussion of how, if at all, to modify the policy for the item.
3. At some point, which may be at the start, a Mozilla representative will draft proposed text.
4. A Mozilla representative will summarize a consensus that has been reached, and/or state the official position of Mozilla in both the discussion in mozilla.dev.security.policy and in the policy issue tracker.
5. The draft policy in Github will be updated, if required.
6. The issue will be closed.

At intervals, a new policy version will be released based on the current draft, along with a timeline for compliance.

• A Mozilla representative will post notice in the mozilla.dev.security.policy, mozilla.dev.security, and mozilla.governance forums.
• A Mozilla representative will send email communication to CAs, indicate the compliance schedule.

Previous Versions of the Policy

2.2

• Policy document
• Publication date: July 26, 2013
• Compliance date: July 26, 2013 (more specific details)
• List of changes: bug 868144

2.1

• Policy document
• Publication date: February 14, 2013
• Compliance date: February 14, 2014 (more specific details)
• Items considered: CA:PolicyVersion2.1
• List of changes: bug 763758

2.0

• Policy document
• Publication date: February 2, 2011
• Compliance date: August 8, 2011 (Feb 2, 2011 for new root inclusions)
• Items considered: CA:PolicyVersion2.0
• List of changes: bug 609945

Earlier

• Version 1.2 -- January 2008
• Version 1.1 -- November 2007
• Version 1.0 -- November 2005
• Version 0.4 -- March 2004

Items that belong in the Recommended Practices Wiki Page

List of items that may belong in the Recommended Practices wiki page:

• CP/CPS documents: Further recommendations about CP/CPS documents
• CA Hierarchy: A hierarchical structure of a single root with intermediate/subordinate certs is preferred.
• Audit Criteria: Further information about Audit Criteria
• Domain Name Verification: More specific information about the requirements for verifying domain name ownership
• Email Address Verification: More specific information about the requirements for verifying email address ownership
• Verification of Identity of Code Signing Certificate Subscriber: More specific information about the requirements for verifying that the entity submitting the certificate signing request is the same entity referenced in the certificate, or has been authorized by the entity referenced in the certificate.
• OCSP Recommendations: How to test OCSP in Firefox, commonly encountered error codes, etc.
• Non US-ASCII character sets in certs

Items that belong in the Potentially Problematic Practices Wiki Page

Items that may belong in the Potentially Problematic Practices wiki page.

• Delegation of Domain / Email validation to third parties:
• Issuing end entity certificates directly from roots
• Allowing external entities to operate subordinate CAs
• Distributing generated private keys in PKCS#12 files
• OCSP Responses signed by a certificate under a different root
• CRL with critical CIDP Extension
• Generic names for CAs