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]<mailto:[email protected]> <[email protected]<mailto:[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/BYAPR14MB260019E8A713B4D937B0D71E8E1E9%40BYAPR14MB2600.namprd14.prod.outlook.com.
