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 <https://www.chromium.org/Home/chromium-security/root-ca-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 <https://github.com/cabforum/servercert/issues/370#issuecomment-1316926602>, 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 <https://docs.google.com/document/d/1FQIHuMvD8Z2z_GvPznAxsStozld7ijoGC99UhElXSeE/view> (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 On Wed, Nov 16, 2022 at 6:28 AM Rufus Buschart <[email protected]> wrote: > 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 > > [email protected] schrieb am Dienstag, 15. November 2022 um 19:13:45 > UTC+1: > >> Hi all, >> >> I commented on the GitHub issue >> <https://github.com/cabforum/servercert/issues/370#issuecomment-1315408729>, >> 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 12:32 PM Ryan Hurst <[email protected]> wrote: >> >>> That all seems reasonable to me. >>> >>> Ryan Hurst >>> >>> On Tue, Nov 15, 2022 at 9:25 AM 'Aaron Gable' via >>> [email protected] <[email protected]> wrote: >>> >>>> 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 <[email protected]> wrote: >>>> >>>>> 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 >>>>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses>). >>>>> This is in relation to GitHub Mozilla PKI Issue #243 >>>>> <https://github.com/mozilla/pkipolicy/issues/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 >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "[email protected]" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> 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 >>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtab0Nme4EyHyXHGs6Lb%3DaCTG5T22tnc8V4%3DcV1uEnXuyOw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "[email protected]" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> 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 >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcQZkJ8G2i68MknTe7noaFVmzNRmxJFSjjD_Pj6we%2B18g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> 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 >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwY9TnZ6Qf7pOwC1jsCf5yOdJBKcHb-F-CUvoPAQm6Y%2BPQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O-_E-9CGn7SnoVE_iUeTZCNgsZy4W7CqP8rXPpGaQZqgw%40mail.gmail.com.
