All, Below is a draft survey about Mozilla Root Store Policy v. 2.8 that I will be sending through the CCADB mailer to all CAs in the Mozilla program. I also have a cover letter for the CA communication, which is boilerplate similar to that used in previous CA communications - see e.g. https://wiki.mozilla.org/CA/Communications. Please review this draft survey and provide any feedback you may have.
Thanks! Ben April 2022 CA Communication Survey ITEM 1: Mozilla Root Store Policy (MRSP), version 2.8 Please read version 2.8 of Mozilla’s Root Store Policy [link] (MRSP). CAs are expected to comply without exception with MRSP v.2.8. CAs MUST review this policy and ensure compliance, and CAs SHOULD carefully review the differences from version 2.7.1 of Mozilla's policy [link]. These changes have been discussed on Mozilla’s dev-security-policy mailing list [link]. CAs that did not participate in these discussions or that have not yet reviewed these conversations should also read the discussions [link] and Github issues [link] regarding these changes, to reduce the chance of confusion or misinterpretation. 1- We have read, understand, and intend to fully comply with version 2.8 of Mozilla’s Root Store Policy. 2- We have read, understand, and intend to comply with version 2.8 of Mozilla’s Root Store Policy, except as described below. (Describe below) 3- We have questions or concerns with version 2.8 of Mozilla’s Root Store Policy (Describe below) 4- Other (Describe below) ITEM 2: Incidents The first paragraph of MRSP section 2.4 (Incidents) is being amended to read, “When a CA operator fails to comply with any requirement of this policy - whether it be a misissuance, a procedural or operational issue, or any other variety of non-compliance - the event is classified as an incident and MUST be reported to Mozilla as soon as the CA operator is made aware. At a minimum, CA operators MUST promptly report all incidents to Mozilla in the form of an Incident Report <https://wiki.mozilla.org/CA/Responding_To_An_Incident>. Any matter documented in an audit as a qualification, a modified opinion, or a major non-conformity is also considered an incident and MUST have a corresponding Incident Report. CA operators MUST regularly update the Incident Report until the corresponding bug is marked as resolved in the mozilla.org Bugzilla <https://bugzilla.mozilla.org> system by a Mozilla representative. CAs SHOULD cease issuance until the problem has been prevented from reoccurring.” (Emphasis added.) 1- We already have created Incident Reports for all matters described in MRSP section 2.4, and will promptly file new Incident Reports when we become aware of such situations or receive a modified opinion in an audit statement. 2- We will ensure that Incident Reports are promptly filed in Bugzilla for all matters described in MRSP section 2.4 as “incidents”. 3- We have questions or concerns about Mozilla’s expectations regarding the reporting of incidents. (Describe below) 4- Other (Describe below) ITEM 3: Auditors As of May 1, 2022, MRSP section 3.2 requires that ETSI auditors be members of the Accredited Conformity Assessment Bodies' Council (ACAB’c) and that WebTrust auditors be enrolled by CPA Canada as WebTrust practitioners. 1- Our auditors already meet this requirement. 2- Our auditors do not yet meet this requirement, but they will before we submit our next audit report. 3- We have questions or concerns about this requirement. (Describe below) 4- Other (Describe below) ITEM 4: CPs and CPSes Please refer to the following language that has been added to MRSP section 3.3: “7. CA operators SHALL maintain links to older versions of each CP and CPS (or CP/CPS), regardless of changes in ownership or control of the root CA, until the entire root CA certificate hierarchy operated in accordance with such documents is no longer trusted in the Mozilla root program.” 1- We already maintain links to our archived CPs and CPSes and can do so until the root CA hierarchy is no longer trusted by Mozilla. 2- We do not yet meet this requirement, but we will before the following date: [date] 3- We have questions or concerns about this requirement. (Describe below) 4- Other (Describe below) ITEM 5: Full CRL Issued By This CA Before October 1, 2022, intermediate CA certificates capable of issuing TLS certificates are required to populate the CCADB fields under "Pertaining to Certificates Issued by This CA" with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs" (that is equivalent to the Full CRL for certificates issued by this CA). 1- We are aware of this requirement and have completed this task in the CCADB. 2- We understand this requirement, and by October 1, 2022, we will populate the "Full CRL Issued By This CA" or the "JSON Array of Partitioned CRLs" CCADB field. 3- We will not be able to meet this date because: (Describe below) 4- We have questions or concerns about this requirement. (Describe below) 5- Other (Describe below) ITEM 6.1: SHA1 sunsetting - Email certificates MRSP § 5.1.3 says: “Effective July 1, 2022, CAs SHALL NOT sign SHA-1 hashes over end-entity certificates with an EKU extension containing the id-kp-emailProtection key purpose.” 1- We already do not use the SHA-1 algorithm when signing email certificates that are in scope of MRSP. 2- Before July 1, 2022, we will cease using the SHA-1 algorithm when signing email certificates that are in scope of MRSP. 3- We will not be able to cease using the SHA-1 algorithm for signing email certificates that are in scope of MRSP by July 1, 2022, because: (Describe below) 4- We have questions or concerns about this requirement. (Describe below) 5- Other (Describe below) ITEM 6.2: SHA1 sunsetting - CRL, OCSP MRSP § 5.1.3 says that effective July 1, 2023, CAs that are in scope of MRSP will be prohibited from using the SHA-1 algorithm to sign CRLs, OCSP responses, OCSP responder certificates, or CA certificates. 1- Our CAs that are in scope of MRSP already do not use the SHA-1 algorithm to sign CRLs, OCSP responses, OCSP responder certificates, or CA certificates. 2- Before July 1, 2023, our CAs that are in scope of MRSP will cease using the SHA-1 algorithm when signing CRLs, OCSP responses, OCSP responder certificates, or CA certificates. 3- We will not be able to cease using the SHA-1 algorithm for signing CRLs, OCSP responses, OCSP responder certificates, or CA certificates by July 1, 2023, because: (Describe below) 4- We have questions or concerns about this requirement. (Describe below) 5- Other (Describe below) ITEM 7: Publicly Disclose All Intermediate Certificates According to MRSP section 5.3.2, all CA certificates capable of issuing working server or email certificates must be reported in the CCADB by July 1, 2022, even if they are technically constrained. 1- The CCADB already contains all our CA certificates capable of issuing working server or email certificates, including those that are technically constrained. 2- We will meet this requirement before July 1, 2022. 3- We will not be able to disclose all of our CA certificates (capable of issuing working server or email certificates) in the CCADB before July 1, 2022, because: (Describe below) 4- We have questions or concerns about this requirement. (Describe below) 5- Other (Describe below) ITEM 8: Precertificates MRSP § 5.4 explains that the issuance of a Certificate Transparency precertificate is considered by Mozilla to be a binding intent to issue a certificate. Therefore, the issuance of a precertificate that does not comply with the MRSP is equal to the misissuance of a certificate; a CA must be able to revoke a certificate presumed to exist because of a corresponding precertificate; and a CA must provide CRL and OCSP services and responses in accordance with the MRSP for certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist. 1- We are aware of these requirements concerning precertificates and already comply fully with them. 2- We are aware of these requirements concerning precertificates and intend to comply fully with them. 3- We have questions or concerns with these requirements concerning precertificates. (Describe below) 4- Other (Describe below) ITEM 9: CRL Revocation Reasons for TLS Certificates MRSP section 6.1.1 applies to revocations that are performed after October 1, 2022. (Revocation entries that appeared on CRLs prior to October 1, 2022, do NOT need to be changed as a result of this requirement.) Also, before October 1, 2022, CA operators will need to update their subscriber agreement forms and the tools they make available to subscribers to effectuate certificate revocation. MRSP section 6.1.1 says, “When an end-entity TLS certificate (i.e. a certificate capable of being used for TLS-enabled servers) is revoked for one of the reasons below, the specified CRLReason MUST be included in the reasonCode extension of the CRL entry corresponding to the end-entity TLS certificate. When the CRLReason code is not one of the following, then the reasonCode extension MUST NOT be provided. * keyCompromise (RFC 5280 CRLReason #1) * privilegeWithdrawn (RFC 5280 CRLReason #9)** * cessationOfOperation (RFC 5280 CRLReason #5) * affiliationChanged (RFC 5280 CRLReason #3) * superseded (RFC 5280 CRLReason #4)” 1- We have read all of the new MRSP section 6.1.1, and we will comply beginning October 1, 2022. 2- We have read the new MRSP section 6.1.1, and we cannot comply by October 1, 2022, because: (Describe below) However, we can meet this requirement by the date indicated. [Date] 3- We have questions or concerns about this requirement. (Describe below) 4- Other (Describe below) ITEM 10: Externally-Operated Subordinate CAs All new CA operators that will operate a subordinate CA externally must be approved through a review-and-comment process. Please read MRSP section 8.4 [link] for details and review https://wiki.mozilla.org/CA/External_Sub_CAs#Process_for_non-Technically-Constrained_Subordinate_CAs 1- We have read and will comply with the new MRSP section 8.4 and the Process for non-Technically Constrained Subordinate CAs <https://wiki.mozilla.org/CA/External_Sub_CAs#Process_for_non-Technically-Constrained_Subordinate_CAs> . 2- We have questions or concerns about this requirement. (Describe below) 3- Other (Describe below) -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabXyvxk45CaWOfjm7HWu%3DT_4C2wrcYrGr9ddN0aZ30ivQ%40mail.gmail.com.
