September 2018 CA Communication

 

Dear Certification Authority,

Mozilla’s Root Store Policy was recently updated. The 2.6.1 version went into effect on 1-July 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).

As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.

To respond to this survey, log in to the Common CA Database (CCADB), click on the 'CA Communications (Page)' tab, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.

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

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.

Regards,
Wayne Thayer
Mozilla CA Program Manager

ACTION 1: Review Mozilla Root Store Policy

Read version 2.6.1 of Mozilla’s Root Store Policy. (Required)

ACTION 1 COMMENTS

ACTION 2: Update CP/CPS

Ensure that your CP/CPS complies with the following requirements that were added to version 2.6.1 of Mozilla’s Root Store Policy:
* Section 2.2 “Validation Practices” now requires CAs with the Mozilla email trust bit to clearly disclose their email address validation methods in their CP/CPS.
* Methods used for IP Address validation must now be clearly specified in your CP/CPS.
* The use of BR validation method 3.2.2.5(4), the “any other method” for IP addresses, has been banned for validating a domain name under 3.2.2.4(8). If your CP/CPS specifies the use of IP address validation method 3.2.2.5(4) “any other method”, please make it clear that it will not be used in conjunction with domain validation method 3.2.2.4(8) “IP Address”. (Required)

ACTION 2 COMMENTS

ACTION 3: Transition to Separate Intermediate Certificates for SSL and S/MIME

Section 5.3 of version 2.6.1 of Mozilla’s Root Store Policy requires intermediate certificates issued after 1-January 2019 to be constrained by EKU to prevent use of the same intermediate certificate to issue both SSL (serverAuth) and S/MIME (emailProtection) certificates. (Required)

ACTION 3 COMMENTS

ACTION 4: Ensure Audit Reports comply with Mozilla’s Root Store Policy

Version 2.5 of Mozilla’s Root Store Policy added detailed requirements for audit reports to section 3.1.4. Mozilla is now rejecting audit reports that do not comply with these requirements. Note that version 2.6.1 of the policy added the following clarification to section 5.3.2 for newly-issued intermediates that are not technically constrained: “If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports.” (Required)

ACTION 4 COMMENTS

ACTION 5: Discontinue use of BR Validation Methods 3.2.2.4.1 and 3.2.2.4.5

CA/Browser Forum ballot 218 set a deadline of 1-August 2018 for CAs to discontinue use of BR domain validation methods 3.2.2.4.1 “Validating the Applicant as a Domain Contact” and 3.2.2.4.5 “Domain Authorization Document” (Required)

ACTION 5 COMMENTS

ACTION 6: Disclose Intermediate Certificates

Later this year, we plan to begin preloading the certificate database shipped with Firefox with all intermediate certificates disclosed in the CCADB. This is an alternative to “AIA chasing” designed to reduce the incidence of “unknown issuer” errors caused by server operators neglecting to include intermediate certificates. Updates to the database will be provided for Firefox users on a regular basis.

We rely on CAs to add new intermediate CA certificates to CCADB within a week of certificate creation, and before any such subordinate CA is allowed to issue certificates, as required by section 5.3.2 of our policy. (Required)

ACTION 6 COMMENTS

ACTION 7: Submit TLS Certificates to CT Logs for Mozilla's CRLite

Later this year, Mozilla is planning to begin testing a new certificate validation mechanism called CRLite. Revocation checking for both leaf and intermediate certificates will be performed via CRLite, but it does not replace OneCRL. When Firefox users load a website supported by CRLite, the browser will not need to fetch OCSP status, which should reduce bandwidth requirements for participating CAs as well as increase performance of the website. In order for CRLite to function properly, Mozilla must know about every TLS certificate that will utilize CRLite for revocation checking. Mozilla might only enable CRLite for CAs that log all TLS certificates issued under their included roots. While Mozilla does not currently have a policy requiring Certificate Transparency (CT) logging, we would like to know if it is reasonable to expect that all newly issued TLS certificates from all CA certificates in the Mozilla program are being logged. (Required)

ACTION 7 COMMENTS