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

Wed Nov 16 18:49:16 UTC 2022

So the proposal I’ve been suggesting is standardizing on the 15th of odd months for effective dates.  This misses most major holidays, which tend to be near the start / end of months.  It also always guarantees that there’s a possible date within 30 days of any desired date you want.  And it’s relatively easy to remember.

I’ve actually been making proposals like this since Bilbao back in like 2015 or so, when discussed the importance of not constantly selecting January 1st as the effective date for every large change 😊  I don’t care horribly about the details, but reducing the number of effective dates we’re tracking and bundling things does make them easier to manage and communicate.

January 15th – I’d only do minor stuff here, but it’s a good date for administrative stuff that wants to align with the calendar year without falling right on January 1st, which can be tricky because of office closures and holidays.
March 15th – on or near Spring F2F
May 15th- before Summer F2F
July 15th – after Summer F2F
September 15th – before Fall F2F
November 15th – again, only minor stuff as this one is flirting with the winter holidays, but is a good last date for anything that needs to be done before the end of the year

This also happens to give us a good effective date near each of the F2F meetings.  We could even pick two of them to be “Major” updates, and two of them to be “Minor” updates, if we wanted.  Then you’d  have two high priority impact dates (which is reasonable / manageable), and a couple of lower priority dates that prevent having too long delays for time sensitive stuff.  Whatever date you want, there’s a date on the list within 30ish days of your desired date.

If anyone else has feedback I’m all ears, I’ve just been slowly evangelizing these ideas over the years in the hope that people find the idea attractive.

Note that there’s no requirement that this has to be standardized in the Bylaws or anything … if ballot authors and root programs want to start organically coalescing around these or another set of dates, I’m all for it.

-Tim

From: Bruce Morton <Bruce.Morton at entrust.com>
Sent: Tuesday, November 15, 2022 3:57 PM
To: Ryan Dickson <ryandickson at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Ben Wilson <bwilson at mozilla.com>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: RE: [EXTERNAL] Re: [Servercert-wg] Annual Update of CPS

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<mailto: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<mailto:bwilson at mozilla.com>>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto: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/20221116/e4dbef09/attachment-0001.html>