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

[Ryan Sleevi]

On Wed, Jan 5, 2022 at 2:15 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> 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 this might be more useful when discussing something concrete. That
is, I'm not sure where you believe something is or is not the expectation
of the author, and so specific requirements might be useful. I believe all
the (BR direct) requirements are very much intended as "hard limit and not
a second later", but it sounds like you may still disagree, and so I'm not
sure which requirement.

I haven't done the exhaustive review of the NCSSRs for this, but it might
save time if you have specific examples.

I do think there's a meaningful difference when discussing 366 days vs 402
days though - a full month difference vs a day difference - so I'm not sure
the "blanket approach" is really the right way. If we assume everything
were to be made abundantly clear about a hard limit, what specifically
would need slack (in the NCSSRs)


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

Thanks for clarifying where that concern is! That's an excellent point, but
if you look at the NCSSRs with respect to the day/hour question, I think
you should see it's OK?

That said, there is definitely benefit to looking at converting some of the
others to explicit day/hour based periods (e.g. 7/92 days for vulnerability
scanning vs one week/three months, 92 days for account deactivation). These
are security-critical tasks that you really are capturing an upper-bound on
(and the language is fairly explicit on that being the maximum period and
an expectation of greater frequency)

Basically, "slack" implies that a CA meeting the level (e.g. 3 months) is
acceptable, while the language tries to make clear that's the _longest_
acceptable, with the wording trying to be clear "do it more frequently"
("at least"). But that's worthy of a separate discussion.


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

I wouldn't say such a disturbance would be unnecessary - I think it'd
probably be much clearer what the expectations are. But if you just meant
that it was unrelated to the goal of this ballot, I agree, and that's why
the language suggestion I made was trying to be scoped narrowly for the
immediate goal :) Your (later) reference to my October message is in line
with that - if we want something to be calendrically aligned for per-second
accuracy, we can build that in, but that's not a 10% slack - that's a much
narrower (+1 unit of measure). However, for things that we really *do* want
more frequently then calendrical, specifying something as 90 days perhaps
helps make it clearer that a calendrical 3 month approach *wouldn't* comply,
and so CAs would understand the need to do it more frequently if they want
calendrical alignment (e.g. the 1st of every month)


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

I'm still not sure I understand that. Even if all the periods were changed
(e.g. from months to hours), the language of the current requirements is
still that it's the absolute longest period you can do something. If I
understand your point, it's that if CAs were taking advantage of that (e.g.
by scheduling calendars for the longest possible), this would break them,
but that seems both acceptable and desirable (as a separate ballot), since
the goal, as written, is clearly for these to be upper bounds, with CAs
being well within safety margins by doing things more frequently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220105/6c4fb745/attachment-0001.html>