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

Fri Nov 19 17:18:57 UTC 2021

Absolutely; I have three proposals below. I don't expect the fixed-width
formatting and diff coloring to come through on servercert-wg, but
hopefully it'll make it to your personal inbox intact.

Personally, I'd prefer that all time periods be computed ignoring leap
seconds. Counting leap seconds, and therefore having the time between two
timestamps which are ostensibly represent an interval of 24 hours (e.g.
2021-11-01 12:34:56 and 2021-11-02 12:34:55) *sometimes* represent more
than 24 hours feels like a "gotcha!". It does encourage CAs to not push
right up against the specified limits, which is a good thing, but it feels
to me like it would be preferable to incentivise that in a way that doesn't
rely on random fluctuations in the Earth's rotational period. (Also, thanks
to global climate disaster, the melting ice caps have contributed to the
last five years having some of the fastest Earth rotation on record, and
the IERS is currently considering *negative* leap seconds.)

So my personal favorite diff to include in this ballot would be:

```

diff --git a/docs/BR.md b/docs/BR.md
index 912cbf1..b0220dd 100644
--- a/docs/BR.md
+++ b/docs/BR.md
@@ -573,7 +573,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "S

 By convention, this document omits time and timezones when listing
effective requirements such as dates. Except when explicitly specified, the
associated time with a date shall be 00:00:00 UTC.

-**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.
+**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, ignoring leap seconds. Any amount
of time greater than this, including fractional seconds, shall represent an
additional unit of measure, such as an additional hour or additional day.

 # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

@@ -1324,7 +1324,7 @@ defined by RFC6960.

 OCSP responders operated by the CA SHALL support the HTTP GET method, as
described in RFC 6960 and/or RFC 5019.

-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.
+As stated in [Section 1.6.4](#164-conventions), for the purpose of
computing an OCSP Validity Interval, an hour is measured as 3,600 seconds
and a day is measured as 86,400 seconds, ignoring leap seconds.

 For the status of Subscriber Certificates:

@@ -1748,7 +1748,9 @@ Subscriber Certificates issued on or after 1
September 2020 SHOULD NOT have a Va
 Subscriber Certificates issued after 1 March 2018, but prior to 1
September 2020, MUST NOT have a Validity Period greater than 825 days.
 Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018
MUST NOT have a Validity Period greater than 39 months.

-As stated in [Section 1.6.4](#164-conventions), a day is measured as
86,400 seconds. Any amount of time greater than this, including fractional
seconds and/or leap seconds, shall represent an additional day. For this
reason, Subscriber Certificates SHOULD NOT be issued for the maximum
permissible time by default, in order to account for such adjustments.
+**For Certificates issued prior to 2022-06-01:** For the purpose of
calculations, a day is measured as 86,400 seconds. Any amount of time
greater than this, including fractional seconds and/or leap seconds, shall
represent an additional day. For this reason, Subscriber Certificates
SHOULD NOT be issued for the maximum permissible time by default, in order
to account for such adjustments.
+
+**For Certificates issued on or after 2022-06-01:** As stated in [Section
1.6.4](#164-conventions), a day is measured as 86,400 seconds, ignoring
leap seconds. Any amount of time greater than this, including fractional
seconds, shall represent an additional day. For this reason, Subscriber
Certificates SHOULD NOT be issued for the maximum permissible time by
default.

 ## 6.4 Activation data
```

But I recognize that such a change is perhaps larger than this ballot wants
to tackle, and would bring in more discussion. So for taking things the
other way, I would propose the following simple diff, which changes how
OCSP validity intervals are calculated (to include leap seconds, instead of
ignoring them) as of the effective date of the ballot:

```
diff --git a/docs/BR.md b/docs/BR.md
index 912cbf1..b90eb98 100644
--- a/docs/BR.md
+++ b/docs/BR.md
@@ -1324,7 +1324,7 @@ defined by RFC6960.

 OCSP responders operated by the CA SHALL support the HTTP GET method, as
described in RFC 6960 and/or RFC 5019.

-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.
+**For OCSP responses issued prior to 2022-06-01:** 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.

 For the status of Subscriber Certificates:
```

If folks don't think that is explicit enough, then I would borrow the
language from the section on Certificate Profiles to make the point clear:

```
diff --git a/docs/BR.md b/docs/BR.md
index 912cbf1..b2071ac 100644
--- a/docs/BR.md
+++ b/docs/BR.md
@@ -1324,7 +1324,9 @@ defined by RFC6960.

 OCSP responders operated by the CA SHALL support the HTTP GET method, as
described in RFC 6960 and/or RFC 5019.

-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.
+**For OCSP responses issued prior to 2022-06-01:** 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.
+
+**For OCSP responses issued on or after 2022-06-01:** As stated in
[Section 1.6.4](#164-conventions), an hour is measured as 3,600 seconds,
and a day is measured as 86,400 seconds. Any amount of time greater than
this, including fractional seconds and/or leap seconds, shall represent an
additional day. For this reason, OCSP responses SHOULD NOT be issued for
the maximum permissible time by default, in order to account for such
adjustments.

 For the status of Subscriber Certificates:
```

It doesn't appear that this ballot is represented by a PR, just a diff
currently, otherwise I'd use GitHub's "suggest an edit" feature directly on
that PR.

Aaron

On Fri, Nov 19, 2021 at 7:44 AM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Hey Aaron,
>
>
>
> Thank you very much for this detailed analysis.  As I mentioned on
> yesterday’s validation call, this is exactly the sort of risk I’m concerned
> about with this ballot.
>
>
>
> Thanks for catching the leap second issue.  I think it’s important that we
> resolve that and have a consistent way of converting days -> seconds
> throughout the document.
>
>
>
> If you would like to take a whack at proposed text to fix it, I’m
> listening and interested.
>
>
>
> -Tim
>
>
>
> *From:* Aaron Gable <aaron at letsencrypt.org>
> *Sent:* Thursday, November 18, 2021 3:52 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Discussion Period Begins: SC-52: Specify
> CRL Validity Intervals in Seconds
>
>
>
> 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/20211119/beb1c994/attachment-0001.html>
