Policy 2.8.1: MRSP Issue #243: Update periods for CPs and CPSes

[Ben Wilson]

All,

The purpose of this thread is to discuss changing the period of time required for updating CPs and CPSes (in item 4 of Section 3.3 of the Mozilla Root Store Policy). This is in relation to GitHub Mozilla PKI Issue #243. It has been suggested that the time period for updating a CP/CPS should be shorter than 365 days, at least for CPs and CPSes describing issuance of TLS server certificates, because the Baseline Requirements are updated much more frequently.

I am not sure whether the same CP/CPS revision timeframe should apply to a CA that only has the email trust bit enabled.

I like the phrasing that would be taken from the CA/Browser Forum's Baseline Requirements section 2.3.  As a start, it could be revised to read as follows:

"The CA operator SHALL develop, implement, enforce, review, and annually update a Certificate Policy, and/or Certification Practice Statement, or combined CP/CPS, that describes in detail how the CA operator implements the latest version of this Policy and the these Baseline Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry at least every X days, even if no other changes are made to the document."

Thanks,

Ben

[Ryan Hurst]

In my personal opinion, a periodic re-affirmation that the CPS/CP is still current seems a minimal bar for inclusion in any trust list regardless of the certificate type.

Ryan Hurst

--
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%2B1gtab0Nme4EyHyXHGs6Lb%3DaCTG5T22tnc8V4%3DcV1uEnXuyOw%40mail.gmail.com.

[Kurt Seifried]

One comment from an operational point of view having a period that is slightly longer than the intended review cycle helps, e.g. a 365 day deadline means my review creeps back a few days every year (unless I leave it to the last minute), ignoring leap years. I would suggest twice a year, so 190-200 day period so people can pick two dates on the calendar and make it part of their workflow. 

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwbLNm5J1_w-AHCc1q%2BDv9AhSZp_PbKPOat15RtWBXLTxw%40mail.gmail.com.

--

Kurt Seifried (He/Him)
ku...@seifried.org

[Aaron Gable]

Thoughts, in no particular order:

- I am in favor of changing the requirement from "annually" to "every X days"; we've made similar changes to other requirements in the BRs and consistency even across requirement-sets is good.

- Again from a consistency perspective, it's understood that "398 days" means "a year, with some wiggle room", so I think that changing from "annually" to "every 398 days" would be as close to a no-op as is reasonable.

- I'm not a big fan of relaxing the requirement, even just by a month, but I think that the consistency arguments above are sufficient to convince me it's appropriate in this case.

Aaron

On Tue, Nov 15, 2022 at 8:32 AM Ben Wilson <bwi...@mozilla.com> wrote:

--

[Ryan Hurst]

That all seems reasonable to me.

Ryan Hurst

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcQZkJ8G2i68MknTe7noaFVmzNRmxJFSjjD_Pj6we%2B18g%40mail.gmail.com.

[Ryan Dickson]

Hi all,

I commented on the GitHub issue, but if we're looking at changing this requirement, I think we should do so from the perspective of making it better aligned with root program expectations. 

Many root program policies include the expectation that a CA's policies conform with the latest version of the BRs. Over the past five years, we've seen, on average, eight ballots adopted to modify the BRs each year. While it's true that not all ballots necessitate a CA's policies are updated, I suspect if we studied it closer, we'd probably see CAs would need to update their CP a few times a year, on average, to satisfy root program policies that require policy “freshness.”

I'm not strongly proposing we change the yearly minimum requirement but instead expressing concern about increasing it beyond every 365 days.

Somewhat related, I think some simple improvements could be made regarding file naming conventions on policy documents to make it easier for CAs to demonstrate compliance with policy “freshness” requirements.

For example, assume we required the current version of a CP always to be located at [$ca_repository_base_url]/cp.pdf], or an otherwise static URL. As new versions of the CP are published, they would replace the document hosted at [$ca_repository_base_url]/cp.pdf] or the static URL. "Archived" versions would then be appended with the version # of the then superseded document (e.g., a superseded document would transition from [$ca_repository_base_url]/cp.pdf] to [$ca_repository_base_url]/cp-[$previousVersion].pdf]). Ultimately, this makes it very easy for interested parties to find the most current version of a given document.

The same format can apply to CPSs or TSPSs. To accommodate CAs that maintain multiple CPs, we’ll need to think about ways of differentiating URLs.

Root programs interested in doing so (or CCADB) could then monitor the "current" policy document URLs and more easily verify the update requirement has been met (i.e., regularly curl and hash $ca_repository_base_url]/cp.pdf, and report when a policy is about to or has recently become stale). Thinking beyond the immediate capabilities of CCADB, perhaps someday it could automatically track version changes to policy documents as they are identified by changes to the hashed value of $ca_repository_base_url]/cp.pdf - reducing workload required by CAs to make sure CCADB records are accurate and updated in a timely manner.  

And, while we’re thinking outside the box - would requiring policy documents be maintained in a common format that easily supports diffs and tracked changes (i.e., Markdown, as we maintain the BRs) - improve our collective policy management and conformance efforts?

Thanks,

Ryan

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwY9TnZ6Qf7pOwC1jsCf5yOdJBKcHb-F-CUvoPAQm6Y%2BPQ%40mail.gmail.com.

[Ryan Hurst]

I like the idea of a well-known URL but from my perspective, something more machine-readable, and in the standard well-known namespace would be ideal, similar to https://securitytxt.org/.

It would also be nice if the documents were signed and timestamped so that the policy of frequency of updates could be assessed programmatically.

Ryan

[Ryan Dickson]

Hi all,

I just realized I was intending on commenting on a separate, but related issue (SCWG Repo). I'll re-post my message there for completeness, though I suspect folks are following the discussions on both threads.

Sorry for the mix-up!

- Ryan

[Rufus Buschart]

Hi Ryan!

I highly like your ideas about making the CP/CPS electronically readable. I'm convinced we will have interesting findings when comparing the level of details of the various CP/CPS' out there.

But regarding your concerns about increasing beyond 365 days: could you elaborate why those 33 days compared to the proposed 398 days will make a signifikant difference in the reliability of the CA operation? I'd not expect this, but these 33 days would make life of the CA operator easier by avoiding a sliding window that needs also to be coordinated with the annual audit.

Best regards

Rufus

[Ryan Dickson]

Hi Rufus,

A CA’s CP represents commitments by its owners regarding minimum expectations related to security and reliability. CPSs should, in detail, describe how those requirements are satisfied. Root programs, like Chrome’s, rely on these policy documents, in part, to evaluate that CAs are upholding their commitments and operating services as expected. We also use them when assessing incidents (to understand better what went wrong and to identify opportunities for improvement) and when considering future changes to our policies to minimize the risk of unintended impacts on the ecosystem. 

Ultimately, this means that policies need to be current and aligned with actual practices. Other ecosystem participants, for example, subscribers, may also rely on the information presented in policy documents to be accurate and timely as they determine which CA they choose as their service provider. 

From one perspective, the existing annual update requirement is somewhat artificial. As described in my last post, many root programs, like Chrome’s, expect a CA’s policies to conform with the effective version of BRs. If the BRs are modified in a way that necessitates an update by a CA (e.g., prohibiting a domain validation method that’s currently in use), we expect those policy updates and corresponding behaviors within the time prescribed by the corresponding ballot’s effective date, not a year from the document’s last update. 

If it’s possible for a CA’s policies to go an entire year without requiring an update as a result of changes to the BRs, the existing annual requirement, at least, presents an opportunity for the communication of this determination, as represented by a bump in the document version number.   

We see the use of “annual” in a few places throughout the BRs:

• Section 2: As discussed in this thread

• Section 5: Related to risk assessments and incident and compromise handling procedures 

• Section 8: Related to audits

The Chrome Root Program interprets “annual” as 365 days in all of the above cases. We’ll use this discussion as an opportunity to reflect on our policy to clarify our expectations further. As with other commenters in the thread, we’re in favor of updates to the BRs that disambiguate statements such as those being discussed here. 

My concern with extending to a number larger than 365 days is that it may present opportunities for confusion (i.e., the BRs expect [A], but root programs expect [B]). As commented on GitHub, these timelines are the minimum requirements CAs must satisfy. Nothing stops a CA from exceeding them.

Regarding arguments to use 398 days to promote consistency, we only see 398 days used in the BRs related to domain validation reuse and TLS server certificate validity. What happens in the future if these timelines are reduced? We’ve heard intent from some root programs (see “Long Term” goals section) about future efforts to reduce these maximum timelines, which might further suggest 398 days is not the best anchor.

Thanks,

Ryan