[cabfpub] Microsoft and Baseline OCSP Next Update Requirements

Aaron Gable aaron at letsencrypt.org
Thu Dec 17 18:35:13 UTC 2020


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.

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?

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?

Thank you,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20201217/ad0f3841/attachment.html>


More information about the Public mailing list