Here are summaries of questions and comments and our responses. Summary of Questions or Concerns about MRSP § 7.4 (Root CA Lifecycles) and/or the Root CA Lifecycles guidance <https://wiki.mozilla.org/CA/Root_CA_Lifecycles>: We received questions about the process of transitioning from a Root CA certificate that's being distrusted to a new one. CAs want to ensure a smooth transition to new roots. One question asked whether distrust dates would be programmed into systems in advance to handle this process.
Mozilla Response: First, Mozilla recommends that CAs not wait until the last moment to request a root CA replacement, but instead ensure sufficient time when both the old and new roots can coexist in the root store. Provided that the CA has a good compliance history, Mozilla will then prioritize with Priority P1 those inclusion requests that involve a root CA replacement - https://wiki.mozilla.org/CA/Prioritization. (For Priority P1, “Applicant has good compliance history and is replacing an already-included CA certificate or is previously approved as a subordinate CA operator”.) For root CAs enabled with the email trust bit, the “distrust after” mechanism will be used. “Distrust after” will not be used for the websites trust bit. Instead, the websites trust bit will be removed, so CAs will need to cease issuing TLS certificates from deprecated roots at least one year / 398 days prior to the date that the websites trust bit will be removed. We plan to add a CA Task List Report to the CA Home page in the CCADB to alert CAs well in advance of when they should be working on the replacement for their aging root certificate(s). Summary of Questions or Concerns about S/MIME requirements and Mozilla's transition guidance <https://wiki.mozilla.org/CA/Transition_SMIME_BRs>: We were asked about the audits of external subordinate CAs when they are audited at different times under different audit criteria (Webtrust and ETSI). There was also uncertainty about audit start dates, for instance, when the S/MIME audit period does not start on September 1, 2023. Mozilla Response: MRSP section 2.3 makes it clear that as of September 1, 2023, S/MIME certificates and CA operations must conform to the S/MIME BRs. As of that date, CAs should have revised their CPs and CPSes to at least incorporate the S/MIME BRs by reference–hopefully more extensively. The transition guidance on the wiki states, “CA operators should modify their CP or CPS on or before September 1, 2023, to assert compliance with the S/MIME BRs.” We are not expecting a CA to file an incident report if it has not made necessary modifications to its CP and/or CPS before September 1, 2023, but if the CA asserts that it began complying with the S/MIME BRs after that date or if the audit period does not begin by that date, then the CA operator should submit an incident report as soon as they are aware of this situation. Many CAs are already filing incident reports for S/MIME non-compliance, but we will also be reviewing audit statements as they are submitted, so all CAs should file one incident bug covering all unreported S/MIME non-compliances listed in the audit statement (i.e. all non-compliances arising on or after September 1, 2023). Period-of-time audits for S/MIME submitted during the next year should have a period-of-time start date of no later than September 1, 2023. Period-of-time audits for periods ending between September 1, 2023, and October 30, 2023, cannot be obtained because 60 days is required to provide a sufficiently representative sample of CA operations and to ensure the audit's reliability and effectiveness. Also, given the short time frame and difficulty in retaining auditors who are prepared to audit according to the S/MIME BRs, it would not be reasonable to expect point-in-time audits within this period. Therefore, those few entities whose normal audit periods end within the timeframe above are expected to submit period-of-time audits that cover their subsequent audit period. For instance, a CA whose normal audit period ends on September 30, 2023, would obtain a period-of-time audit for October 1, 2023, through September 30, 2024, and the audit report would need to be submitted before January 1, 2025. Summary of Questions or Concerns about security incident and vulnerability disclosure requirement: There were questions and general suggestions about the use of the terms "vulnerability" and "incident", and the difference between "something that happened" and "something that could happen". The Vulnerability Disclosure wiki page <https://wiki.mozilla.org/CA/Vulnerability_Disclosure> defines vulnerabilities as potential weak points and incidents as actual events that pose threats, and yet most of the examples describe incidents and not vulnerabilities. Also, the term "Reportable Vulnerabilities" differs from critical CVEs, potentially causing confusion. Regarding “Incident Reporting”, the guidance says that “information does not need to be duplicated in the Reportable Vulnerability bug if it can be provided in the public-facing incident report.” Given the overlap and link between these processes, clarification is needed regarding the interdependencies between Incident Reports and Reportable Vulnerability bugs. Mozilla Response: As stated in the wiki page, the purpose of MRSP 2.4.1 and the “CA Security Vulnerability” Bugzilla component is to enable CAs to provide Mozilla with “Information about security compromises that require action from Mozilla” and “Security-sensitive information that needs to be shared with Mozilla”. Thus, CAs need to be sure to mark the “CA Program Security” checkbox in such Bugzilla reports. We welcome specific suggestions about how to improve the text in the Vulnerability Disclosure wiki page. For that purpose, I am sending out a separate post to this list, and then we will update the wiki page and try to clarify the use of these terms accordingly. Thanks, Ben and Kathleen On Mon, Sep 18, 2023 at 10:01 AM Ben Wilson <bwil...@mozilla.com> wrote: > All, > The period for submitting survey responses has now concluded, and the > results are in the sheet linked below (in my previous email). > I will now summarize the comments and post them here. > Thanks, > Ben > > On Fri, Sep 8, 2023 at 2:12 PM Ben Wilson <bwil...@mozilla.com> wrote: > >> All, >> >> While survey responses are not due until Sept. 15th, here are the results >> we've received thus far. >> >> >> https://docs.google.com/spreadsheets/d/1xJ6VRs2R0tw3-QHoIRzIIO8MWWoqNs576KOxPKYsp3w/edit?usp=sharing >> >> Thanks, >> >> Ben >> > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZPf2-8jsqgNbTL%3DEqAOXC4DTDQhJgo0psNz_cvnVqSdg%40mail.gmail.com.
