One comment from an operational point of view having a period that is slightly longer than the intended review cycle helps, e.g. a 365 day deadline means my review creeps back a few days every year (unless I leave it to the last minute), ignoring leap years. I would suggest twice a year, so 190-200 day period so people can pick two dates on the calendar and make it part of their workflow.
On Tue, Nov 15, 2022 at 9:50 AM Ryan Hurst <[email protected]> wrote: > In my personal opinion, a periodic re-affirmation that the CPS/CP is still > current seems a minimal bar for inclusion in any trust list regardless of > the certificate type. > > Ryan Hurst > > 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/CALVZKwbLNm5J1_w-AHCc1q%2BDv9AhSZp_PbKPOat15RtWBXLTxw%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwbLNm5J1_w-AHCc1q%2BDv9AhSZp_PbKPOat15RtWBXLTxw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Kurt Seifried (He/Him) [email protected] -- 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/CABqVa38xqhsdjw3n3HEeXq7b3My27Xw3a8KcXpq3xSaB-tandw%40mail.gmail.com.
