For #294 (Key Generation Recency): No comment, looks good. For #298 (Continuous Audit Coverage): Looks good, with the inclusion of the paragraph here in the email. I was about to leave a big comment discussing how the need for a new audit report between a key generation ceremony and a root inclusion request is unclear, before realizing you'd addressed it in the email itself :)
For #297 (Updates to Audit Criteria References): the lines which refer to two different versions of a given WebTrust criteria, one applicable up to a certain date and the other required thereafter, only actually link to the latter doc. I think it would be good for these lines to still link to both the old and new versions of the WebTrust documents. For #296 (Detailed Controls Reports): I fear that this requirement may substantially increase audit costs to CAs. In some ways it feels like a step in the opposite direction from things like the CCADB Self-Assessment, which felt like a move away from reliance on external audits. That said, I do think that the whole industry will benefit from more transparent and detailed audits. Aaron On Fri, Apr 24, 2026 at 9:08 AM Mike Shaver <[email protected]> wrote: > I'm not sufficiently sophisticated in the ways of WebTrust to comment on > the details, but that "have more functional detail about the operations of > trusted CAs" is exactly the right direction to move the MRSP. Thank you! > > MIke > > > On Wed, Apr 22, 2026 at 6:59 PM 'Ben Wilson' via > [email protected] <[email protected]> wrote: > >> All, >> >> This thread begins discussion of proposed audit-related updates to the >> Mozilla Root Store Policy (MRSP). >> >> These changes are intended to improve the depth, consistency, and >> verifiability of information available to Mozilla when assessing CA >> compliance, and when evaluating root inclusion requests. In particular, the >> proposed changes are meant to *(1)* address gaps between high-level >> audit opinions and the underlying controls and operational practices that >> those opinions are meant to assess (*#296 >> <https://github.com/mozilla/pkipolicy/issues/296>*– Detailed Controls >> Reports), *(2)* update references to audit criteria (*#297 >> <https://github.com/mozilla/pkipolicy/issues/297>*–WebTrust / ETSI), >> *(3)* clarify audit coverage following key generation (*#298 >> <https://github.com/mozilla/pkipolicy/issues/298>*), and *(4)* add a >> root key generation recency requirement (*#294 >> <https://github.com/mozilla/pkipolicy/issues/294>*). >> >> *Here is a GitHub diff comparison >> <https://github.com/mozilla/pkipolicy/compare/3b7d84f5c9708cf6be9655319825d60ea338eca4...ad8e1766be6e0e9a93a64b0b71506ae923086ec5>* >> of the *currently proposed MRSP v3.1 >> <https://github.com/BenWilson-Mozilla/pkipolicy/blob/3.1/rootstore/policy.md>* >> (working draft, subject to change) vs. the *current MRSP v3.0 >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>* >> : >> >> *Overview of Proposed Changes* >> >> *1. Introduction of Detailed Controls Reports (DCRs) – #296 >> <https://github.com/mozilla/pkipolicy/issues/296>* >> >> The current audit framework relies primarily on standardized audit >> reports (e.g., WebTrust or ETSI), which provide an opinion on whether >> controls are suitably designed and operating effectively. However, these >> reports often do not include sufficient detail about the controls >> themselves, how they are implemented, or how compliance is verified. >> >> The proposed addition of Section 3.1.5 introduces a requirement for an >> annual Detailed Controls Report (DCR), beginning July 1, 2027. >> >> Under this approach, a DCR would: >> >> - supplement, but not replace, existing audit reports; >> - define system boundaries, scope limitations, and interactions with >> relevant parties; >> - provide a structured and comprehensive description of CA systems, >> controls, and audit testing; >> - contain control mappings, descriptions of control design, testing >> methodologies, and results; and >> - incorporate risk considerations and how implemented controls >> address those risks. >> >> The DCR is intended to bridge the gap between high-level audit opinions >> and the underlying technical and procedural reality of CA operations. Also, >> the DCR would not be publicly disclosed, but a CA operator would have to >> provide it to Mozilla upon request. >> >> *2. Clarification of Continuous Audit Coverage – #298 >> <https://github.com/mozilla/pkipolicy/issues/298>* >> >> Section 7.1 currently includes language requiring “contiguous >> period-of-time audit reports,” which has led to ambiguity regarding whether >> audit reports must be issued immediately following root key generation. >> >> A proposed revision in subsection 5 clarifies that: >> >> - Continuous audit coverage refers to the absence of gaps in audited >> periods, not the timing of report issuance. >> - Audit reports are expected to follow the CA operator’s normal audit >> cycle (e.g., annual reporting), and are not required to be issued >> immediately after key generation. >> - A root key generated within an already-audited environment may be >> considered covered, provided there are no material changes to controls. >> >> However, the following additional edits have not yet made it into MRSP v. >> 3.1 section 7.1: >> >> “Before being included, CA operators MUST provide evidence that their CA >> key pairs and CA certificates comply with the current Mozilla Root Store >> Policy and the applicable S/MIME BRs or TLS BRs, and have continuously >> complied, from the time of CA private key creation (see Section 3.1.3), >> with the Mozilla Root Store Policy and the applicable Baseline Requirements >> in effect during the relevant audit periods. Evidence of such continuous >> compliance consists of: (1) existing period-of-time audit reports covering >> the CA operator’s systems, processes, and controls; and (2) an >> auditor-witnessed key generation ceremony report for the root CA key pair. >> Where the key pair was generated within the audited environment and subject >> to the same controls, and no material changes to those controls have >> occurred, a separate or immediate audit is not required prior to submission >> of a Root Inclusion Request, as the subsequent audit report covering the >> applicable audit period is expected to include the new root CA certificate >> within its scope.” >> >> I plan to incorporate this language into the draft; feedback is welcome. >> >> >> *3. Root CA Key Generation Recency Requirement – #294 >> <https://github.com/mozilla/pkipolicy/issues/294>* >> >> The proposed update to Section 7.1 also introduces a requirement that >> root CA key material be generated within five (5) years prior to submission >> of a root inclusion request. >> >> Under this approach: >> >> - Root inclusion requests will only be accepted if the corresponding >> root key pair was generated within the preceding five years. >> - The requirement is tied to the auditor-witnessed key generation >> ceremony report submitted with the request. >> >> This change is intended to: >> >> - Promote modern cryptographic practices and operational readiness; >> - Ensure that newly included roots reflect current security >> expectations; and >> - Reduce reliance on long-dormant or aging key material. >> >> *4. Updates to Audit Criteria References – #297 >> <https://github.com/mozilla/pkipolicy/issues/297>* >> >> Sections 3.1.1 and 3.1.2 are updated to reference the current versions of >> applicable WebTrust and ETSI audit criteria. This is a maintenance >> update intended to ensure alignment with current audit standards and to >> avoid ambiguity regarding applicable criteria versions. >> >> >> Feedback on proposed direction and draft language are welcome. >> >> Thanks, >> Ben Wilson >> Mozilla Root Program >> >> >> >> -- >> 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%2B1gtaahGKEks65eRN5ZFY0LSMR8nVcB_QCNu8ONXDxE3RBP6Q%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaahGKEks65eRN5ZFY0LSMR8nVcB_QCNu8ONXDxE3RBP6Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CADQzZqu%3Dk4ZzAGEBb1t4mQh2Qt%3D2d1DSE9kiToUDk3hfwbge0Q%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqu%3Dk4ZzAGEBb1t4mQh2Qt%3D2d1DSE9kiToUDk3hfwbge0Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEmnErfepZt45Eb4uasdn0Mwx7AwcLMS6PLEJwRXUe86Eonk7A%40mail.gmail.com.
