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.
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. Here are some sample key generation sections from CPS docs: CA key pairs are generated by trusted roles and using a cryptographic hardware device. Typically, the cryptographic hardware is evaluated to FIPS 140‐1 Level 3 and EAL 4+. Community requirements may specify a lower version of control. DigiCert creates auditable evidence during the key generation process to prove that the CP/CPS was followed and role separation was enforced during the key generation process For Root CA Key Pairs created under this CPS Sectigo: • prepares and follows a Key Generation Script, • has a Qualified Auditor witness the Root CA Key Pair generation process or records a video of the entire Root CA Key Pair generation process, and • has a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair. The CAs will perform the following when generating a CA Key Pair: (i) Prepare and follow a Key Pair generation script; (ii) Have a qualified auditor witness the CA Key Pair generation process; (iii) Have a qualified auditor issue a report opining that the CA followed its CA Key Pair generation ceremony during its key generation process and the controls to ensure the integrity and confidentiality of the CA Key Pair; (iv) Generate the CA Key Pair in a physically secured environment; (v) Generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge; (vi) Generate the CA Key Pair within cryptographic modules meeting the applicable requirements of §6.2.11; (vii) Log its CA Key Pair generation activities; and (viii) Maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in this CPS and (if applicable) its CA Key Pair generation script. From: [email protected] <[email protected]> On Behalf Of Pedro Fuentes Sent: Monday, March 28, 2022 2:46 AM To: [email protected] Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; Pedro Fuentes <[email protected]> Subject: Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents Yes... That's how I see it... As long as there's any active Root or Intermediate that is affected by a version of the CP/CPS, it should be published El domingo, 27 de marzo de 2022 a las 20:41:11 UTC+2, [email protected]<mailto:[email protected]> escribió: And the full lifetime of root CA certificates. Correct? Regardless of changes in ownership. On Sun, Mar 27, 2022, 10:55 AM Pedro Fuentes <[email protected]> wrote: Maybe I didn't express myself properly, but what I said implies that the CA must publish the whole history of CP/CPS versions for any active CA or leaf certificate. El viernes, 25 de marzo de 2022 a las 18:41:03 UTC+1, [email protected] escribió: I think we need a retention period longer than 1 year. Can we make it apply without reference to current certificate lifetimes? What if the requirement were something like: "CA operators SHALL maintain links to older versions of each CP and CPS for at least seven (7) years, regardless of whether there is a sale, transfer, or acquisition of the CA." ? On Fri, Mar 25, 2022 at 5:44 AM Pedro Fuentes <[email protected]<mailto:[email protected]>> wrote: Maybe it would be reasonable to request to keep visibility on any CP/CPS that applies to any active certificate (Root/Intermediate/Leaf) or to certificates expired within one year prior to the date. This would ensure that the last audit period always can consider any relevant CP/CPS El jueves, 24 de marzo de 2022 a las 23:45:55 UTC+1, [email protected]<mailto:[email protected]> escribió: A comment to me on this draft raised two issues in my mind: 1 - How far back should CAs need to maintain older CPs/CPSes? Should there be a retention period for these (e.g. 7-10 years), even though the root has not yet expired? 2 - What about when ownership of the root changes? Take for example the GTE Cybertrust Root that was valid from 1998 to 2018. How should those CPSes have been maintained when the root was transferred from GTE -> Baltimore -> BeTrusted -> Cybertrust -> Verizon -> DigiCert? On Tue, Jan 18, 2022 at 4:03 PM Ben Wilson <[email protected]<mailto:[email protected]>> wrote: Here is another possible wording for new item 7 of MRSP 3.3 - "CAs SHALL maintain links to older versions of their CPs and CPSes until all root CA certificate hierarchies operated in accordance with such CP or CPS are no longer trusted in the Mozilla root program." Are there other suggested wordings that are better? On Sun, Jan 9, 2022 at 8:35 AM passerby184 <[email protected]<mailto:[email protected]>> wrote: "any related CA certificate hierarchy" sound too vague. guess this means upstream of trust chain of that CA? one could argue that as parent of that certificate is related even after sign is expired, so CA have to publish those CA's police until it's root expired, (like late 2030s for most root CAs in NSS currently) 2022년 1월 8일 토요일 오전 5시 7분 36초 UTC+9에 [email protected]님이<mailto:[email protected]님이> 작성: All, This email introduces discussion of another issue to be resolved by the next version of the Mozilla Root Store Policy (MSRP), version 2.8. (See https://github.com/mozilla/pkipolicy/labels/2.8) This is tracked by Github Issue #185<https://github.com/mozilla/pkipolicy/issues/185>. I have prepared draft language stating, "CAs SHALL maintain links to older versions of their CPs and CPSes for as long as any related CA certificate hierarchy is in the Mozilla root program." See https://github.com/BenWilson-Mozilla/pkipolicy/commit/3b217f923582f7cfd8d3915699602631bd12242e Please review and comment on the clarity of this proposed language. Thanks, Ben Wilson Mozilla Root Store Program -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f6395677-26f6-4534-b348-f7df24619f5dn%40mozilla.org<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f6395677-26f6-4534-b348-f7df24619f5dn%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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BYAPR14MB2600D8F7A69CAB9DD901431A8E1D9%40BYAPR14MB2600.namprd14.prod.outlook.com.
