[Servercert-wg] [cabfpub] Microsoft and Baseline OCSP Next Update Requirements

[Ryan Sleevi]

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)

On Thu, Dec 17, 2020 at 1:35 PM Aaron Gable via Public <public at cabforum.org>
wrote:

> Hi everyone,
>
> The Microsoft Trusted Root Program Requirements (
> https://docs.microsoft.com/en-us/security/trusted-root/program-requirements,
> henceforth MS) contain the following language in MS§3.C.2:
>
> > 3.C.2. CAs that issue Server Authentication certificates must support
> the following OCSP responder requirements:
> > a. Minimum validity of eight (8) hours; Maximum validity of seven (7)
> days; and
> > 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.
>
> I'm most interested in part (b). This piecewise function can be
> illustrated by the following examples:
> * 8 hour lifetime: 8 hours before (i.e. instantaneously)
> * 12 hour lifetime : 8 hours before
> * 16 hour lifetime : 8 hours before
> * 20 hour lifetime : 10 hours before
> * 80 hour lifetime : 40 hours before
>
> As of ballot SC31 (Browser Alignment), the version 1.7.3 of the Baseline
> Requirements (
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf,
> henceforth BR) contains the following language in BR§4.9.10:
>
> > 1. OCSP responses MUST have a validity interval greater than or equal to
> eight hours;
> > 2. OCSP responses MUST have a validity interval less than or equal to
> ten days;
> > 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.
> > 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.
>
> As above, I'm most interested in parts (3) and (4). This piecewise
> function can be illustrated by these examples:
> * 8 hour lifetime : 4 hours before
> * 12 hour lifetime : 6 hours before
> * 16 hour lifetime : 8 hours before
> * 20 hour lifetime : 8 hours before
> * 80 hour lifetime : 8 hours before
>
> 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*.
>
> 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.
> 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.
>
> 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.
>
> 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.
>
> 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:
>
> https://github.com/cabforum/servercert/pull/195/commits/f4860a596625e2167aa3fea06b17ee07900a3a7a#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1143
> Later, an update titled "Incorporate feedback from Microsoft" reversed the
> requirements, producing the language which made it into the final ballot
> and the BRs:
>
> https://github.com/cabforum/servercert/pull/195/commits/e824ca10671c3b428009091bd0e78f8a7f39ddb1#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1145
> 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.
>

Sorry about that!

https://github.com/sleevi/cabforum-docs/pull/18 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.

This raises two questions for me, which I hope the members of this list
> will be able to address:
>
> 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?
>

Captured above, but Microsoft's statement they were in the process of
updating their requirements to what was/is described in SC31 :)


>
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201217/a23ab4dd/attachment.html>