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

Sat Nov 20 10:39:17 UTC 2021

On 19/11/2021 10:57 μ.μ., Tim Hollebeek wrote:
>
> 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.
>

I am not entirely sure I understand how enforcing "1-second accuracy" 
would address the "plenty of incidents" related to revocation deadlines. 
These incidents missed deadlines of entire days, not seconds. This 
ballot won't help with that.

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

The 1-second accuracy started when calculating the certificate validity 
time. We then expanded to OCSP and now on CRLs. A wholistic analysis 
caused by a ballot that changes this requirement for all time intervals, 
is a very time consuming process which will take time from compliance 
and engineering teams for no good security benefit. Instead, focusing 
just on the CRL issuance (notBefore - nextUpdate fields) is a very 
well-defined engineering problem for CA teams to resolve in a timely manner.

IMHO we have other more important ballots to pass (delegation of Domain 
Validation via CNAME, Certificate Profiles) that will improve the 
security of the ecosystem and we should focus our efforts, and 
engineering capacity, to those areas more.

Dimitris.

> -Tim
>
> *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
>
> Tim,
>
> 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).
>
>
> Dimitris.
>
> 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.
>
>     ---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/20211120/44e55038/attachment.html>