[Servercert-wg] Discussion Period Begins: SC-52: Specify CRL Validity Intervals in Seconds

[Aaron Gable]

Throughout the BRs, there are many different kinds of time intervals:
- how long a cert is valid
- how long a CRL is valid
- how long an OCSP response is valid
- how long a validation document can be used
- how long a random value can be used
- how long a CA has to perform a revocation
- how quickly CAs must provide their first audit and disclose CPS changes
in CCADB

Although the purpose of this ballot is focused on CRLs, I think there are
two things we need to notice about it:

First, by moving the declaration of how differences are counted into
Section 1.6.4 Conventions, this method of computing time differences *does*
apply to validation documents, random values, and all other time intervals.
CAs should be aware that these lifetimes will now be measured to the
precision of seconds, and should take care to ensure that they are not
(e.g.) reusing validation documents right up against the limit.

This does introduce a slight issue, in that some of these other intervals
express some of their timetables in terms of days (now very precise) and
some of their timetables in months (still imprecise). But that can be
solved in a follow-up ballot.

Second, although this ballot does not *change* how OCSP validity intervals
are calculated, I believe that it does increase the chances of confusion on
how to do so. Calling out three lines from the ballot diff:

Section 1.6.1 Definitions:
> **Validity Interval**: For CRLs and OCSP responses, the difference in
time between the thisUpdate and nextUpdate field, inclusive.

Section 1.6.4 Conventions:
> **Effective 2022-06-01:** For purposes of computing differences, a
difference of 3,600 seconds shall be equal to one hour, and a difference of
86,400 seconds shall be equal to one day. Any amount of time greater than
this, including fractional seconds and/or leap seconds, shall represent an
additional unit of measure, such as an additional hour or additional day.

Section 4.9.10 On-line revocation checking requirements
> For the purpose of computing an OCSP Validity Interval, a difference of
3,600 seconds shall be equal to one hour, and a difference of 86,400
seconds shall be equal to one day, ignoring leap-seconds.

The first two quotes appear to combine to say that, for OCSP responses, the
validity interval shall be the difference in time between the thisUpdate
and the nextUpdate, and that any amount of time greater than that (such as
leap seconds) shall represent an additional day of validity interval.
However, this definition is then superseded by 4.9.10, which says that OCSP
validity intervals ignore leap seconds.

I believe that the BRs should unify on either always including leap seconds
(and that therefore CAs should be careful to not run right up against the
limits, in case a leap second is inserted), or on always ignoring leap
seconds. In particular, I propose the following text be included in section
4.9.10 in this ballot:
> **Effective prior to 2022-06-01:** For the purpose of computing an OCSP
Validity Interval, a difference...

If folks believe that that change should not be included in this ballot,
then I think that this ballot should not attempt to unify the calculation
of the validity interval for OCSP and CRLs, as doing so leads to this
confusion.

Aaron

On Thu, Nov 18, 2021 at 7:43 AM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Ballot SC-52: Specify CRL Validity Intervals in Seconds
>
> Purpose of Ballot: Similar to Ballot SC-31 which modified the
> specification of
>
> OCSP validity periods to be in seconds, this ballot modifies the
> specification
>
> of CRL validity periods to be in seconds to avoid confusion about exactly
> which
>
> periods are valid and which are not.  The ballot also specifies that other
> time
>
> periods should be handled the same way, which has broader impacts
> throughout
>
> the document.
>
>
>
> The following motion has been proposed by Tim Hollebeek of DigiCert and
> endorsed
>
> by Trevoli Ponds-White of Amazon and Kati Davids of GoDaddy.
>
>
>
> ---MOTION BEGINS---
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management
>
> of Publicly-Trusted Certificates” (“Baseline Requirements”), based on
> Version 1.8.0:
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
>
>
> https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...0c265a673b10c460264a721214b902484c0d1c1f
>
>
>
> ---MOTION ENDS---
>
>
>
> This ballot proposes a Final Maintenance Guideline.
>
>
>
> The procedure for approval of this ballot is as follows:
>
>
>
> Discussion (7+ days)
>
> Start Time: November 18, 2021 10:30am Eastern
>
> End Time: No earlier than November 25, 2021 10:30 am Eastern
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20211118/51490ddd/attachment.html>