<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 5/1/2022 9:31 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvZpSYR=RhfhHfN58MNvP37+hXGiTmiRT=qyCN3tVyNKSg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
</div>
</blockquote>
<br>
<br>
<ul>
<li>For Random Values no more than 30 days from its creation</li>
<li>For the CAA Records (they MUST do so within the TTL of the CAA
record, or 8 hours, whichever is greater)</li>
<li>4.2.1 about reusing information no more than 398 days</li>
<li>...<br>
</li>
</ul>
I don't assume every CA has implemented these checks to the accuracy
of seconds. If days are introduced at the accuracy of 1'', all CA
systems must be reviewed and possibly updated to ensure their
controls are measured at this precision level or ensure this is done
sooner than the maximum, for safety. <br>
<br>
I'm merely proposing to add a recommendation for CAs to adopt safer
margins than the max limits in the BRs to signal this expectation in
a clearer way. <br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZpSYR=RhfhHfN58MNvP37+hXGiTmiRT=qyCN3tVyNKSg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
<br>
<ul>
<li>1l: within six (6) months. This would possibly be affected.</li>
<li>2j: at least every three (3) months. This would possibly be
affected.</li>
<li>3e: at least once every 31 days. That was supposed to be once
a month. Looks ok.</li>
<li>4c (1): one (1) week of receiving a request from the CA/B
Forum. That doesn't seem likely to happen but it would possibly
be affected :)</li>
<li>4c (3): at least every three (3) months. This would possibly
be affected.<br>
</li>
<li>4d: at least an annual basis. This would possibly be affected.</li>
<li>4f: ninety-six (96) hours. That was supposed to be 4 days max.
Looks ok.</li>
</ul>
<p>I believe that's all but I'd appreciate someone double checking.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZpSYR=RhfhHfN58MNvP37+hXGiTmiRT=qyCN3tVyNKSg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
Indeed, that's why I asked for a small clarification in the proposal
to make it unambiguous that this statement affects requirements
specified in "hours" and "days" only.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZpSYR=RhfhHfN58MNvP37+hXGiTmiRT=qyCN3tVyNKSg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
<br>
Exactly, this was unrelated to the goal of this ballot and was
hoping to discuss separately. That's why HARICA recommended removing
this part from the ballot. We could discuss this more general "time
alignment" issue separately and more holistically by carefully
reviewing all documents and achieve consistency.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvZpSYR=RhfhHfN58MNvP37+hXGiTmiRT=qyCN3tVyNKSg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</blockquote>
<br>
We have both been involved in the Forum and its activities for some
time and we know that the expectation/good practice is to implement
controls below the upper bounds for safety. Someone who reads the
BRs for the first time will probably not immediately get that, not
with the current language anyway, and will likely implement some/all
(?) systems/controls using the upper bounds. I believe we can make
this expectation a bit clearer to assist current and future
implementations of the BRs. I hope this makes my intention a bit
clearer.<br>
</body>
</html>