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%2B1gtaaR_r0xiSGPEtqz6ekkfDSB5ZER%2BLRL0GtGOEOao0xReA%40mail.gmail.com.
