Thanks, Roman, for your questions. With respect to CA key protection, gaps in audit reports raise a big concern, but possibly they could be considered on a case-by-case basis. It would depend on the circumstances and the justification provided by the CA operator. But yes, if the gap were unjustified or part of a lapse in compliance or security, we would consider the key compromised and the key material and any certificates would not be trusted.
Here are some ideas for how a CA operator's case-specific request might be handled: We would require an independent auditor's post-gap report confirming that key lifecycle management processes remained intact, supported by sufficient documentation and evidence from the CA operator demonstrating CA key security measures as well as compliance with relevant policies or requirements. We would also want the CA operator to explain publicly: - why the gap occurred (all internal and external factors leading to its failure to obtain contiguous, annual key-protection reports); - what key protection controls were in place during the gap, which prevented key compromise and misuse; - how the CA operator maintained compliance with all other relevant policies and requirements; and - what the CA operator has done or will do in the future to prevent occurrence of similar incidents. Thanks again, Ben On Tue, Dec 10, 2024 at 11:57 PM Roman Fischer <[email protected]> wrote: > Dear Ben, > > > > We're wondering about the last sentence of proposed MRSP line 273: > > > > […] Successive period-of-time audits and auditor-provided annual key > lifecycle management reports MUST be contiguous (no gaps). > > > > What are the consequences if there are gaps? Can the gaps be closed > retrospectively or must the key be discarded? > > > > Thanks > Roman > > > > *From:* 'Ben Wilson' via [email protected] < > [email protected]> > *Sent:* Mittwoch, 4. Dezember 2024 23:09 > *To:* [email protected] <[email protected]> > *Subject:* MRSP 3.0: Issue #275: CA Key Protection > > > > All, > > > > This email is to open discussion here on the m-d-s-p list regarding the > resolution of GitHub Issue #275 > <https://github.com/mozilla/pkipolicy/issues/275> (Emphasize > period-of-time key lifecycle management in MRSP § 3.1.3). > > > > Part of the issue, as I see it, is to strengthen key protection > requirements for *all* keys that are intended to serve as CA keys, > including pre-generated CA keys that a CA operator might create. Sometimes > cryptographic key pairs are generated but not yet used to issue a CA > certificate (because, for example, the standards sometimes require > auditor presence at "key generation" but not at certificate creation). An > auditor's key generation report is likely useless if CA keys are > subsequently unprotected. So, at least one goal is to create clarity with > requirements that address the lifecycle management of these "parked" CA > keys. > > > > Here are some proposed edits to the Mozilla Root Store Policy (MRSP) > > > > Proposed edits to the MRSP > <https://github.com/mozilla/pkipolicy/compare/28a519327a21bebafc1cc3721d4376ba85bf3f98...e1a7f4e77f4988600b4d5caeb3cba172d7818a26> > (lines 273 and 746) > > > > Mainly this adds to MRSP § 3.1.3, "CA private keys that have been > generated but not yet associated with a CA certificate ("parked keys") MUST > be identified 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". > > > > The CA/B Forum's TLS Baseline Requirements has a similar issue (see e.g. > https://github.com/cabforum/servercert/issues/417). > > > > Proposed edits to the TLS BRs > <https://github.com/cabforum/servercert/compare/096810820d605d1a2c90a9b10e4ef36ed65bd6cc...d07ff6e148b9003938c47b23878d0065ea9d65d5> > (CABF Server-Cert GitHub Repository) > > > > Please provide any comments or suggestions you might have to resolve, or > otherwise improve this proposed resolution of, Issue #275. > > > > Thanks, > > > > Ben > > > > > > > > > > -- > 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%2B1gtaYZ4bfgg05Wb7MOfKz0q5rjnvnruQoKtS0O_kCOv9GMtQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYZ4bfgg05Wb7MOfKz0q5rjnvnruQoKtS0O_kCOv9GMtQ%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/ZR0P278MB017061E36B172D95F2B2DCCEFA3E2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB017061E36B172D95F2B2DCCEFA3E2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.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/CA%2B1gtaYQP%3DS9mEs8qmiH0c6MCm%2B0ySbg%2BiXPLoG5VAF9py2SLQ%40mail.gmail.com.
