Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CP/CPS updates at least every 365 days #370

Open
BenWilson-Mozilla opened this issue Apr 28, 2022 · 13 comments
Open

CP/CPS updates at least every 365 days #370

BenWilson-Mozilla opened this issue Apr 28, 2022 · 13 comments
Labels
backlog baseline-requirements Server Certificate CWG - Baseline Requirements enhancement

Comments

@BenWilson-Mozilla
Copy link
Contributor

Section 2 should be amended to delete "annually update" and add a following sentence that says, "The CA SHALL review and update its CP and/or CPS at least every 365 days, and indicate the new version by incrementing the version number and adding a dated changelog entry, even if no other changes are made." Or something similar. Rationale: Some CAs have argued that "annually update" means calendar year, which leads to a period of as much as 730 days between CP/CPS updates.

@RufusJWB
Copy link

I would like to propose setting the time window to 398 days and not 365. The reason for this is that one typically does the update a couple of days before reaching the deadline and if we have only 365 days, the window is moving forward.

@BenWilson-Mozilla
Copy link
Contributor Author

@RufusJWB @srdavidson That 398-day window would be fine with me. Change will also need to be made with all root program policies and in the CCADB's processing logic.

@pfuentes69
Copy link

I personally prefer years understood as 12 months… there are other activities such as the period audits that I guess won’t be shifted to 398 days…

@ryancdickson
Copy link
Contributor

Studying historical updates (ballots adopted) to the Baseline Requirements tracked in Section 1.2.1 (Revisions)...:

  • 2022 (in-progress): 3
  • 2021: 8
  • 2020: 8
  • 2019: 7
  • 2018: 8
  • 2017: 14

Given many root programs operate under the expectation that a CA's policies conform to the latest version of the BRs, it seems we should be expecting policy updates at a frequency much more often than yearly.

One could argue that a single ballot may not necessitate changes to a CA's policies (i.e., a clean-up ballot that focuses on updating the "References" section), but it seems unlikely (to me) that a set of policies can go a year without needing to be updated to describe "in detail how the CA implements the latest version of these Requirements" (snippet from Section 2 of the BRs).

@BenWilson-Mozilla
Copy link
Contributor Author

Hi @RufusJWB, What are your responses? Thanks.

@Dwright1-godaddy
Copy link

I agree with what Ryan said, I don't think we could go a year without updating our CP/CPS, but I know some other CAs can or do from looking at a history of the bugzilla log.

That said, it looks like the primary change here is clarifying the word annually (as the mention of a changelog is listed in 2.4). Would we be better off adding a definition of the word annually to clarify a 12 month period so we don't have to update 3 other uses of the word?

@RufusJWB
Copy link

I personally prefer years understood as 12 months… there are other activities such as the period audits that I guess won’t be shifted to 398 days…

In the BRs we always work for good reasons with days (or even seconds) and not months / years. So I would strongly advise to use days here as well.

Actually the audit periods should also be shifted to 398 days. Having it exactly ending 365 days after the end of the last audit makes planning very unflexible.

@MMeent
Copy link

MMeent commented Nov 16, 2022

Actually the audit periods should also be shifted to 398 days. Having it exactly ending 365 days after the end of the last audit makes planning very unflexible.

Can't a CA "just" move to audit more frequently than once per 365 days when they don't want the difficulties with planning exactly once every 365 days? The BR at 1.8.4 (section 8.1) explicitly requests no more than 1 year, but less than that is allowed as long as the audit periods are continuous: "An audit period MUST NOT exceed one year in duration". I don't think "the CA is bad at planning" is worth the risk that comes with decreasing the audit frequency requirements by 9%.

Same for CP/CPS, the longest time you can go without review and update is 365 days, but the requirements as written do not block the CA from doing that (e.g.) every 180 days.

@romanf
Copy link

romanf commented Nov 16, 2022

Audits are expensive (both in external cost to the auditors as well as in internal resources). And planning for audits always also has to take into account internal development schedules and auditors other clients...

Personally I struggle with the 1 year = 365 days because it's just not true... (leap years?) ;-)

-Roman

@ChristopherRC
Copy link

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.

is included in Section 2 and repeated in Section 2.3 of the current BRs. I suggest editing both sections to address the original proposed issue.

  1. PUBLICATION AND REPOSITORY RESPONSIBILITIES
    The CA SHALL develop, implement, and 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.

    2.3 Time or frequency of publication
    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 Certificate Policy and/or Certification Practice Statement SHALL be reviewed and updated at least once every 365 days (or 366 days in a leap year). The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.

Alternatively, we could do as @Dwright1-godaddy suggested and define annually to mean every 365 days (or 366 days in a leap year) and shorten the proposed update to Section 2.3.

@BenWilson-Mozilla
Copy link
Contributor Author

What if we set it to "at least every 366 days" and called it good?

@RufusJWB
Copy link

What if we set it to "at least every 366 days" and called it good?

I still think 397 days would be more reasonable and aligned with operative practices of a CA operator. And do we truly believe those 10% make a security difference?

@BenWilson-Mozilla BenWilson-Mozilla added baseline-requirements Server Certificate CWG - Baseline Requirements enhancement backlog labels Jul 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog baseline-requirements Server Certificate CWG - Baseline Requirements enhancement
Projects
None yet
Development

No branches or pull requests

8 participants