Hi all, I just realized I was intending on commenting on a separate, but related issue (SCWG Repo <https://github.com/cabforum/servercert/issues/370>). 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 On Tue, Nov 15, 2022 at 1:19 PM Ryan Hurst <[email protected]> wrote: > 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 > > > On Tue, Nov 15, 2022 at 10:13 AM Ryan Dickson <[email protected]> > wrote: > >> 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/CADEW5O83ef125aKNUS%2Bs6qMM95wNWBpGMrKYf4Y_NbKM487EHA%40mail.gmail.com.
