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/CALVZKwZ-2hnCUutWP3pxVJxg9GsX8fkFCJ903B_dO-0JuDn3hA%40mail.gmail.com.
