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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[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.
