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

[Ryan Sleevi]

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

> When a "baseline" requirement says that a task must be executed every day,
> every month, every year, then the expectation should be for the CA to
> execute this task within that timeframe, not every 23 hours, every 25 days,
> every 11 months. Sure, we can update the requirements to say that we should
> be issuing Root CRLs every 11 months or even every 6 months but then we
> would be in the same trip where a CA would not be able to fulfill this
> requirement every 6 months but would need to execute every -say- 5 months
> :). My goal is for CAs to be able to fulfill "what's permissible",
> otherwise the BRs are flawed (they intend for something that is not even
> mentioned in the document).
>
> We have had discussions in the past where the client clock skew problem
> made it clear that the 1'' accuracy doesn't practically affect the security
> of Relying Parties. This was when discussing the certificate validity
> RFC5280 definition issue. It is even less impactful when considering tasks
> like "check logs every 31 days" or perform a Disaster Recovery every year
> or execute a pen-test annually.
>
> Perhaps the allowance of an additional 10% (~2 hours for daily tasks, 1
> day for weekly tasks, 3 days for monthly tasks, 9 days for quarterly tasks
> and 1 month for annual tasks) is too much or not appropriate at all. Can
> anyone propose something more reasonable?
>

Thanks for your reply - I think this perhaps captures why I still believe
there may be a disconnect.

I think your reply captures one of the challenges for the BRs. Namely, as
you described it, it sounds like you see these requirements as being a type
of "floor" requirement (a Baseline), which is the minimum to meet. However,
when it comes to these sorts of time periods, it's best to think of them as
"ceiling" requirements - you must not exceed this amount.

I guess a different way of putting it: think of these requirements as sort
of a "greater than" comparison - e.g. "the time it takes the CA to do X
MUST NOT be greater than ...". They represent the hard upper bound, and
then the CA is expected to design their system to not exceed that
upper-bound (e.g. by ensuring they're well within tolerances, by setting -
for themselves - a lower target, so that they have slack they need).

>From your description, I get the sense that you may be viewing these sorts
of requirements as an "equals to" comparison, e.g. "the time it takes the
CA to do X MUST be equal to". With that perspective, if the goal of a
requirement is to have something executed exactly every 24 hours, then the
suggestion is to make the hard upper bound 25 (or, as you propose here,
26.4) hours, with the hope that the CA will understand that means they
should do it every 24 hours.

I hope I haven't misunderstood your response, but if that's the mindset
that you're approaching it with, I do think that approach is somewhat
inconsistent with the direction of the BRs, or the philosophy of setting
those hard upper limits. They're meant to represent the sort of "maximum
acceptable" - the desire, for many of these limits, whether it's lifetimes,
CRLs, or even routine tasks (like CA self-audits), is that CAs are actually
doing them *more* frequently, not at *exactly the maximum specified*.

Obviously, these can vary in different cases. For example, certificate
lifetimes explicitly had some slack built in to them, but that's not
exactly a great illustrative example of the "right" way to do it, given how
many discussions we've had in the Forum about the desire for shorter lived
certificates. Certainly, that one iis also complex, because that slack can
affect billions of subscribers, while for something such as issuing CRLs or
OCSP responses, that both has very limited impact (only a few CAs need to
ensure proper procedures, versus billions of website operators) and
unquestionably benefits from greater frequency.

I'm not sure why you bring up other situations, such as weeks, months, and
years. That's not what the language, as currently written, says: it only
focuses on requirements expressed in hours and days specifically. So for
something specified in months, it's not specified whether a month is 28
days, 30 days, or 31 days. This reveals that the original concern was, in
fact, based on a misunderstanding of the requirement as written. That was
intentionally done, at least in the proposal, precisely to reduce the risk
of broad impact that you feared. However, even if it were the case, it's
unclear to me: are there CAs that truly only visit their (offline)
facilities once a year that this would become an unreasonable burden for? I
would imagine that most CAs have regular need to visit their facilities,
such that incorporating something as simple as a CRL and OCSP signing
ceremony, such as every 6 months, or "9 months since the last one", should
just be a trivial addition to the plans and procedures, and require only 60
or so organizations to make a change.

So hopefully that captures the concern:
- The BRs capture plenty of "ceilings", intentionally, with the
hope/expectation that CAs are building the slack in themselves. Raising
those ceilings seems a step back for security, at least in general.
- The specific concerns about "virality" of the language (specifically with
regard to weeks, months, years) don't apply here, and those remain
calendrical, at least for now (although some should be updated to daily
intervals, but separately)
- Even if they were viral, the practical impact seems to be low, especially
relative to the general benefit, and so it would seem a positive direction
even if it was viral (to weeks/months/years)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220105/cdb325bb/attachment-0001.html>