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

[Aaron Gable]

If I may, I believe the disconnect in this conversation can be summarized
as follows:

- It is understood that the current requirements are upper bounds, and that
CAs should be scheduling their recurring tasks at intervals notably less
than the strict requirements.
- But at the same time, scheduling things to occur every 23 hours or every
11 months is relatively inconvenient, compared to scheduling things every
24 hours or 12 months.

I *think* that this pair of statements is what might lead one to suggest
that the requirements be loosened, so that tasks could be scheduled at
"convenient" intervals (e.g. every 12 months) while still coming in
approximately 10% below the strict requirement. It does make sense to me
that one might read a requirement for a seemingly-convenient period and
come to the conclusion that the intent is for the task to be performed at
that convenient interval, and that a need to perform the task *slightly*
more often than that is a bug, not a feature.

My contrasting suggestion would be that, instead, one might schedule
recurring tasks for 12 hours and 6 months respectively, which are both
convenient and come in generously below the requirements.

Aaron

On Wed, Jan 5, 2022 at 8:44 AM Ryan Sleevi <sleevi at google.com> wrote:

>
>
> On Wed, Jan 5, 2022 at 7:31 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>> I clearly understand your opinion about the "ceiling" requirements.
>> However, this is not what those documents currently say.
>>
>
> Could you be more specific about what you believe the documents say?
>
> That is, for any requirement talking about a date range and some
> upper-bound, it's inherently a ceiling as written, because you cannot let
> more time elapse than the requirement. We don't have, as far as I know, any
> requirements that require you do something exactly (no sooner, no later) -
> they're all of the variation of (no later). But maybe I'm overlooking
> something, so if you can be precise about the concern, that may help.
>
>
>> 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 totally hear you on this, but I think this is overlooking my previous
> reply. The goal is *not* to have a pen test every 365/366 days, it's to
> have a pen test *at least* every 365/366 days. In practice, a forward
> thinking CA would do this *more* frequently: the annual requirement just
> represents the upper-bound.
>
> This is where the Baseline Requirements are *not* the definition of what
> a "great" CA looks like, but rather, the absolute minimum that CAs need to
> meet.
>
> Just to recap where we're talking about intervals:
>
>    - 4.9.7 CRL issuance ("*at least* once every twelve months", "*at
>    least *within 24 hours", "MUST NOT be more than twelve months")
>    - 4.9.10 OCSP ("*at least* every twelve months", "*within* 24 hours")
>    - 6.3.2 Operational periods ("MUST NOT have a Validity Period greater
>    than 398 days")
>    - 8.1 Frequency or circumstances of assessment ("no earlier than
>    twelve (12) months prior to", "within ninety (90) days")
>    - 8.6 Communications of results ("no later than three months after")
>    - 5.4.3 Retention period for Audit Logs ("for at least two years")
>    - 5.5.2 Retention period for archive ("at least seven years")
>    - 8.4 Topics covered by assessment ("but in no case may any non-core
>    control be audited less often than once every three years")
>
> There's no reference to weeks in the BRs, AFAICT.
>
> So all of these represent upper-bounds on security sensitive tasks, and as
> far as I can tell, are all explicitly worded as upper-bounds. Am I
> overlooking an interpretation here?
>
>
>> 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".
>>
>
> I mean, isn't that in the very name of the document - the Baseline
> Requirements? All of these represent the bare minimum controls/safety
> margins, and just like in any safety/security critical environment, the
> expectation is that you build tolerances in to your processes. If the
> requirement is you must support X load, then as engineers, you make sure
> you support X load plus more. If the requirement is you must do something
> no later than 24 hours, then you build your process to look at 12 hours,
> and start escalating at that point, and then hit the safety critical alarms
> when  you get at 8 hours. If you're building something that requires you
> support 200psi, then your "danger zone" is precisely as you approach
> 200psi, because your system is not rated for more by spec - even if you
> would have built in extra tolerances.
>
> That's perhaps the disconnect with understanding your feedback.
>
>
>> 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.
>>
>
> We certainly could, but I think we both agree that's a separate
> discussion. I think the disconnect is whether, in the absence of such a
> mandate (SHOULD/SHALL), is it still a good idea? And I think, as with most
> of the BRs, the answer is "Yes, it is". This is effectively the past
> discussions about lifetimes, and how setting shorter lifetimes
> (voluntarily) is *still* good, and shouldn't require the Forum to bless
> it before a CA does so.
>
>
>> 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.
>>
>
> Hopefully the concrete discussion above helps identify, and clarify, why
> slack seems to be a step backward for security, and an unnecessary concern
> given the existing language.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220105/c4e26ee6/attachment.html>