Changes

Jump to: navigation, search

CA/Communications

2,846 bytes added, 16:59, 26 January 2018
January 2018 CA Communication: Changed to a survey format
'''***DRAFT***'''
<br /><br />
Dear Certification Authority,
<br /><br />
Because 2018 has already generated some important news for Certification Authorities, we are sending this message to ensure that every CA in the Mozilla program is aware of the following current events and impending deadlines:.
<br /><br />
1. On 9-January, the CA “Let’s Encrypt” disclosed This survey requests a vulnerability in the ACME domain validation method known as TLS-SNI-01, which is an implementation set of the more general method described in BR 3.2.2.4.10. [1] A subsequent vulnerability was disclosed actions on 11-January affecting the validation method described your behalf, as a participant in BR 3.2.2.4.9. [2] Mozilla expects all CAs to be monitoring discussion in the mozilla.dev.security.policy forum and for any 's 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 discoveredCertificate Program.
<br /><br />
2. On 19-DecemberTo respond to this survey, significant concerns were raised about login to the reliability of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. [3] Since thenCommon CA Database (CCADB), discussions click on the 'CA/Browser Forum Public list have resulted in a proposed ballot to prohibit Communications (Page)' tab, and select the use of these methods after 1-August 'January 2018CA Communication' survey. [4] If Please enter your CA uses either of these methods, please evaluate your implementation for vulnerabilities and be prepared to discontinue their use prior to the deadline if ballot 218 succeedsresponse by 9-February 2018.
<br /><br />
3. Sections 5.3.1 and 5.3.2 A compiled list of Mozilla Root Store Policy version 2.5 [5] require CAs to publicly disclose (via CCADB [6]) all subordinate CA certificates including those used responses to issue email S/MIME certificates the survey action items will be automatically and immediately published by 15-January unless they are technically constrained to a whitelist of 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. [7] Please ensure that your CA is in compliance before 15-April 2018CCADB system.
<br /><br />
4. In Participation in Mozilla's CA Certificate Program is at our November 2017 CA Communication [8]sole discretion, Mozilla asked all CAs with roots enabled for websites (SSL) to complete a BR self-assessment [9] by 31-January and send it we will take whatever steps are necessary to Kathleenkeep our users safe. If you have not yet done soNevertheless, please complete this we believe that the best approach to safeguard that security is to workwith CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. If Thank you requested an extension, for your deadline is 15-April 2018cooperation in this pursuit.
<br /><br />
5ACTION 1: Disclose Use of Methods 3.2.2.4.9 or 3. 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 CPS to comply with version 2.5 of the Mozilla Root Store Policy, please complete the updates no later than 15-April 20182. Mozilla feels that four months is more than long enough to make a CPS change4.10 for Domain Validation
<br /><br />
6. On 179-March 2017, in ballot 193January, the CA/Browser Forum set “Let’s Encrypt” disclosed a deadline of 1vulnerability in the ACME domain validation methods known as TLS-SNI-01 and TLS-March 2018 after which newlySNI-issued SSL certificates must not have a validity period greater than 825 days02, and which are implementations of the remore general method described in Baseline Requirements 3.2.2.4.10. [1] A subsequent vulnerability was disclosed on 11-use of January affecting the validation information must method described in BR 3.2.2.4.9. [2] Mozilla expects all CAs to be limited monitoring discussion in the mozilla.dev.security.policy forum and for any CA that employs either of these methods to 825 daysdisclose that fact on the list. As with all other baseline requirementsFrom now on, Mozilla expects all that CAs in will not use these methods unless they have implemented and disclosed a mitigation for the program to complyvulnerabilities that have been discovered.
<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[1] https://groups.google.com/d/msg/mozilla.dev. 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 pursuitpolicy/RHsIInIjJA0/LKrNi35aAQAJ<br />[2] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PiOiGCyuxCU
<br /><br />
RegardsResponses:<br />* We have never used these methods and our 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.* We have not yet disclosed our use of either of these methods,but will do so immediately.
<br />
Wayne ThayerACTION 1 COMMENTS<br /><br />ACTION 2: Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation<br /><br />On 19-December, significant concerns were raised about the reliability of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. [3] 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. [4] 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 Program Manager 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 />
[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ<br />[2] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PiOiGCyuxCU<br />[3] https://cabforum.org/pipermail/public/2017-December/012630.html<br />
[4] https://cabforum.org/pipermail/public/2018-January/012819.html
<br /><br />
Responses:<br />
* We have never used these methods and our CPS states that we do not use these methods.
* We use these methods or are permitted by our CPS to use these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below.
* We use these methods or are permitted by our CPS to use 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.
<br />
ACTION 2 COMMENTS<br /><br />ACTION 3: Disclose All Subordinate CA Certificates<br /><br />Sections 5.3.1 and 5.3.2 of Mozilla Root Store Policy version 2.5 [5] require CAs to publicly disclose (via CCADB [6]) all subordinate CA certificates including those used to issue email S/MIME certificates by 15-January unless they are technically constrained to a whitelist of 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. [7] Please ensure that your CA is in compliance before 15-April 2018.<br /><br />[5] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/<br />[6] http://ccadb.org/cas/intermediates<br />[7] 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 [8], Mozilla asked all CAs with roots enabled for websites (SSL) to complete a BR self-assessment [69] httpby 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 />[8] https://ccadbwiki.mozilla.org/casCA/intermediatesCommunications#November_2017_CA_Communication<br />[9] https://wiki.mozilla.org/CA/BR_Self-Assessment<br /><br />Responses:* We have already delivered our BR Self Assessment to Kathleen* We intend to deliver our BR Self Assessment prior to the deadline* We are exempt from completing a BR Self Assessment because our root(s) are not enabled for websites (SSL)
<br />
[7] https:ACTION 4 COMMENTS<br /><br /groups.google.com>ACTION 5: Update CPS to Comply with Mozilla Policy<br /d><br /msg/mozilla>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 CPS to comply with version 2.dev5 of the Mozilla Root Store Policy, please complete the updates no later than 15-April 2018.securityMozilla feels that four months is more than long enough to make a CPS change.policy<br /sKhPTsIYNqs><br /Q>Our CPS already complies with Mozilla’s root store policyOur CPS will comply with Mozilla’s root store policy by 15-_ZKmDVAQAJApril 2018[8] https:<br /><br /wiki.mozilla.org>ACTION 5 COMMENTS<br /CA><br /Communications#November_2017_CA_Communication>[9] httpsACTION 6:825 Day Validity Period<br /><br />On 17-March 2017, in ballot 193, the CA/wikiBrowser 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.mozillaAs with all other baseline requirements, Mozilla expects all CAs in the program to comply.org<br /CA><br /BR_Self>We never have, or will no longer issue SSL certificates with a validity period greater than 825 days after 1-AssessmentMarch 2018<br /><br />ACTION 6 COMMENTS
== November 2017 CA Communication ==
136
edits

Navigation menu