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/7a654d5f-daac-4f65-992f-6e2202fef9b0n%40mozilla.org.
