<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 5/1/2022 10:22 π.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYC4A-TNbftby5Y0isjtEkONvGhvqYLV7JuReNpGc-iow@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 5, 2022 at 2:33
AM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true"
class="moz-txt-link-freetext">dzacharo@harica.gr</a>>
wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> 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).<br>
<br>
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.<br>
<br>
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?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks for your reply - I think this perhaps captures why
I still believe there may be a disconnect.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYC4A-TNbftby5Y0isjtEkONvGhvqYLV7JuReNpGc-iow@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>>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.</div>
</div>
</div>
</blockquote>
<br>
I understand that it needs to happen <b>before</b> (not even equal)
to that deadline.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYC4A-TNbftby5Y0isjtEkONvGhvqYLV7JuReNpGc-iow@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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 <i>more</i> frequently,
not at <i>exactly the maximum specified</i>.</div>
</div>
</div>
</blockquote>
<br>
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".<br>
<br>
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".<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYC4A-TNbftby5Y0isjtEkONvGhvqYLV7JuReNpGc-iow@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
</div>
</div>
</blockquote>
<br>
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:<br>
<br>
<span class="blob-code-inner blob-code-marker js-code-nav-pass "
data-code-marker="+"><i><span class="pl-mb">**Effective
2022-06-01:**</span></i><i> 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.</i><br>
<br>
</span>Would it be more clear to say:<br>
<br>
<i><span class="blob-code-inner blob-code-marker js-code-nav-pass "
data-code-marker="+"><span class="pl-mb">**Effective
2022-06-01:**</span> For purposes of computing differences <b>of
hours and days</b>, 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.</span></i><br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYC4A-TNbftby5Y0isjtEkONvGhvqYLV7JuReNpGc-iow@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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. <br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYC4A-TNbftby5Y0isjtEkONvGhvqYLV7JuReNpGc-iow@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>So hopefully that captures the concern:</div>
<div>- 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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYC4A-TNbftby5Y0isjtEkONvGhvqYLV7JuReNpGc-iow@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>- 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)</div>
<div>- 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)</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
</body>
</html>