Greetings All, I am finalizing a mass email communication and survey to be sent to CA operators that are either seeking root inclusion or that have CA certificates currently trusted in Mozilla's Root Store. The purpose of such communication is to inform CA operators of proposed amendments to the Mozilla Root Store Policy (MRSP) - version 3.0 and to gather CA operator feedback on key issues related to compliance and implementation.
Community input has always been invaluable in shaping Mozilla’s policies to ensure they are effective, clear, and practical for all stakeholders. I greatly appreciate the time and effort this community invests in providing thoughtful feedback, and I strongly encourage you to review the draft CA communication and survey below. Your insights are critical to ensuring the final version that we send to CA operators is as comprehensive and impactful as possible. Comments and suggestions must be submitted by 1:00 UTC Saturday, February 1, 2025. Thank you in advance for your feedback and for your continued dedication to strengthening the security and trustworthiness of the Web PKI ecosystem. Best regards, Ben Wilson Mozilla Root Store Program Manager Date: Monday, February 3, 2025 Subject: Upcoming Changes to Mozilla Root Store Policy Version 3.0 – Feedback and Survey Request Dear Certification Authority Operator, As part of Mozilla's commitment to maintaining a secure and transparent Web PKI ecosystem, we are finalizing amendments to the Mozilla Root Store Policy (MRSP), version 3.0. To ensure the policy meets its objectives while addressing CA concerns, we invite you to review the proposed changes and provide answers via a short survey that will help guide our finalization of MRSP v3.0. Your organization must respond to the survey prior to 1:00 UTC, Saturday, February 15, 2025. [Note to reviewers: We anticipate that CA operators will provide answers to the survey questions asked below using a Google form.] MRSP v3.0 will be published in its final form the week of February 17-21, with an effective date of March 1, 2025. Please review the proposed new requirements to ensure that you have sufficient time to fully comply. Please note: Relevant to items 1 and 2 below, the Mozilla Root Store Policy will more fully incorporate the new CCADB incident reporting guidelines. See: https://github.com/ryancdickson/www.ccadb.org/blob/incident-reporting-fall-2024-v3/cas/incident-report.md Executive Summary: Updates to requirements in five key areas: 1. Incident Reporting: More complete incorporation of CCADB Incident Reporting Guidelines 2. Delayed Revocation Requirements: Proactive communication, subscriber agreements, mass revocation plans, third-party assessments, and incident reporting 3. Phase-Out of Dual-Purpose Roots: Transition to dedicated TLS or S/MIME roots by December 31, 2028 4. Key Lifecycle Management: Audit requirements for parked keys 5. Automation: New TLS roots must support automated issuance Miscellaneous updates: clarifications re: P-521 curve support and re: CP/CPS compliance with RFC 3647 -------------------- 1. Incident Reporting (GitHub Issues #270 <https://github.com/mozilla/pkipolicy/issues/270>, #271 <https://github.com/mozilla/pkipolicy/issues/271>) Incorporates the CCADB Incident Reporting Guidelines (IRGs) by reference. (By the time MRSP v. 3.0 becomes effective, the IRGs will be version 2.1.) The first paragraph of MRSP section 2.4 will read: 2.4 Incidents 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 <https://wiki.mozilla.org/CA/Responding_To_An_Incident>. Any matter documented in an audit as a qualification, a modified opinion, or non-conformity is also considered an incident. This policy incorporates by reference the CCADB's Incident Reporting Guidelines <https://www.ccadb.org/cas/incident-report> (IRGs) as if fully set forth herein. As such, CA operators MUST report all incidents within 72 hours of the CA being made aware, and if a Full Incident Report is not yet ready, the CA operator MUST provide a Preliminary Incident Report. Full Incident Reports MUST be posted within 14 days of the incident’s initial disclosure. CA operators MUST update Incident Reports and respond to questions or comments in accordance with the IRGs until the corresponding Bugzilla <https://bugzilla.mozilla.org> bug is closed. Survey Questions - Incident reporting What challenges, if any, do you anticipate in meeting the 72-hour preliminary incident reporting requirement and the 14-day full incident reporting requirement? [Free-text response] -------------------- 2. Delayed Revocation of TLS Certificates (GitHub Issue #276 <https://github.com/mozilla/pkipolicy/issues/276>) Proposed language reads: 6.1.3 Delayed Revocation Mozilla’s goal is to ensure that revocation occurs as swiftly as possible while maintaining the overall security and stability of the web. Mozilla does not grant exceptions to the revocation requirements of the TLS BRs. To ensure compliance with the TLS BRs, Mozilla requires that CA operators: - engage in proactive communication and advise subscribers well in advance about the revocation timelines and explicitly warn them against using publicly-trusted TLS server certificates on systems that cannot tolerate timely revocation; - include appropriate language in customer agreements requiring subscribers’ timely cooperation in meeting revocation timelines and acknowledging the CA’s obligations to adhere to applicable policies and standards; - prepare and maintain comprehensive and actionable plans to address mass revocation events, including detailed procedures for handling mass revocations effectively, including rapid communication with affected parties and conducting annual plan testing; and - engage a third party assessor to evaluate whether the CA Operator has: - well-documented and actionable plans to handle mass revocation events; - demonstrated the implementation and feasibility of the plans through testing exercises, including documentation of testing processes, timelines, results, and remediation steps; and - incorporated feedback from such testing exercises and other evaluations to enhance readiness and improve future performance. Section 2.4 of this policy incorporates by reference the CCADB's Incident Reporting Guidelines <https://www.ccadb.org/cas/incident-report>. It has reporting requirements that MUST be followed by CA operators who determine they might delay revocation of certificates beyond the time period required by the TLS BRs. For instance, the Analysis field in the Impact section of such incident reports MUST explain "the factors and rationales behind the decision to delay revocation (including detailed and substantiated explanations of how extensive harm would result to third parties–such as essential public services or widely relied-upon systems–and why the situation is exceptionally rare and unavoidable)." All delayed revocation incidents MUST be listed as findings in the CA operator’s next TLS BR audit statement. Repeated incidents of delayed revocation without sufficient justification will result in heightened scrutiny and sanctions, which may include removal of the CA from the Mozilla Root Store. Survey Questions - Delayed Revocation What challenges, if any, do you anticipate in proactively communicating revocation timelines to subscribers and advising them against using publicly-trusted TLS certificates on systems that cannot tolerate timely revocation? [Free-text response] What challenges, if any, do you anticipate in changing your agreements and subscriber management processes to ensure that customer agreements explicitly require timely cooperation from subscribers and that they acknowledge that your organization must adhere to applicable policies, standards, and CA obligations? [Free-text response] What challenges, if any, do you anticipate in maintaining and testing a comprehensive, actionable plan for handling mass revocation events? [Free-text response] What challenges, if any, do you anticipate when engaging a third-party assessor to evaluate your mass revocation readiness, including documentation, testing, and feedback incorporation? [Free-text response] What support or guidance would help your organization implement this requirement? [Free-text response] Do you have a process in place to ensure that all delayed revocation incidents are fully documented and reported per the new CCADB Incident Reporting Guidelines? [Yes/No] If not, what additional resources or changes would be necessary to meet any of these requirements? [Free-text response] Do you foresee any other significant challenges in complying with any of these requirements? If so, please describe. [Free-text response] -------------------- 3. Phase-Out of Dual-Purpose (TLS/S/MIME) Root CAs (GitHub Issue #279 <https://github.com/mozilla/pkipolicy/issues/279>) Root CAs included in the Mozilla root store after January 1, 2025, must be dedicated to a single trust bit (either websites or email). Transition plans are required for existing dual-purpose roots by April 15, 2026. Full transition is required by December 31, 2028. Proposed language reads: 7.5 Dedicated Root Certificates CA operators with root certificates that have both websites and email trust bits enabled SHOULD consider the requirements in Section 7.4 (Root CA Lifecycles) when planning their compliance with the trust bit transitions outlined in this section. All root CA certificates added to Mozilla's Root Store after January 1, 2025, will only be trusted for either TLS server authentication (websites trust bit) or S/MIME email protection (email trust bit). Existing root CA certificates that do not comply with this requirement MUST transition to one or the other prior to December 31, 2028, i.e., by having one of their trust bits (websites or email) removed. 7.5.1 Server Authentication Hierarchies Subordinate CA and end entity certificates issued under a Root CA certificate added after January 1, 2025, with the websites trust bit enabled MUST include an extendedKeyUsage extension that asserts only id-kp-serverAuth or both id-kp-serverAuth and id-kp-clientAuth. OCSP signing certificates are exempt from this EKU restriction and MUST only include the id-kp-OCSPSigning EKU. 7.5.2 S/MIME Hierarchies Subordinate CA and end entity certificates issued under a Root CA certificate added after January 1, 2025, with the email trust bit enabled MUST include an extendedKeyUsage extension that asserts id-kp-emailProtection. They MAY include other extendedKeyUsages, but they MUST NOT include extendedKeyUsages of id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, or anyExtendedKeyUsage. OCSP signing certificates are exempt from this EKU restriction and MUST only include the id-kp-OCSPSigning EKU. 7.5.3 Transition Plan for Existing Roots Root CA certificates included in Mozilla's Root Store as of January 1, 2025, that have both the websites and the email trust bits enabled MAY remain trusted after April 15, 2026, if the CA operator has submitted a transition plan by April 15, 2026, to migrate to dedicated hierarchies by December 31, 2028. Transition plans MAY include: 1. Submission of requests for inclusion of single-purpose roots; 2. Requests to remove the websites trust bit or the email trust bit from a dual-purpose root; 3. Timelines for phasing out conflicting uses of the root (e.g. dates by which inconsistent certificates will expire or issuance will cease); and 4. Revocation or replacement of certificates that do not meet the requirements of Sections 7.5.1 or 7.5.2. Survey Questions - Phase-Out of Dual-Purpose Roots If your organization has currently pending inclusion applications for root certificates with both the websites and email trust bits in Mozilla, what challenges do you anticipate with the revision of your inclusion request due to this policy? [Free-text response] If your organization currently operates root CAs that have both the websites and email trust bits enabled in Mozilla, please detail any challenges you will have in meeting the proposed transition timeline. [Free-text response] -------------------- 4. CA Key-Life-Cycle Auditing Requirements - “Parked Keys” (GitHub Issue #275 <https://github.com/mozilla/pkipolicy/issues/275>) New language is being added to section 3.1.3 that reads: CA private keys that have been generated but not yet associated with a CA certificate ("parked keys") MUST be identified by the SHA-256 hashes of their corresponding DER-encoded CA Public Keys and included in auditor-provided annual key lifecycle management reports (or a corresponding section of the CA operator's annual audit reports). These reports must account for the controls and measures applied to ensure the integrity, confidentiality, and protection of these keys throughout their lifecycle, consistent with the audit criteria cited above. Survey Questions - Parked Keys If you park CA keys, how do you maintain an inventory of them? [Free-text response] What challenges, if any, do you anticipate in providing the SHA-256 hashes of the public keys for parked CA key pairs in your annual audit reports? [Free-text response] What changes, clarifications, or alternative methods could help address these challenges while ensuring compliance? [Free-text response] How do your current audit processes address lifecycle management for parked CA keys, including ensuring their integrity, confidentiality, and protection from unauthorized disclosure or use? [Free-text response] What guidance, information, or resources do you believe are needed to provide to your auditors for them to effectively verify compliance with this requirement? [Free-text response] -------------------- 5. Automation Required for New TLS CAs (GitHub Issue #283 <https://github.com/mozilla/pkipolicy/issues/283>) A new paragraph is being added to section 7.1 (Inclusions): Additionally, CA operators applying for inclusion of new TLS-issuing root certificates MUST demonstrate support for at least one automated method of certificate issuance for each type of TLS certificate (EV, OV, DV, IV) intended to be issued under the root certificate being requested for inclusion. This means (1) automated domain control validation, as defined in the TLS Baseline Requirements; and (2) automated certificate issuance and retrieval processes. Such automated methods MUST minimize hands-on human input during routine certificate issuance and renewal processes and comply with the TLS Baseline Requirements, and EV Guidelines, if applicable. Acceptable "hands-on" input includes initial software setup, configuration, updates, and identity verification where required. CA operators MUST renew test certificates using such capability at least every 30 days to demonstrate compliance with these automation requirements. The test certificates MUST be served by publicly accessible websites, and the URL for each test site MUST be disclosed in the CCADB. Survey Questions - Automation For new TLS Root CAs, do you foresee any difficulties in complying with the requirement to disclose URLs for test certificates in the CCADB, including any potential challenges related to your current infrastructure or processes? [Free-text response] What concerns do you have about this provision, including its potential impact on your infrastructure or operations, that you believe should be addressed to ensure successful implementation? [Free-text response] What additional guidance, clarifications, or infrastructure considerations would help your organization effectively implement the automation requirements in this provision? [Free-text response] -------------------- 6. Miscellaneous: Clarify that P-521 is acceptable (GitHub Issue #281 <https://github.com/mozilla/pkipolicy/issues/281>) and RFC 3647 requirements for CPs/CPSes (GitHub Issue #263 <https://github.com/mozilla/pkipolicy/issues/263>) Section 5.1 of MRSP v. 3.0 will clarify that ECDSA keys using the P-521 curve is acceptable. Also, item 5 of Section 3.3 (CPs and CPSes) will state: all CPs, CPSes, and combined CP/CPSes MUST be structured according to the common outline set forth in section 6 of RFC 3647, as may be amended by the CA/Browser Forum's TLS BRs or its S/MIME BRs, and MUST: * include at least every section and subsection defined in section 6 of RFC 3647; * only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and * contain no sections that are entirely blank, having no text or subsections; Survey Questions - Miscellaneous If any of these RFC-3647-related clarifications require updates to your CP, CPS, or CP/CPS, what level of effort do you anticipate this will take? [Free-text response] Finally, are there any additional concerns, questions, or recommendations regarding the proposed changes to MRSP for v3.0 that you would like to share? [Free-text response] Regards, Ben Wilson Mozilla Root Store Program Manager -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa%3D%3DhH9EbEWkXY78uO4kvZWpMqs5y4EH-fq485CB7YVKg%40mail.gmail.com.
