<div dir="ltr">If I may, I believe the disconnect in this conversation can be summarized as follows:<div><br></div><div>- 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.</div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 5, 2022 at 8:44 AM Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 7:31 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>I clearly understand your opinion about the "ceiling" requirements.
However, this is not what those documents currently say. </div></blockquote><div><br></div><div>Could you be more specific about what you believe the documents say?</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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></div></blockquote><div><br></div><div>I totally hear you on this, but I think this is overlooking my previous reply. The goal is <b>not</b> to have a pen test every 365/366 days, it's to have a pen test <b>at least</b> every 365/366 days. In practice, a forward thinking CA would do this <i>more</i> frequently: the annual requirement just represents the upper-bound.</div><div><br></div><div>This is where the Baseline Requirements are <i>not</i> the definition of what a "great" CA looks like, but rather, the absolute minimum that CAs need to meet. </div><div><br></div><div>Just to recap where we're talking about intervals:</div><div><ul><li>4.9.7 CRL issuance ("<i>at least</i> once every twelve months", "<i>at least </i>within 24 hours", "MUST NOT be more than twelve months")</li><li>4.9.10 OCSP ("<i>at least</i> every twelve months", "<i>within</i> 24 hours")</li><li>6.3.2 Operational periods ("MUST NOT have a Validity Period greater than 398 days")</li><li>8.1 Frequency or circumstances of assessment ("no earlier than twelve (12) months prior to", "within ninety (90) days")</li><li>8.6 Communications of results ("no later than three months after")</li><li>5.4.3 Retention period for Audit Logs ("for at least two years")</li><li>5.5.2 Retention period for archive ("at least seven years")</li><li>8.4 Topics covered by assessment ("but in no case may any non-core control be audited less often than once every three years")</li></ul><div>There's no reference to weeks in the BRs, AFAICT.</div></div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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></div></blockquote><div><br></div><div>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.</div><div><br></div><div>That's perhaps the disconnect with understanding your feedback.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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.</div></blockquote><div><br></div><div>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 <i>still</i> good, and shouldn't require the Forum to bless it before a CA does so.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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.</div></blockquote><div><br></div><div>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. </div></div></div>
</blockquote></div>