<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">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><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><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><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. 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><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>- 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>