[Servercert-wg] Ballot SC-52 version 2: Specify CRL Validity Intervals in Seconds

[Dimitris Zacharopoulos (HARICA)]

On 5/1/2022 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:
>
> The current BRs don't have "soft" or "hard" limits except for some 
> cases where we use SHOULD and SHALL for 397 and 398 days validity. If 
> we want to have this notion of "hard" deadlines, if the expectation is 
> to run a task at least monthly, we already say that it needs to be 
> executed "at least every 31 days". The expectation is clear (monthly), 
> the precision is aligned (31 days) and the implementation is simple 
> and convenient.
>
> This is not the same for cases where the expectation is to execute 
> something quarterly and the requirements say "at least every 90 days" 
> because the precision misses the expectation. In this case, the CA is 
> forced to drift the quarters to be on the safe side. If we wanted to 
> follow the existing patterns, we would need to make this "at least 
> every 93 days". Even for the status of subCAs in OCSP responses we 
> didn't say "at least every 360 or 365 days" but used "at least every 
> 367 days" to help CAs implement it annually.
>
> Our "danger zone" should be practical if possible. Like I said, the 
> drifting problem may create security problems if a CA needs to build 
> custom code and complicated procedures for otherwise simple scheduling 
> tasks.

I recalled the conversation from October 
<https://lists.cabforum.org/pipermail/validation/2021-October/001708.html> 
where you noted that a month being 30 days and a year 365 days is 
inconsistent of how Root programs measure time intervals. I think in 
parallel with this ballot we could go over the various time intervals 
and make things more consistent to avoid ambiguity. It's just a few 
places outside the certificate, crl, ocsp validity periods.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220105/95a86fab/attachment.html>