April 2017 CA Communication


Dear Certification Authority,

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.

To respond to this survey, login to the Common CA Database (CCADB), click on the 'CA Communications (Page)' tab, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.

A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.

In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Kathleen Wilson
Mozilla CA Program Manager


Update your CA's CP, CPS, and process documentation as necessary to clearly indicate the methods of domain validation that may be used. Currently, the only permitted methods of domain validation are those documented in section of version 1.4.1 (and not any other version) of the CA/Browser Forum's Baseline Requirements (BRs) . Section of version 1.4.1 of the BRs provides 10 different ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate, and your CP/CPS must clearly specify the procedures that the CA employs. Each documented procedure should state which subsection of it is complying with.

Note that version 1.4.2 of the BRs does not contain all 10 of these methods, but it does contain section, "Other Methods", so the methods that were removed in version 1.4.2 of the BRs are still BR-compliant under that version. By Mozilla policy, CAs are not permitted to rely on the "Other Methods" section to use methods of domain validation that are not among the 10 listed in section of version 1.4.1 of the BRs.

The IPR issues relating to the missing methods have been resolved, so Mozilla expects that they will soon be restored. When they are, Mozilla's policy will once again be that we accept all of the methods of domain validation explicitly listed in the latest version of the BRs.

Please enter the date by which your CP/CPS will be updated to meet the above requirements (use format MM/DD/YYYY). Date must be before July 21, 2017. If your CA's included root certificates do not have the Websites trust bit enabled, then use the date 01/01/2015. (Required)



The CA/Browser Forum's Baseline Requirements (BRs) state: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."

Please make sure your CP and CPS are reviewed and updated as necessary at least once every year. You should indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.

A template for performing BR Self Assessments is here: https://wiki.mozilla.org/CA:BRs-Self-Assessment
- (Required)


Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been published. Differences between versions 2.4 and 2.3 (published Dec 2016), and between versions 2.4 and 2.2 (published July 2013) may be viewed on Github. Version 2.4.1 contains exactly the same normative requirements as version 2.4 but has been completely reorganized. Please review version 2.4.1 of Mozilla's CA Certificate Policy and confirm that your CA complies with it.

Please note:
+ In addition to audit statements, the CP and CPS documents need to be submitted to Mozilla each year.
+ As of June 1, 2017, the audit, CP, and CPS documents must be provided in English, translated if necessary.
+ All submitted documentation must be openly licensed (see the policy for the exact options and terms).
+ Version 2.4 of Mozilla's CA Certificate Policy incorporates by reference the Common CCADB Policy and the Mozilla CCADB Policy.
+ The new CCADB Policy makes official a number of existing expectations regarding the CCADB.
+ The applicable versions of some audit criteria have been updated.
+ There are additional requirements on OCSP responses.
+ 64 bits of entropy is required in certificate serial numbers.
+ The requirements in both version 2.4 and 2.4.1 are immediately applicable, except for the document translation requirement which is required by June 1, 2017.

Please confirm that you have reviewed version 2.4.1 of Mozilla's CA Certificate Policy. (Required)



Mozilla's CA Certificate Policy requires CAs to provide updated statements annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. CAs must now provide this information directly via the Common CA Database.

Confirm that a representative of your CA has logged into the Common CA Database, and understands how to create an Audit Case. (Required)



All audit statements or audit transmittal letters submitted to Mozilla MUST be public-facing (not confidential), provided in English, and must include:

+ Name of the company being audited
+ Name and address of the organization performing the audit
+ Audit period start and end dates -- An audit period is the period of time of CA operations that were examined by the auditor. Audit Periods must not exceed one year in length, and must be contiguous.
+ Audit statement date, which must be within 90 days of the audit period end date
+ Audit criteria (including version number) that were used
+ CA policy documents (with version numbers) referenced during the audit
+ Distinguished name (Certificate Subject Field) and SHA1 or SHA256 fingerprint of each certificate issuer covered by the audit scope
+ Clear indication of which in-scope certificate issuers are self-signed.
+ The word "clean" must be included in audit statements for which no problems were noted.
+ For ETSI - the attestation should additionally state if the audit was a full audit, and must indicate which parts of the criteria applied (e.g. DVCP, OVCP, PTC-BR, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), Part 2 (Requirements for trust services Providers issuing EU qualified certificates)).

It is the CA's responsibility to communicate these requirements to their auditors. (Required)



When an auditor finds non-compliance with the audit criteria, the audit statement should clearly indicate the word "qualified", and clearly identify the controls that failed. The auditor should provide qualified reports for all time periods until the problems have been fixed.

Period-of-time audit statements are required to cover audit periods that are less than one year and are contiguous. In other words, there should never be a time gap between the audit periods indicated in period-of-time audit statements.

Point-in-time audit statements may be used to confirm that all of the problems that the auditor previously identified in a qualified audit statement have been corrected. However, a point-in-time assessment does *not* replace the period-of-time assessment. (Required)



Resolve all of your CA's Bugzilla Bugs regarding BR Compliance and Incidents, as listed here: https://wiki.mozilla.org/CA/ca-bugs (Required)


Review your CA's response to the previous CA Communication here: https://wiki.mozilla.org/CA:Communications#March_2016_Responses

Please confirm completion of those action items by checking the boxes below. (Required)



Does your CA have any third-party Registration Authorities (RA)s that your CA relies on to perform the domain validation as required under Section of the CA/Browser Forum's Baseline Requirements?

If so, please tell us about the program, including:
* How many companies are involved
* What measures you have in place to ensure this work is done to an appropriate standard (Required)


Your attention is drawn to the cablint and x509lint tools, which you may wish to incorporate into your certificate issuance pipeline to get early warning of circumstances when you are issuing certificates which do not meet the Baseline Requirements (certlint) or X509 standards (x509lint).

- (Required)


The CA/Browser Forum recently passed ballot 187, which updated the Baseline Requirements to make DNS Certification Authority Authorization (CAA) checking per RFC 6844 mandatory at time of certificate issuance in almost all circumstances.

Please provide a list of the domain names which your CA plans to recognize in a CAA record's issue and issuewild property tags as permitting it to issue. Mozilla plans to make a central list of identifiers, so please explain if certain identifiers are only permitted under certain circumstances. (Required)


Please explain how your CA meets the following requirement from section 4.9.3 of the CA/Browser Forum's Baseline Requirements.

"The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means."

Mozilla plans to make a central list of these mechanisms.

Please detail both the mechanism and the location(s) where you publicly disclose this information. You are encouraged to make an email address at least one of your provided options. (Required)


Does your CA issue SHA-1 S/MIME certificates? If so, please explain your plans for ceasing to do so, and any self-imposed or external deadlines you are planning to meet. Mozilla plans to make policy in this area in the future, so please explain any facts or constraints which you think might be relevant to our considerations. (Required)


Your attention is drawn to the CA/Browser Forum ballot 193, which recently passed. This reduces the maximum permissible lifetime of certificates from 39 to 27 months, as of 1st March 2018. In addition, it reduces the amount of time validation information can be reused, from 39 to 27 months, as of 31st March 2017. Please be aware of these deadlines so you can adjust your practices accordingly.

Mozilla is interested in, and the CA/Browser Forum continues to discuss, the possibility of further reductions in certificate lifetime. We see a benefit here in reducing the overall turnover time it takes for an improvement in practices or algorithms to make its way through the entire Web PKI. Shorter times, carefully managed, also encourage the ecosystem towards automation, which is beneficial when quick changes need to be made in response to security incidents. Specifically, Mozilla is currently considering a reduction to 13 months, effective as of 1st March 2019 (2 years from now). Alternatively, several CAs have said that the need for contract renegotiation is a significant issue when reducing lifetimes, so in order that CAs will only have to do this once rather than twice, another option would be to require the reduction from 1st March 2018 (1 year from now), the current reduction date.

If you are unable to support a comprehensive reduction in issuance lifetime, please explain the impact you see of Mozilla (and potentially other browsers) removing trust from certificates of lifetime > 13 months in the same sort of timeframe. This would mean browser-facing certificates would need to have shorter lifetimes, but those certificates not issued for trust by browsers could have longer lifetimes. (Required)