<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:15 PM 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>
It is not just inconvenient, it is not the expectation of the
author. If the author of the document expected an event to occur at
least every 1 day, an implementer should be allowed to schedule this
event every 24 hours, otherwise it doesn't meet the expectation of
the author. Similarly with the annual expectation. If the author
wanted a hard limit and "not a second later", then this hard limit
should take into account implementation challenges and security
risks. If there is a slightly increased hard limit that has
negligible security impact but is more convenient for implementation
purposes and even readability, then IMHO it should be a preferred
option.<br></div></blockquote><div><br></div><div>I think this might be more useful when discussing something concrete. That is, I'm not sure where you believe something is or is not the expectation of the author, and so specific requirements might be useful. I believe all the (BR direct) requirements are very much intended as "hard limit and not a second later", but it sounds like you may still disagree, and so I'm not sure which requirement.</div><div><br></div><div>I haven't done the exhaustive review of the NCSSRs for this, but it might save time if you have specific examples.</div><div><br></div><div>I do think there's a meaningful difference when discussing 366 days vs 402 days though - a full month difference vs a day difference - so I'm not sure the "blanket approach" is really the right way. If we assume everything were to be made abundantly clear about a hard limit, what specifically would need slack (in the NCSSRs)</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 understood this ballot to apply to NCSSRs and EV Guidelines as
well. Section 5 of the BRs say:<br>
<br>
<i>"The CA/Browser Forum's Network and Certificate System Security
Requirements are incorporated by reference as if fully set forth
herein."</i></div></blockquote><div><br></div><div>Thanks for clarifying where that concern is! That's an excellent point, but if you look at the NCSSRs with respect to the day/hour question, I think you should see it's OK?</div><div><br></div><div>That said, there is definitely benefit to looking at converting some of the others to explicit day/hour based periods (e.g. 7/92 days for vulnerability scanning vs one week/three months, 92 days for account deactivation). These are security-critical tasks that you really are capturing an upper-bound on (and the language is fairly explicit on that being the maximum period and an expectation of greater frequency)</div><div><br></div><div>Basically, "slack" implies that a CA meeting the level (e.g. 3 months) is acceptable, while the language tries to make clear that's the _longest_ acceptable, with the wording trying to be clear "do it more frequently" ("at least"). But that's worthy of a separate discussion.</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><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">
<div>I highlight this as a disconnect, because the NCSSRs
already have the slack built in (by using the vaguer terms
that are subject to auditor interpretation, rather than
consistent interpretation); "at least an annual basis" is
such an example.<br>
</div>
</div>
</div>
</blockquote>
<br>
Exactly, and this is resolved by scoping the proposed 1.6.4 language
to only "hours" and "days" as mentioned in my previous post. I hope
you can understand the unnecessary disturbance this ballot would
cause it it were applied to "months", "quarters" or "years".<br></div></blockquote><div><br></div><div>I wouldn't say such a disturbance would be unnecessary - I think it'd probably be much clearer what the expectations are. But if you just meant that it was unrelated to the goal of this ballot, I agree, and that's why the language suggestion I made was trying to be scoped narrowly for the immediate goal :) Your (later) reference to my October message is in line with that - if we want something to be calendrically aligned for per-second accuracy, we can build that in, but that's not a 10% slack - that's a much narrower (+1 unit of measure). However, for things that we really <i>do</i> want more frequently then calendrical, specifying something as 90 days perhaps helps make it clearer that a calendrical 3 month approach <i>wouldn't</i> comply, and so CAs would understand the need to do it more frequently if they want calendrical alignment (e.g. the 1st of every month)</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>
Of course, one might schedule things as they like (probably CAs
reading this thread :-) but the author of the document doesn't set
the expectation for CAs to use limits in the document as the
absolute "ceiling", to be on the safe side. It still allows for the
bare minimum. If we want to change that, we need to communicate it
better in the current BRs.<br></div></blockquote><div><br></div><div>I'm still not sure I understand that. Even if all the periods were changed (e.g. from months to hours), the language of the current requirements is still that it's the absolute longest period you can do something. If I understand your point, it's that if CAs were taking advantage of that (e.g. by scheduling calendars for the longest possible), this would break them, but that seems both acceptable and desirable (as a separate ballot), since the goal, as written, is clearly for these to be upper bounds, with CAs being well within safety margins by doing things more frequently. </div></div></div>