<div dir="ltr"><div>Note: Moving this to servercert-wg@ since this is about the BRs (I'm avoiding BCC'ing public so that a reply-all doesn't cause cross-posting)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 17, 2020 at 1:35 PM Aaron Gable via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>The Microsoft Trusted Root Program Requirements (<a href="https://docs.microsoft.com/en-us/security/trusted-root/program-requirements" target="_blank">https://docs.microsoft.com/en-us/security/trusted-root/program-requirements</a>, henceforth MS) contain the following language in MS§3.C.2:<span style="font-weight:bold;color:rgb(95,99,104);font-family:Roboto,arial,sans-serif;font-size:14px"></span></div><div><br></div><div>> 3.C.2. CAs that issue Server Authentication certificates must support the following OCSP responder requirements:</div>> a. Minimum validity of eight (8) hours; Maximum validity of seven (7) days; and<br>> b. The next update must be available at least eight (8) hours before the current period expires. If the validity is more than 16 hours, then the next update must be available at ½ of the validity period.<div><br></div><div>I'm most interested in part (b). This piecewise function can be illustrated by the following examples:</div><div>* 8 hour lifetime: 8 hours before (i.e. instantaneously)<br>* 12 hour lifetime : 8 hours before<br>* 16 hour lifetime : 8 hours before<br>* 20 hour lifetime : 10 hours before<br>* 80 hour lifetime : 40 hours before<br><div><br></div><div>As of ballot SC31 (Browser Alignment), the version 1.7.3 of the Baseline Requirements (<a href="https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf" target="_blank">https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf</a>, henceforth BR) contains the following language in BR§4.9.10:</div><div><br></div><div>> 1. OCSP responses MUST have a validity interval greater than or equal to eight hours;<br>> 2. OCSP responses MUST have a validity interval less than or equal to ten days;<br>> 3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.<br>> 4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.<br></div><div><br></div><div>As above, I'm most interested in parts (3) and (4). This piecewise function can be illustrated by these examples:</div><div>* 8 hour lifetime : 4 hours before<br>* 12 hour lifetime : 6 hours before<br>* 16 hour lifetime : 8 hours before<br>* 20 hour lifetime : 8 hours before<br>* 80 hour lifetime : 8 hours before</div><div><br></div><div>Both of these separate the requirements for when the next update must be available into two domains: for OCSP responses with validity less than 16 hours, and ones with validity greater than or equal to 16 hours. However, their behavior in these two domains is *exactly opposed*.</div><div><br></div><div>MS§3.C.2 requires that responses be available 8 hours prior in the "8-16 hours validity" domain, and at half the lifetime in the "16+ hours validity" domain.</div><div>BR§4.9.10 requires that responses be available 8 hours prior in the "16+ hours validity" domain, and at half the lifetime in the "8-16 hours validity" domain.</div><div><div><br></div><div>Of course, these requirements are not contradictory. At all possible validity intervals, the Microsoft requirements are stricter (i.e. require the next update to be available earlier), so a CA can simply abide by the Microsoft requirements and be in conformance with everything.</div><div><br></div><div></div></div><div>But this reversal is so precise that it seems at first that it must be a mistake. However, some spelunking through the drafts of Ballot SC31 shows that the language now incorporated into the BRs was in fact suggested by Microsoft.</div><div><br></div><div>In the very first draft of SC31, the language proposed for BR§4.9.10 was identical to the language currently found in MS§3.C.2:</div><div><a href="https://github.com/cabforum/servercert/pull/195/commits/f4860a596625e2167aa3fea06b17ee07900a3a7a#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1143" target="_blank">https://github.com/cabforum/servercert/pull/195/commits/f4860a596625e2167aa3fea06b17ee07900a3a7a#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1143</a><br></div><div>Later, an update titled "Incorporate feedback from Microsoft" reversed the requirements, producing the language which made it into the final ballot and the BRs:</div><div><a href="https://github.com/cabforum/servercert/pull/195/commits/e824ca10671c3b428009091bd0e78f8a7f39ddb1#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1145" target="_blank">https://github.com/cabforum/servercert/pull/195/commits/e824ca10671c3b428009091bd0e78f8a7f39ddb1#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1145</a><br></div><div>However, I have been unable to find any discussion on this list or elsewhere in which that feedback was provided, so the reasoning behind this change is unclear.</div></div></div></blockquote><div><br></div><div>Sorry about that!</div><div><br></div><div><a href="https://github.com/sleevi/cabforum-docs/pull/18">https://github.com/sleevi/cabforum-docs/pull/18</a> was the original PR from Microsoft , which was based on an email sent off-list regarding ongoing work to update policy, which captures some of that transition from the individual commits. I'm having a GitHub bug linking to the direct discussion that captured some of this.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>This raises two questions for me, which I hope the members of this list will be able to address:</div><div><br></div><div>1) What was the reasoning behind the reversal of this piecewise function between the version included in MS§3.C.2 and the version proposed in SC31 and incorporated into BR§4.9.10?</div></div></div></blockquote><div><br></div><div>Captured above, but Microsoft's statement they were in the process of updating their requirements to what was/is described in SC31 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>2) Does Microsoft plan to remove its own requirements from MS§3.C.2, now that the baseline requirements have "aligned" on Microsoft's proposal?</div></div></div></blockquote></div></div>