Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

[Ben Wilson]

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.

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

[passerby184]

"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에 bwi...@mozilla.com님이 작성:

[Ben Wilson]

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?

[Ben Wilson]

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? 

[Pedro Fuentes]

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 

[Ben Wilson]

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." ?

[Arvid Vermote]

Hi Ben, if a party is relying on a 7+ year old CA would they not want to consult / know the policies and practices that were in place at the time the CAs keys were generated or during the first years of its lifetime?

 

Thanks - Arvid

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZRMjYzP7peUtRfK-0P9OhxA4wYDB5OzfbsZ5kgOxy6wg%40mail.gmail.com.

[Ben Wilson]

On Fri, Mar 25, 2022 at 12:24 PM Arvid Vermote <arvid....@globalsign.com> wrote:

Hi Ben, if a party is relying on a 7+ year old CA would they not want to consult / know the policies and practices that were in place at the time the CAs keys were generated or during the first years of its lifetime?

Yes - thanks!

[Pedro Fuentes]

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.

[Ben Wilson]

And the full lifetime of root CA certificates.  Correct? Regardless of changes in ownership.

[Pedro Fuentes]

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

[Jeremy Rowley]

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: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Pedro Fuentes
Sent: Monday, March 28, 2022 2:46 AM
To: dev-secur...@mozilla.org
Cc: bwi...@mozilla.com <bwi...@mozilla.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>; Pedro Fuentes <pfuen...@gmail.com>
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

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

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.

[Pedro Fuentes]

I see your point, but this is not about "operating under the old CPS docs", because we are obliged to update the CPS every year, so actually we can't be do any operation under CP/CPS that are older than one year.

This is more for the sake of transparency and history, for matters related to liability, ownership... We currently publish all our versions since 2005, but I'd be OK if the community decides this is overkill.

[Ryan Sleevi]

On Mon, Mar 28, 2022 at 8:58 AM 'Jeremy Rowley' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> 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).

[Jeremy Rowley]

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 <ry...@sleevi.com>
Sent: Monday, March 28, 2022 7:13 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Pedro Fuentes <pfuen...@gmail.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>; bwi...@mozilla.com <bwi...@mozilla.com>

Subject: Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

 

[Ryan Sleevi]

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

[Ben Wilson]

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

[Ben Wilson]

Here is an edit to address this - https://github.com/BenWilson-Mozilla/pkipolicy/commit/10946b7133bf57818638fdee95d38c8696baca63