Here is an edit to address this - https://github.com/BenWilson-Mozilla/pkipolicy/commit/10946b7133bf57818638fdee95d38c8696baca63
On Tue, Mar 29, 2022 at 9:28 AM Ben Wilson <[email protected]> wrote: > Should I add language that says ", regardless of changes in ownership or > control of the root CA,"? > > "CA operators SHALL maintain links to older versions of each CP and CPS > (or CP/CPS)*, regardless of changes in ownership or control of the root > CA, *until *the entire* root CA certificate hierarchy operated in > accordance with such documents are no longer trusted in the Mozilla root > program." > > It will be the responsibility of the current root CA operator to maintain > those older versions of CPs and CPSes. I think this may affect several CA > operators in the Mozilla program that have acquired roots from their > original owners. I hope they will be able to locate those older CPs and > CPSes. Should there be a cut-off going back? Or would the inability to > produce those CPs/CPSes be one of the reasons for root removal? (This would > be a factor in retiring an older root. See > https://github.com/mozilla/pkipolicy/issues/232) > > Should this item 7 in MRSP section 3.3 also include requirements for > retention and availability of the CPs and CPSes of externally operated > third party CAs? "This requirement also applies to the CPs and CPSes of > externally operated third party CAs." > > Thanks, > > Ben > > > > On Mon, Mar 28, 2022 at 7:24 PM Ryan Sleevi <[email protected]> wrote: > >> Well, yes, but it's not that things can't change - just that there's a >> history of those changes. >> >> In practice, I think it's more relevant to think of in the context of CA >> Lifecycle that Wayne presented about during the Shanghai F2F [1]. A root >> program understandably would want to know the entire lifecycle of the CA's >> key material and operations - from birth to death. Having an audit report >> over the continuous history is an important first step, for sure, but the >> audit report is going to be contextual based on the policies and practices >> in place during the audit period. So to have a full "birth to death" >> situation, you need not only a continuous set of audits, but also an >> unbroken sequence of policy documents for that same period. >> >> This policy change doesn't fully require the "birth certificate" approach >> (although it's great to consider going forward), but it does seem to make >> sense to set forward the policy documentation requirement, which presumably >> the CA has and has maintained. If they haven't, perhaps it's another >> incentive to rotate roots? >> >> Yes, I'm stuck on rotating roots. It's still good :) >> >> [1] >> https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/#28-Audit-requirements-over-the-lifecycle-of-a-root >> >> On Mon, Mar 28, 2022 at 9:15 PM Jeremy Rowley <[email protected]> >> wrote: >> >>> Even key protection changes over time as things move to new safes and >>> hsms. Although I can see the value in knowing how the keys were stored >>> during each phase of its life - ie a historic record of key protection from >>> its creation to identify any areas that are later exposed as vulnerable. >>> ------------------------------ >>> *From:* Ryan Sleevi <[email protected]> >>> *Sent:* Monday, March 28, 2022 7:13 PM >>> *To:* Jeremy Rowley <[email protected]> >>> *Cc:* Pedro Fuentes <[email protected]>; >>> [email protected] <[email protected]>; >>> [email protected] <[email protected]> >>> *Subject:* Re: Policy 2.8: MRSP Issue #185: Require publication of >>> outdated CA policy documents >>> >>> >>> >>> On Mon, Mar 28, 2022 at 8:58 AM 'Jeremy Rowley' via >>> [email protected] <[email protected]> wrote: >>> >>>> I don’t see the point of keeping the old CPS docs after the 7-year >>>> requirement as everything after the 7-year archive period is purged. No one >>>> should be operating under the old CPS docs at that time. Can you imagine if >>>> we were protecting root keys the same way we did 30 years ago? Or doing the >>>> validation the same way. >>>> >>> >>> All the more reason to replace roots every few years, yes? ;-) >>> >>> >>>> The only relevant section in old CPS docs that I’m aware of is key >>>> generation. Key generation is a rather short section in CPS docs without a >>>> lot of detail. The detail is in the key ceremony docs. If you want to >>>> enforce records on key ceremonies, require retention of those rather than >>>> the CPS docs. >>>> >>> >>> Not just key generation though - but also key protection. >>> >>> Although yes, I agree with you, in practice most CP/CPSes are so >>> anemically anodyne that the practical value, versus the intended value, is >>> probably quite limited. >>> >>> There are other reasons that this could be useful, but they've primarily >>> been tackled through other policy avenues (e.g. disclosure and auditing of >>> intermediates). >>> >> -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaY_FFUcE8Scy4ar%3D8uPZXcp_z2%2BUY%2BPy3RXKMwc%3DO1LpA%40mail.gmail.com.
