<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">I see this more than reasonable </div><div dir="ltr"><br><blockquote type="cite">Le 16 nov. 2022 à 19:49, Tim Hollebeek via Servercert-wg <servercert-wg@cabforum.org> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Calibri; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif; }
a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }
span.EmailStyle22 { font-family: Calibri, sans-serif; color: windowtext; }
.MsoChpDefault { font-size: 10pt; }
@page WordSection1 { size: 8.5in 11in; margin: 1in; }
div.WordSection1 { page: WordSection1; }</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">So the proposal I’ve been suggesting is standardizing on the 15<sup>th</sup> of odd months for effective dates. This misses most major holidays, which tend to be near the start / end of months. It also always guarantees that there’s a
possible date within 30 days of any desired date you want. And it’s relatively easy to remember.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ve actually been making proposals like this since Bilbao back in like 2015 or so, when discussed the importance of not constantly selecting January 1<sup>st</sup> as the effective date for every large change
<span style="font-family:"Segoe UI Emoji",sans-serif">😊</span> I don’t care horribly about the details, but reducing the number of effective dates we’re tracking and bundling things does make them easier to manage and communicate.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">January 15<sup>th</sup> – I’d only do minor stuff here, but it’s a good date for administrative stuff that wants to align with the calendar year without falling right on January 1<sup>st</sup>, which can be tricky because of office closures
and holidays.<o:p></o:p></p>
<p class="MsoNormal">March 15<sup>th</sup> – on or near Spring F2F<o:p></o:p></p>
<p class="MsoNormal">May 15<sup>th</sup>- before Summer F2F<o:p></o:p></p>
<p class="MsoNormal">July 15<sup>th</sup> – after Summer F2F <o:p></o:p></p>
<p class="MsoNormal">September 15<sup>th</sup> – before Fall F2F<o:p></o:p></p>
<p class="MsoNormal">November 15<sup>th</sup> – again, only minor stuff as this one is flirting with the winter holidays, but is a good last date for anything that needs to be done before the end of the year<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This also happens to give us a good effective date near each of the F2F meetings. We could even pick two of them to be “Major” updates, and two of them to be “Minor” updates, if we wanted. Then you’d have two high priority impact dates
(which is reasonable / manageable), and a couple of lower priority dates that prevent having too long delays for time sensitive stuff. Whatever date you want, there’s a date on the list within 30ish days of your desired date.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If anyone else has feedback I’m all ears, I’ve just been slowly evangelizing these ideas over the years in the hope that people find the idea attractive.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Note that there’s no requirement that this has to be standardized in the Bylaws or anything … if ballot authors and root programs want to start organically coalescing around these or another set of dates, I’m all for it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Tim<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Bruce Morton <Bruce.Morton@entrust.com> <br>
<b>Sent:</b> Tuesday, November 15, 2022 3:57 PM<br>
<b>To:</b> Ryan Dickson <ryandickson@google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org>; Ben Wilson <bwilson@mozilla.com><br>
<b>Cc:</b> Tim Hollebeek <tim.hollebeek@digicert.com><br>
<b>Subject:</b> RE: [EXTERNAL] Re: [Servercert-wg] Annual Update of CPS<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Maybe another issue is the 8 ballots per year all have different effectivity dates. I think this was Tim’s idea, but if we are thinking out of the box, why not limit the number of effectivity dates, say 2 per year. This would allow the
CAs to take the opportunity to update CP/CPS, based on changes from BR/EVG, once or twice per year depending on the impact.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Bruce.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org">servercert-wg-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Ryan Dickson via Servercert-wg<br>
<b>Sent:</b> Tuesday, November 15, 2022 1:25 PM<br>
<b>To:</b> Ben Wilson <<a href="mailto:bwilson@mozilla.com">bwilson@mozilla.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [Servercert-wg] Annual Update of CPS<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="100%" align="center">
</div>
<div>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">[Accidentally posted this in the
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_groups.google.com_a_mozilla.org_g_dev-2Dsecurity-2Dpolicy_c_JoyItinU9iQ_m_0QECoxA2CAAJ-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter-5F-5F-3B-21-21FJ-2DY8qCqXTj2-21dsuTApwH3ST7ASghiebViD-2DvEA8KpCLoeRtFWmmICfgK-2DfiEhvhCL-2DggPnW-5FHcmYEpSdLv7TrlqplEa3i2nvTZHwu-2DuGeA-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=GM-aG4L4bcOH4-d4J2Fqks8U1pxNdx25wta5Xx28HYI&s=5tw7gdh9Q2USZMmHpE-PFHFbg9RGldixRaxcO95TcuI&e=">
MDSP</a> thread related to the same topic, sorry if you're seeing this twice!]</span><o:p></o:p></p>
<p style="margin:0in"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">Hi all,</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">I commented on the GitHub</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_github.com_cabforum_servercert_issues_370-2Aissuecomment-2D1315408729-5F-5F-3BIw-21-21FJ-2DY8qCqXTj2-21dsuTApwH3ST7ASghiebViD-2DvEA8KpCLoeRtFWmmICfgK-2DfiEhvhCL-2DggPnW-5FHcmYEpSdLv7TrlqplEa3i2nvTZFVOwoVjw-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=GM-aG4L4bcOH4-d4J2Fqks8U1pxNdx25wta5Xx28HYI&s=kK3NrnfqG1pKtOnsHrFeD2pOapiseypt8T3hhR-pDrw&e=" target="_blank"><span style="font-family:"Arial",sans-serif;color:#0E101A">
</span><span style="font-family:"Arial",sans-serif;color:#4A6EE0">issue</span></a><span style="font-family:"Arial",sans-serif;color:#0E101A">, 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. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">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.”</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">I'm not strongly proposing we change the yearly minimum requirement but instead expressing concern about
<i>increasing</i> it beyond every 365 days.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">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.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">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.
</span><o:p></o:p></p>
<p style="margin:0in"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">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.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">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. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">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?</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">Thanks,</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">Ryan</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Nov 15, 2022 at 11:01 AM Ben Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Hi Clint,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">On second thought, maybe my mind has changed about this. I invite others to chime in.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ben<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Nov 15, 2022 at 7:16 AM Clint Wilson <<a href="mailto:clintw@apple.com" target="_blank">clintw@apple.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hi Ben,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Can you share more of your reasoning for picking 398 days and in general for decreasing the frequency of CP/CPS update requirements?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-Clint<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Nov 14, 2022, at 4:38 PM, Ben Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">All,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Section 2.3 of the Baseline Requirements currently says, "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy<br>
and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements." I am considering a proposal to revise that language to specify a 398-day period. See
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_github.com_cabforum_servercert_issues_370-2Aissuecomment-2D1113441809-5F-5F-3BIw-21-21FJ-2DY8qCqXTj2-21dsuTApwH3ST7ASghiebViD-2DvEA8KpCLoeRtFWmmICfgK-2DfiEhvhCL-2DggPnW-5FHcmYEpSdLv7TrlqplEa3i2nvTZEi1VmwsA-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=GM-aG4L4bcOH4-d4J2Fqks8U1pxNdx25wta5Xx28HYI&s=yBGxlPJMIEVM0RjD0dGMz7WbwjUw_ypBN9tj4BBhHzQ&e=" target="_blank">
https://github.com/cabforum/servercert/issues/370#issuecomment-1113441809 <br>
</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Possible language would be:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"The CA SHALL develop, implement, enforce, and <s>annually</s> update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate
conformance with this requirement by incrementing the version number and adding a dated changelog entry
<u>at least every 398 days</u>, even if no other changes are made to the document."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ben<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_lists.cabforum.org_mailman_listinfo_servercert-2Dwg-5F-5F-3B-21-21FJ-2DY8qCqXTj2-21dsuTApwH3ST7ASghiebViD-2DvEA8KpCLoeRtFWmmICfgK-2DfiEhvhCL-2DggPnW-5FHcmYEpSdLv7TrlqplEa3i2nvTZEG1NCn7g-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=GM-aG4L4bcOH4-d4J2Fqks8U1pxNdx25wta5Xx28HYI&s=tB5VFwEryn4xer9b6E_hGs5ecWOlmKrfqKD-253SarE&e=" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_lists.cabforum.org_mailman_listinfo_servercert-2Dwg-5F-5F-3B-21-21FJ-2DY8qCqXTj2-21dsuTApwH3ST7ASghiebViD-2DvEA8KpCLoeRtFWmmICfgK-2DfiEhvhCL-2DggPnW-5FHcmYEpSdLv7TrlqplEa3i2nvTZEG1NCn7g-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=GM-aG4L4bcOH4-d4J2Fqks8U1pxNdx25wta5Xx28HYI&s=tB5VFwEryn4xer9b6E_hGs5ecWOlmKrfqKD-253SarE&e=" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<p class="MsoNormal"><i>Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute
or disclose of the information it contains. <u>Please notify Entrust immediately</u> and delete the message from your system.</i>
<o:p></o:p></p>
</div>
</div>
<span>_______________________________________________</span><br><span>Servercert-wg mailing list</span><br><span>Servercert-wg@cabforum.org</span><br><span>https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=GM-aG4L4bcOH4-d4J2Fqks8U1pxNdx25wta5Xx28HYI&s=WJ-1nlRkNOpSNvOJFkGLEQxMd8-uiidX6SWdQ0B6Enw&e=</span><br></div></blockquote></body></html>