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

Tim Hollebeek tim.hollebeek at digicert.com
Fri Nov 19 20:57:33 UTC 2021

So, that’s actually a legitimate position, and it was Corey’s original position before we added the effective date.  One of the reasons we added an effective date was to allow CAs to have time to make adjustments in the event that they have problems with some of the other periods that are affected.  As a practical matter, though, if you don’t measure 24 hours or five days to revoke a certificate down to the second, you’re already in trouble, as plenty of incidents have already been filed for missing revocation deadlines by fairly small time periods.  So I’d advise CAs to watch those particular ones pretty carefully.


We find the consistency in having one set of date / time rules for the entire BRs to be pretty compelling.  I think different sets of rules for different things is more likely to cause compliance problems instead of solving them.


In fact, one can argue that the reason this ballot is necessary is because a previous effort focused too closely on OCSP validity periods without doing a more wholistic analysis of the problem and the solution(s).  If there are actually time periods where this level of accuracy causes problems instead of solving them, I would love to know what those are so we can discuss and fix them.  That would be a very productive use of this discussion period.




From: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr> 
Sent: Friday, November 19, 2021 2:41 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



I thought there was rough consensus NOT to extend the "1 sec accuracy" to time duration requirements other than the CRL and OCSP.

For example, measuring 24 hours or 5 days to revoke a certificate doesn't need the accuracy of a second.

It's not easy to programmatically measure this level of accuracy for every CA process. When the requirements identify this level of accuracy (e.g. RFC 5280), it makes sense to programmatically enforce them, otherwise it is too painful to implement for every time measurement and produces very little -if any- security improvements to the ecosystem.

HARICA does not support the current proposal to extend the accuracy to the entirety of the BRs (and by extension to NetSec and EV Guidelines).


On 18/11/2021 5:43 μ.μ., Tim Hollebeek via Servercert-wg 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.




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:






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> 


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

More information about the Servercert-wg mailing list