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

Wed Jan 5 12:31:38 UTC 2022

On 5/1/2022 10:22 π.μ., Ryan Sleevi wrote:
>
>
> 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 clearly understand your opinion about the "ceiling" requirements. 
However, this is not what those documents currently say. If we are to 
move to this direction -which I am fully supportive- it must me done 
collectively and with clear language. With that said, if we are to move 
to this approach defining "ceilings", we need to justify the purpose and 
security implications. For example, I would argue that a CA should be 
able to perform a pen-test annually without caring about the additional 
second or even a day. I would argue that security-wise, performing a 
pen-test every 365 days or every 366 days has negligent impact on the 
security of the system. Obviously this is different from the 
certificate, OCSP, CRL validity some of which have clear and precise 
language coming from normative RFCs.

>
> 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 understand that it needs to happen *before* (not even equal) to that 
deadline.

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

Understood. Please see my previous comment about making this explicit in 
the document(s) because until this is clearly written, there will be CAs 
out there who will read "SHALL execute this at least every 4 days" and 
will set their systems exactly at that number and risk becoming 
non-compliance because of a second (like with the 397, 398 certificate 
validity periods), when the expectation is "SHOULD execute this at least 
every 3 days and SHALL execute at least every 4 days".

I'm sure CAs would welcome a clear "catch-all" requirement that says 
"you must take all those time periods as the absolute ceiling and should 
implement controls below those documented limits for safety".

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

I must have missed that and thank you for pointing it out. I was under 
the impression that we would need to interpret the entirety of the BRs 
for all "computing differences", with the precision of a second. The 
ballot proposes the following:

/**Effective 2022-06-01:**//For purposes of computing differences, a 
difference of 3,600 seconds shall be equal to one hour, and a difference 
of 86,400 seconds shall be equal to one day, ignoring leap seconds. Any 
amount of time greater than this, including fractional seconds, shall 
represent an additional unit of measure, such as an additional hour or 
additional day./

Would it be more clear to say:

/**Effective 2022-06-01:** For purposes of computing differences *of 
hours and days*, a difference of 3,600 seconds shall be equal to one 
hour, and a difference of 86,400 seconds shall be equal to one day, 
ignoring leap seconds. Any amount of time greater than this, including 
fractional seconds, shall represent an additional unit of measure, such 
as an additional hour or additional day./

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

I believe the previous clarification that this accuracy applies for 
hours and days only, was very helpful. To your question about the 
frequency of offline ceremonies, There are those who support that 
offline ceremonies should be done only when absolutely necessary 
(because they contains several additional risks) and those that support 
that they should be done more frequently than absolutely necessary 
because repetition also brings improvements and stability in documented 
procedures.

For the specific issue regarding CRL/OCSP signing ceremonies, we could 
start a separate thread if you believe they should be performed more 
frequently. In order to avoid the risks of inaccessibility to offline 
facilities (as we've seen some cases due to COVID-19 lockdowns), we 
could move to a position of proposing and then requiring (SHOULD and 
then SHALL) the issuance of Root CRLs/OCSP responders/responses twice a 
year but maintain the validity to 12 months.

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

Raising "slightly" with negligent step back for security in order to 
ensure CAs have simple/clean implementation paths and specific language 
that these are indeed "ceilings" and CAs are expected to "do better 
than", doesn't sound so bad to me. But I understand the concern and 
makes sense to try to push this expectation to the document rather than 
"adding slack" to existing requirements.

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

The cost of implementation of viral requirements should be considered. I 
suppose CAs will have time until June 2022 to go over all the normative 
documents that state the terms "hour" and "day" and update their 
implementations if necessary.

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