[Servercert-wg] [EXTERNAL] Re: Annual Update of CPS

Tue Nov 15 20:56:45 UTC 2022

Maybe another issue is the 8 ballots per year all have different effectivity dates. I think this was Tim’s idea, but if we are thinking out of the box, why not limit the number of effectivity dates, say 2 per year. This would allow the CAs to take the opportunity to update CP/CPS, based on changes from BR/EVG, once or twice per year depending on the impact.

Bruce.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Dickson via Servercert-wg
Sent: Tuesday, November 15, 2022 1:25 PM
To: Ben Wilson <bwilson at mozilla.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [EXTERNAL] Re: [Servercert-wg] Annual Update of CPS

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________

[Accidentally posted this in the MDSP<https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/g/dev-security-policy/c/JoyItinU9iQ/m/0QECoxA2CAAJ?utm_medium=email&utm_source=footer__;!!FJ-Y8qCqXTj2!dsuTApwH3ST7ASghiebViD-vEA8KpCLoeRtFWmmICfgK-fiEhvhCL-ggPnW_HcmYEpSdLv7TrlqplEa3i2nvTZHwu-uGeA$> thread related to the same topic, sorry if you're seeing this twice!]

Hi all,

I commented on the GitHub issue<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/issues/370*issuecomment-1315408729__;Iw!!FJ-Y8qCqXTj2!dsuTApwH3ST7ASghiebViD-vEA8KpCLoeRtFWmmICfgK-fiEhvhCL-ggPnW_HcmYEpSdLv7TrlqplEa3i2nvTZFVOwoVjw$>, 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

On Tue, Nov 15, 2022 at 11:01 AM Ben Wilson via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
Hi Clint,
On second thought, maybe my mind has changed about this. I invite others to chime in.
Ben

On Tue, Nov 15, 2022 at 7:16 AM Clint Wilson <clintw at apple.com<mailto:clintw at apple.com>> wrote:
Hi Ben,

Can you share more of your reasoning for picking 398 days and in general for decreasing the frequency of CP/CPS update requirements?

Thanks!
-Clint

On Nov 14, 2022, at 4:38 PM, Ben Wilson via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:

All,
Section 2.3 of the Baseline Requirements currently says, "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy
and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."  I am considering a proposal to revise that language to specify a 398-day period.  See https://github.com/cabforum/servercert/issues/370#issuecomment-1113441809
<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/issues/370*issuecomment-1113441809__;Iw!!FJ-Y8qCqXTj2!dsuTApwH3ST7ASghiebViD-vEA8KpCLoeRtFWmmICfgK-fiEhvhCL-ggPnW_HcmYEpSdLv7TrlqplEa3i2nvTZEi1VmwsA$>
Possible language would be:
"The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry at least every 398 days, even if no other changes are made to the document."
Thanks,
Ben

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!dsuTApwH3ST7ASghiebViD-vEA8KpCLoeRtFWmmICfgK-fiEhvhCL-ggPnW_HcmYEpSdLv7TrlqplEa3i2nvTZEG1NCn7g$>

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!dsuTApwH3ST7ASghiebViD-vEA8KpCLoeRtFWmmICfgK-fiEhvhCL-ggPnW_HcmYEpSdLv7TrlqplEa3i2nvTZEG1NCn7g$>
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20221115/e95fcf20/attachment-0001.html>