Hi Jeremy, Thanks for reaching out. The intent of the proposed changes is twofold (both a clarification and a new requirement) because:
1. While the "cradle-to-grave" requirement was already present, it wasn’t always clearly articulated or consistently interpreted. Some CAs might have assumed they were meeting it without explicitly providing the necessary documentation or tracking for the entire CA key lifecycle. 2. The clarification aims to ensure that key lifecycle tracking is more comprehensive and consistently reported. By specifying that "parked" keys must be included in key lifecycle management reports (or an equivalent audit section), we are reinforcing the expectation that all CA keys are accounted for throughout their entire lifecycle. This aligns with GitHub Issue #275 <https://github.com/mozilla/pkipolicy/issues/275>, which I opened in January 2024. At the time, I noted that audit templates for key lifecycle management reports are valuable for CAs seeking root inclusion, as they provide evidence of key protection over a period of time. (Period-of-time audits are preferable to point-in-time audits, readiness assessments, or even key generation reports in this context. Additionally, this change is particularly relevant for intermediate CA certificates that might be signed and created well after a key generation ceremony. In such cases, tracking the status and handling of those "parked" keys becomes especially important to ensure their security and proper management during the period between the key generation ceremony and CA certificate creation. Additionally, this change is intended to bring further clarity to section 3.1.3 of the MRSP and other parts of section 3, emphasizing the usefulness of period-of-time key lifecycle reports in meeting cradle-to-grave key protection requirements. With this clarification, we aim to improve the accuracy and completeness of CA key tracking throughout their entire lifecycle (from the key generation report until the key is destroyed or no longer trusted). Thanks again, Ben On Tue, Feb 18, 2025 at 4:03 PM Jeremy Rowley <[email protected]> wrote: > Hi Ben - what is the intent of the change on the "parked keys"? There > already is a cradle-to-grave requirement. Is this just clarifying the > format that CAs must use when listing key pairs in their audit report? Have > CAs not been providing cradle-to-grave audit reports already? I ask as the > adoption date could cause confusion about whether this requirement is > already applicable to all CAs (which I thought it was). > > On Tuesday, February 18, 2025 at 3:39:54 PM UTC-7 高尾由加利 wrote: > >> >> 2025年2月19日(水) 7:13 Matt Palmer <[email protected]>: >> >>> On Tue, Feb 18, 2025 at 12:15:32PM -0800, 'Ben Wilson' via >>> [email protected] wrote: >>> > In response to survey feedback on the proposed requirements in *section >>> > 6.1.3* for mass revocation planning and testing, I have developed a >>> draft *Mass >>> > Revocation Incident Preparation and Testing Plan (MRIP&TP)* template. >>> > >>> > Since this is *not a Mozilla recommendation*, but rather a resource >>> that >>> > may help CAs in meeting upcoming requirements, I’m wondering how best >>> to >>> > share it. Would it be useful to post it to the list for discussion, or >>> > would another approach be preferable? >>> >>> If you think it's going to be a draft that'll require significant >>> revision and third-party input, posting the draft to the list soliciting >>> comments is probably best. >>> >>> As far as where the final text goes, the Mozilla wiki would seem >>> reasonable -- plenty of the information there already is what I would >>> consider "informative" rather than "normative", so adding this template >>> would not be out of place, IMO. >>> >>> - Matt >>> >>> -- >>> 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/a31ec4e1-d36d-4975-a288-2a4c4e4e1633%40mtasv.net >>> . >>> >> -- > 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/c3e32b1a-1b28-4248-b6c4-67da814ba542n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c3e32b1a-1b28-4248-b6c4-67da814ba542n%40mozilla.org?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%2B1gtaZXoqRZtQ0LPEzSw%2BtOUgZa49w1GRfoRghFRYrmS95%2BjA%40mail.gmail.com.
