<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 4/1/2022 10:59 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvbAwNhr+se7L1YWnCCRrWZ7xOxbU=Noe+KmjpTmHJZaag@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 Tue, Jan 4, 2022 at 6:38
AM Dimitris Zacharopoulos (HARICA) via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</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>A solution to this problem would be for the ballot to
allow an additional 10% for every "daily", "monthly",
"yearly". In the worst case, this would allow a yearly
event to be scheduled for November 1st and have a full
month leeway for possible set-backs. Would people support
this change?<br>
</div>
</blockquote>
<div><br>
</div>
<div>It's not clear that this is necessary.</div>
<div><br>
</div>
<div>The Baseline Requirements are to set the upper-bound on
what's permissible. It's meant to be the absolute limit.
You're totally right that CAs could run into issues if they
schedule things to that absolute limit, but they can address
that risk by doing things less than that.</div>
<div><br>
</div>
<div>There's long been a tension between wanting to set a
"soft limit" and a "hard limit", but it sounds like you're
suggesting making all the (current) hard limits soft. That
seems to be a step back for security.</div>
<div><br>
For example, rather than adding additional overhead, CAs
could recognize the risk of the situation you describe, and
instead build their processes to address that risk, such as
by issuing their CRLs every 6 or 9 months. There's no reason
to think that running against the absolute limit (e.g. every
365 days) is actually the desirable outcome - it's just the
upper bound. We saw this issue come up with 397 vs 398 days,
and we saw some surprisingly (negative) reaction to the
quite sensible SHOULD at 397, and we saw plenty of issues
from CAs that ignored that, in favor of getting as close as
they can to the max.</div>
<div><br>
</div>
<div>Thus, the downside risk for your proposal is that we'd
see just more of that same - CAs that leverage that proposed
10% padding (which seems quite excessive), run to the
absolute max, and still have issues. I totally understand
wanting to be sensitive to CAs' business opportunities, but
it seems that a CA that had their ceremony every 6 months,
or every 9 months - which are still quite long periods -
could still fully comply, and naturally have their headroom
built in.</div>
<div><br>
</div>
<div>So that's where it's a bit difficult to see the
justification for such a change, and it certainly would be a
step in the opposite direction from where the past several
years of the Forum work has been going towards. Even "every
11 months" seems... reasonable?</div>
</div>
</div>
</blockquote>
<br>
Please don't get me wrong, HARICA supports the increased accuracy of
1'' for the validity of CRLs (and all other areas necessary for
security) as we have done in the certificate validity and OCSP
responses. The "catch-all" requirement is the one which -in our
opinion- creates more problems than it solves. I identified some of
them in my previous post. <br>
<br>
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>
<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>