[Servercert-wg] Discussion Period Begins: SC-52: Specify CRL Validity Intervals in Seconds
Tim Hollebeek
tim.hollebeek at digicert.com
Fri Nov 19 20:10:23 UTC 2021
Yeah, directionally, we support ignoring leap seconds, too. We discussed it a bit internally this morning.
There’s some hilarious internal discussion that makes sense to get out onto the public list for everyone’s enjoyment: it turns out that leap seconds are only announced six months in advance.
This means that, in a quest to develop a system with absolute precision and certainty about which certificate validity periods are legal we have instead created a system where a validly issued certificate can have an invalid lifetime due to a leap second that was announced after it was issued. And tools like zlint would have to periodically download the latest version of the official leap second list in order to accurately make difference calculations. And the tools would have to take into account whether the leap second was announced yet or not at the time of issuance … ugh.
So, yeah. Let’s ignore leap seconds.
-Tim
From: Wayne Thayer <wthayer at gmail.com>
Sent: Friday, November 19, 2021 12:54 PM
To: Aaron Gable <aaron at letsencrypt.org>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: [Servercert-wg] Discussion Period Begins: SC-52: Specify CRL Validity Intervals in Seconds
Thank you Aaron. I went ahead and created a pull request since I originally drafted the ballot: https://github.com/cabforum/servercert/pull/327
I will defer to Tim as the official proposer of the ballot, but I support making these proposed changes and would be happy to add them to the PR.
- Wayne
On Fri, Nov 19, 2021 at 10:19 AM Aaron Gable via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:
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 <mailto: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 <mailto:aaron at letsencrypt.org> >
Sent: Thursday, November 18, 2021 3:52 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto: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 <mailto: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 <mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto: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/a0eea920/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20211119/a0eea920/attachment-0001.p7s>
More information about the Servercert-wg
mailing list