All, I have renamed the previously-mentioned branch to Final Updates 3.0 ( https://github.com/mozilla/pkipolicy/compare/Final-Updates-3.0), and I'm merging this update branch into the 3.0 branch that has the rest of the changes.
Here are some final edits made today: https://github.com/mozilla/pkipolicy/compare/695d6c318875a912a4a5ce3fa0d0f6aa1ca5f0d6...2c815ba3bed17a5023b6f283442d71d3c81a3a94 . Of note: - I have changed the Effective Date to March 15, 2025, made changes to reflect the March 15, 2025, date in several places. - Under section 6.1.3 for mass revocation plans, I have separated the assessment part more clearly and added a clarification, "The above-referenced June 1, 2025, date is to ensure that compliance with the September 1, 2025, requirements will be evaluated within a reasonable timeframe while allowing CA operators to incorporate mass revocation testing into their CA processes and annual audit cycles. However, the assessment does not have to be conducted as part of the CA operator’s ETSI or WebTrust audit unless the CA operator finds it more convenient to include it within that scope. The assessment may be conducted separately by a qualified third-party assessor, provided it meets the stated evaluation criteria." - Under section 7.5 for dedicated roots, I added a clarification "CA operators with root certificates that have both the websites and email trust bits enabled SHOULD review the transition schedule associated with Section 7.4 (Root CA Lifecycles) when planning their compliance with this section 7.5. Specifically, CA operators SHOULD be aware that Mozilla’s trust bit transition schedule will result in the removal of the websites trust bit from certain root certificates before December 31, 2028." Ben On Tuesday, February 18, 2025 at 7:04:42 PM UTC-7 Ben Wilson wrote: > 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/1928a235-af44-458b-8874-c4df447bb664n%40mozilla.org.
