[Servercert-wg] Ballot SC-52 version 2: Specify CRL Validity Intervals in Seconds
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Jan 5 19:15:09 UTC 2022
Apologies, I replied before seeing these last two messages :-)
On 5/1/2022 7:38 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Jan 5, 2022 at 12:06 PM Aaron Gable <aaron at letsencrypt.org> wrote:
>
> If I may, I believe the disconnect in this conversation can be
> summarized as follows:
>
> - It is understood that the current requirements are upper bounds,
> and that CAs should be scheduling their recurring tasks at
> intervals notably less than the strict requirements.
> - But at the same time, scheduling things to occur every 23 hours
> or every 11 months is relatively inconvenient, compared to
> scheduling things every 24 hours or 12 months.
>
It is not just inconvenient, it is not the expectation of the author. If
the author of the document expected an event to occur at least every 1
day, an implementer should be allowed to schedule this event every 24
hours, otherwise it doesn't meet the expectation of the author.
Similarly with the annual expectation. If the author wanted a hard limit
and "not a second later", then this hard limit should take into account
implementation challenges and security risks. If there is a slightly
increased hard limit that has negligible security impact but is more
convenient for implementation purposes and even readability, then IMHO
it should be a preferred option.
>
> I /think/ there may be a third disconnect as well:
> - Reading the clarifications (for hours & days) as also applying to
> longer periods, particularly those in the NCSSRs.
>
> I realized after seeing the discussion of weeks, that this might be
> getting interpreted as also applying to the NCSSRs. If they had been
> incorporated into the BRs, that's totally a risk, but the work to
> extract them into a new WG seems to suggest otherwise. In that
> document, the discussion may be different.
I understood this ballot to apply to NCSSRs and EV Guidelines as well.
Section 5 of the BRs say:
/"The CA/Browser Forum's Network and Certificate System Security
Requirements are incorporated by reference as if fully set forth herein."/
>
> I highlight this as a disconnect, because the NCSSRs already have the
> slack built in (by using the vaguer terms that are subject to auditor
> interpretation, rather than consistent interpretation); "at least an
> annual basis" is such an example.
Exactly, and this is resolved by scoping the proposed 1.6.4 language to
only "hours" and "days" as mentioned in my previous post. I hope you can
understand the unnecessary disturbance this ballot would cause it it
were applied to "months", "quarters" or "years".
> My contrasting suggestion would be that, instead, one might
> schedule recurring tasks for 12 hours and 6 months respectively,
> which are both convenient and come in generously below the
> requirements.
>
>
> Yes, exactly.
Of course, one might schedule things as they like (probably CAs reading
this thread :-) but the author of the document doesn't set the
expectation for CAs to use limits in the document as the absolute
"ceiling", to be on the safe side. It still allows for the bare minimum.
If we want to change that, we need to communicate it better in the
current BRs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220105/e130e4b1/attachment.html>
More information about the Servercert-wg
mailing list