<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 8:53 μ.μ., Dimitris
Zacharopoulos (HARICA) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a2208405-9be6-432e-92d0-e71792f3a3a7@harica.gr"><br>
The current BRs don't have "soft" or "hard" limits except for some
cases where we use SHOULD and SHALL for 397 and 398 days validity.
If we want to have this notion of "hard" deadlines, if the
expectation is to run a task at least monthly, we already say that
it needs to be executed "at least every 31 days". The expectation
is clear (monthly), the precision is aligned (31 days) and the
implementation is simple and convenient.<br>
<br>
This is not the same for cases where the expectation is to execute
something quarterly and the requirements say "at least every 90
days" because the precision misses the expectation. In this case,
the CA is forced to drift the quarters to be on the safe side. If
we wanted to follow the existing patterns, we would need to make
this "at least every 93 days". Even for the status of subCAs in
OCSP responses we didn't say "at least every 360 or 365 days" but
used "at least every 367 days" to help CAs implement it annually.
<br>
<br>
Our "danger zone" should be practical if possible. Like I said,
the drifting problem may create security problems if a CA needs to
build custom code and complicated procedures for otherwise simple
scheduling tasks.</blockquote>
<br>
I recalled the <a moz-do-not-send="true"
href="https://lists.cabforum.org/pipermail/validation/2021-October/001708.html">conversation
from October</a> where you noted that a month being 30 days and a
year 365 days is inconsistent of how Root programs measure time
intervals. I think in parallel with this ballot we could go over the
various time intervals and make things more consistent to avoid
ambiguity. It's just a few places outside the certificate, crl, ocsp
validity periods.<br>
<br>
<br>
</body>
</html>