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

Fri Nov 19 15:44:56 UTC 2021

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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20211119/45a6a446/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/45a6a446/attachment-0001.p7s>