<br /><br />
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.
<br /><br />
ACTION 1: Disclose Use of Methods 18.104.22.168.9 or 22.214.171.124.10 for Domain Validation
<br /><br />
On 9-January, the CA “Let’s Encrypt” disclosed a vulnerability in the ACME domain validation methods known as TLS-SNI-01 and TLS-SNI-02, which are implementations of the more general method described in Baseline Requirements 126.96.36.199.10.  A subsequent vulnerability was disclosed on 11-January affecting the validation method described in BR 188.8.131.52.9.  Mozilla expects all CAs to be monitoring discussion in the mozilla.dev.security.policy forum and for any CA that employs either of these methods to disclose that fact on the list. From now on, Mozilla expects that CAs will not use these methods unless they have implemented and disclosed a mitigation for the vulnerabilities that have been discovered.
<br /><br />
 https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ<br />
<br /><br />
* We have never used these methods and our CP/CPS states that we do not use these methods of domain validation.
* We have disclosed our use of these methods of domain validation on the mozilla.dev.security.policy forum and have either stopped using them or implemented and disclosed a mitigation for the vulnerabilities that have been discovered.
* None of our root(s) are enabled for websites (SSL) in Mozilla products.
* Other (please describe below)
ACTION 1 COMMENTS <br /><br /> ACTION 2: Disclose Use of Methods 184.108.40.206.1 or 220.127.116.11.5 for Domain Validation <br /><br /> On 19-December, significant concerns were raised about the reliability of the domain validation methods specified in BR 18.104.22.168.1 and 22.214.171.124.5.  Since then, discussions on the CA/Browser Forum Public list have resulted in a proposed ballot to prohibit the use of these methods after 1-August 2018.  Rather than accept the risk of continued use of these methods, Mozilla may decide to set an earlier deadline such as 1-March 2018. If your CA uses either of these methods, please evaluate your implementation for vulnerabilities, follow the discussion closely, and be prepared to quickly discontinue your use of these methods of domain validation. <br /><br />  https://cabforum.org/pipermail/public/2017-December/012630.html<br />  https://cabforum.org/pipermail/public/2018-January/012819.html <br /><br /> Responses:<br /> * We have no valid certificates that were issued using these methods * We have active (not expired or revoked) certificates issued using BR 126.96.36.199.1, but we only use this method in a way that already complies with the proposed method 12 in CA/Browser Forum ballot 218. * We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. * We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. * None of our root(s) are enabled for websites (SSL) in Mozilla products. <br /> ACTION 2 COMMENTS (please include any exceptions to the option you selected above) <br /><br /> ACTION 3: Disclose All Non-Technically-Constrained Subordinate CA Certificates <br /><br /> Sections 5.3.1 and 5.3.2 of Mozilla Root Store Policy version 2.5  require CAs to publicly disclose (via CCADB ) all subordinate CA certificates including those used to issue email S/MIME certificates by 15-January unless they are technically constrained via both EKU and Name Constraints to a set of validated domains. We have since changed the compliance deadline to 15-April 2018. Certificate monitors have detected over 200 certificates that currently do not comply with this new policy.  Please ensure that your CA is in compliance before 15-April 2018. <br /><br />  https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/<br />  http://ccadb.org/cas/intermediates<br />  https://groups.google.com/d/msg/mozilla.dev.security.policy/sKhPTsIYNqs/Q-_ZKmDVAQAJ <br /><br /> Responses:<br /> * We are in compliance with this policy * We intend to comply with this policy before 15-April 2018<br /> ACTION 3 COMMENTS <br /><br /> ACTION 4: Complete BR Self Assessment <br /><br /> In our November 2017 CA Communication , Mozilla asked all CAs with roots enabled for websites (SSL) to complete a BR self-assessment  by 31-January and send it to Kathleen. If you have not yet done so, please complete this work. If you requested an extension, your deadline is 15-April 2018. <br /><br />  https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication<br />  https://wiki.mozilla.org/CA/BR_Self-Assessment <br /><br /> Responses: * Our BR Self Assessment has already been, or will be sent to Kathleen by 31-January 2018 * We previously requested an extension and intend to deliver our BR Self Assessment prior to 15-April 2018 * We are exempt from completing a BR Self Assessment because our root(s) are not enabled for websites (SSL) <br /> ACTION 4 COMMENTS <br /><br /> ACTION 5: Update CP/CPS to Comply with version 2.5 of Mozilla Root Store Policy <br /><br /> If you are one of the CAs that indicated in your response to the November 2017 CA Communication that you need more time to update your CP/CPS to comply with version 2.5 of the Mozilla Root Store Policy, please complete the updates no later than 15-April 2018. Mozilla feels that four months is more than long enough to make a CP/CPS change. <br /><br /> * Our CP/CPS already complies with Mozilla’s root store policy * Our CP/CPS will comply with Mozilla’s root store policy by 15-April 2018 <br /> ACTION 5 COMMENTS <br /><br /> ACTION 6: 825 Day Maximum Validity Period in SSL Certificates <br /><br /> On 17-March 2017, in ballot 193, the CA/Browser Forum set a deadline of 1-March 2018 after which newly-issued SSL certificates must not have a validity period greater than 825 days, and the re-use of validation information must be limited to 825 days. As with all other baseline requirements, Mozilla expects all CAs in the program to comply. <br /><br /> * We never have, or will no longer issue SSL certificates with a validity period greater than 825 days after 1-March 2018 * None of our root(s) are enabled for websites (SSL) in Mozilla products <br /> ACTION 6 COMMENTS
=== January 2018 Responses ===