Categories: CA Program Security

Announcing Version 2.1 of Mozilla CA Certificate Policy

Mozilla released version 2.1 of the Mozilla CA Certificate Policy. This version adds a requirement for either the technical constraint or the audit of subordinate CA certificates, and requires CAs who issue SSL certificates to comply with the CA/Browser Forum Baseline Requirements.

Mozilla is working towards stronger controls and visibility of publicly-trusted issuing certificates in order to make better trust decisions, detect security incidents faster, and limit the impact of each security incident. Version 2.1 of Mozilla’s CA Certificate Policy encourages CAs to technically constrain subordinate CA certificates using RFC 5280 extensions that are specified directly in the intermediate certificate and controlled by crypto code (e.g. NSS). We recognize that technically constraining subordinate CA certificates in this manner may not be practical in some cases, so the subordinate CA certificates may instead be publicly disclosed, and audited in accordance with Mozilla’s CA Certificate Policy.

All subordinate CA certificates that are issued after May 15, 2013 must comply with version 2.1 of Mozilla’s CA Certificate Policy, and all pre-existing subordinate CA certificates must be updated to comply with version 2.1 of Mozilla’s CA Certificate Policy for new certificate issuance by May 15, 2014. This time frame takes into account the impact that the new requirements might have on large enterprise subordinate CAs who may need to plan and budget for new infrastructure and audits.

Audit criteria have recently been released for the CA/Browser Forum’s “Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates” (BRs). Therefore, Version 2.1 of Mozilla’s CA Certificate Policy requires CAs to update their operations and SSL certificate issuance to comply with version 1.1 of the BRs. The BRs provide clear standards for CAs on important subjects including verification of identity, certificate content and profiles, CA security, revocation mechanisms, and use of algorithms and key sizes. As of February 2013, SSL certificate issuance must be audited according to the BR criteria, but initial BR audits for each CA and subCA that include a reasonable list of exceptions will be considered and potentially accepted.

Mozilla sent a CA Communication in January requesting that CAs review the draft of version 2.1 of Mozilla’s CA Certificate Policy and evaluate their current operations in regards to the Baseline Requirements. Responses to this communication are publicly posted and discussed in the mozilla.dev.security.policy forum. CAs are planning to complete their necessary system and documentation upgrades according to the grace periods that Mozilla provided. Many CAs continue to diligently work towards compliance with the BRs, the most common effort being to implement OCSP. Additionally, we asked CAs to scan their certificate databases to identify and revoke certificates that were not issued in accordance with certain recommended practices.

With these updates to Mozilla’s CA Certificate Policy, we re-iterate our belief that each root is ultimately accountable for every certificate it signs, directly or through its subordinates. Participation in Mozilla’s root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe, up to and including the removal of root certificates that mis-issue, as well as any roots that cross-sign them. Nevertheless, we believe that security is best served when browsers and CAs can work together; we hope that frank communication and clear expectations can resolve these issues before any such action is required. We must also be diligent in looking for new ways to improve the security systems of the web. Those systems are built on the trust of web users, and we all have a responsibility to be strong stewards of that trust.

 

Mozilla Security Team

One comment on “Announcing Version 2.1 of Mozilla CA Certificate Policy”

  1. Mark Doliner wrote on

    Thank you! The global https ecosystem is incredibly important, and this sounds like a great step in the right direction.