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

[Dimitris Zacharopoulos (HARICA)]

On 4/1/2022 10:59 μ.μ., Ryan Sleevi wrote:
>
>
> On Tue, Jan 4, 2022 at 6:38 AM Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
>     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?
>
>
> It's not clear that this is necessary.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?

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.

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,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220105/272c6eef/attachment.html>