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/CAErg%3DHEsKPJUx-HJTj2tzfeWjdsL1qRx-r8hcvQFwakezAJhyg%40mail.gmail.com.
