[Servercert-wg] Ballot SC-52 version 2: Specify CRL Validity Intervals in Seconds
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Tue Jan 4 11:38:22 UTC 2022
Happy New Year everyone :-)
On 16/12/2021 12:10 π.μ., Aaron Gable wrote:
> I'd love a little more information on this difficulty.
>
> The standard crontab syntax has never supported "perform this task
> every X months" even for X <= 12; it has only ever supported "perform
> this task in months X,Y, and Z", where those are integers representing
> January through December. You can say something /that looks like/ "do
> this every 12 months", but that actually means "do this in months
> /divisible by 12/", i.e. every December.
It's complicated, it depends if the period is divisible by 2, 3, 4, 6 or
not.
You can have a crontab entry of "0 0 1 2/3 * task" to "do this task
*every* 3 months starting in February", i.e. at months 2, 5, 8, 11, 2,...
but if you have a crontab entry of "0 0 1 2/5 * task", it will mean "do
this task at months 2, 7, 12, 2, ...".
>
> A task to update CRLs which is scheduled to occur every Jan 1st abides
> by the new requirements (once every 367 days) just as easily as it
> abided by the old requirements (once every 12 months).
If you need to perform an offline ceremony every 1st of November, then
with the 367 days it is fairly easy to miss a deadline because a key
person might be on sick leave, it will be a non-working day (e.g.
Sunday), etc. This means that you would be forced to drift and set the
ceremony every 11 months for safety (above and beyond).
When a requirement mentions that a DR test must be performed annually
and the last test was performed in December 2020 after getting an alert
Dec 1, 2020, you still want the alert to be sent Dec 1 2021 because the
company knows that "December is the DR-Test month". Sending the alert
every "11 months" for safety, will shift annually scheduled tasks to
other periods of time that may not be convenient for the CA because, for
example, November has other scheduled priorities. This continuous
"drift" probably doesn't make too much sense for everything. Similarly,
when the NSRs ask for tasks to be performed every 31 days it means you
can schedule it on the first day of each month without any issues. This
"drifting" issue will produce more problems.
The SCWG documents have survived the repetitive events all these years
with only one challenge for the NSR's periodic events. We addressed that
in ballot 210
<https://cabforum.org/2017/08/31/ballot-210-misc-changes-network-certificate-system-security-requirements/>.
I recall the discussions being around the "30 days" being unreasonably
strict, causing task drifts for no good reason. CAs needed the
flexibility for scheduling those tasks and Browsers were ok with that
flexibility since there was no significant security benefit for
requiring something every 30 days instead of "every month".
It would be interesting and very useful if the proposers of the ballot
could provide an example of other industries that have adopted this
drifting practice, for example performing "annual" tasks every "11 months".
A solution to this problem would be for the ballot to allow an
additional 10% for every "daily", "monthly", "yearly". In the worst
case, this would allow a yearly event to be scheduled for November 1st
and have a full month leeway for possible set-backs. Would people
support this change?
We also noticed that the ballot has 2 definitions of "hour":
1. "a difference of 3,600 seconds shall be equal to one hour" (in
section 1.6.4).
2. "an hour is measured as 3,600 seconds" (in section 4.9.10).
and 4 definitions of "day":
1. "a difference of 86,400 seconds shall be equal to one day, ignoring
leap seconds" (in section 1.6.4).
2. "a day is measured as 86,400 seconds, ignoring leapseconds." (in
section 4.9.10).
3. "a day is measured as 86,400 seconds." (in section 6.3.2).
4. "a day is measured as 86,400 seconds, ignoring leap seconds." (in
section 6.3.2).
The "ignoring leapseconds" is not necessary, since the definition uses
an exact number of seconds. Repeating identical or rephrased definitions
is unnecessary and would increase the risk of misinterpretation.
Using the ballot definition of day as a "unit of measure
<https://en.wikipedia.org/wiki/Non-SI_units_mentioned_in_the_SI>" (86400
SI seconds), "performing a task twice, 1 day and 1 second apart", i.e.
86401 seconds apart, *is not* "daily".
Dimitris.
>
> Just because a requirement is specified to the precision of seconds
> does not mean that the systems which abide by that requirement need to
> be specified at the same precision -- they simply need to abide by it.
> A process which occurs every 11 months will trivially abide by a
> 367-day requirement, no matter what level of precision those months
> are measured to.
>
> Aaron
>
> On Wed, Dec 15, 2021 at 5:06 AM Wendy Brown - QT3LB-C via
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
> although not a voting member - I agree with Dimitiris
>
> Wendy
>
> Wendy Brown
> Supporting GSA FPKI
> Protiviti Government Services
>
> 703-965-2990 (cell)
>
> wendy.brown at gsa.gov
> wendy.brown at protiviti.com
>
>
>
> On Wed, Dec 15, 2021 at 12:51 AM Dimitris Zacharopoulos (HARICA)
> via Servercert-wg <servercert-wg at cabforum.org> wrote:
>
>
> HARICA disagrees with adding the following text to the
> Baseline Requirements:
>
> /"**Effective 2022-06-01:** For purposes of computing
> differences, a difference of 3,600 seconds shall be equal to
> one hour, and a difference of 86,400 seconds shall be equal to
> one day, ignoring leap seconds. Any amount of time greater
> than this, including fractional seconds, shall represent an
> additional unit of measure, such as an additional hour or
> additional day."/
>
> My team has advised me that when using the standard (vixie)
> cron, an admin cannot state that an action must take place:
>
> * every x minutes, for x>60
> * every x hours, for x>24
> * every x days, for x>1
> * every x months, for x>12
>
> An admin would need to create custom scripts to overcome these
> problems, thus creating a possibility of human error. It is
> also not possible to specify seconds. This is just one of the
> tools that can be used by admins. Windows has the same
> limitations in the "tasks" scheduling tool.
>
> This is a very simple indication that such a change in the
> requirements will require significant analysis and
> implementation effort by all CAs without good justification.
>
> HARICA still doesn't see a clear benefit from generalizing the
> expectation that all time intervals in the BRs, EVGs, NetSec
> should be evaluated at the level of 1 second which is an
> "expensive" compliance obligation and should be
> applied/enforced in areas where it is really needed. The
> necessity may come from interoperability risks as we have seen
> for the validity of certificates and OCSP/CRL. If other areas
> seem appropriate for this level of accuracy, we should
> identify, justify and add to the requirements instead of
> making a general requirement for such an expensive operation.
>
>
> Dimitris.
>
> On 2/12/2021 5:20 μ.μ., Tim Hollebeek via Servercert-wg wrote:
>>
>> Ballot SC-52 version 2: Specify CRL Validity Intervals in Seconds
>>
>> Purpose of Ballot: Similar to Ballot SC-31 which modified the
>> specification of
>>
>> OCSP validity periods to be in seconds, this ballot modifies
>> the specification
>>
>> of CRL validity periods to be in seconds to avoid confusion
>> about exactly which
>>
>> periods are valid and which are not. The ballot also
>> specifies that other time
>>
>> periods should be handled the same way, which has broader
>> impacts throughout
>>
>> the document.
>>
>> These changes should not be interpreted as implying that
>> missing a deadline by
>>
>> a few seconds is any more or less important than it
>> previously was. The
>>
>> changes are merely intended to provide additional clarity and
>> precision about
>>
>> exactly where the deadlines are.
>>
>> The following motion has been proposed by Tim Hollebeek of
>> DigiCert and endorsed
>>
>> by Trevoli Ponds-White of Amazon and Kati Davids of GoDaddy.
>>
>> ---MOTION BEGINS---
>>
>> This ballot modifies the “Baseline Requirements for the
>> Issuance and Management
>>
>> of Publicly-Trusted Certificates” (“Baseline Requirements”),
>> based on Version 1.8.0:
>>
>> MODIFY the Baseline Requirements as specified in the
>> following Redline:
>>
>> https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...2b9cf93af71233095f370cdc1d1b587166da4b07
>>
>> ---MOTION ENDS---
>>
>> This ballot proposes a Final Maintenance Guideline.
>>
>> The procedure for approval of this ballot is as follows:
>>
>> Discussion (7+ days)
>>
>> Start Time: December 2, 2021 10:30 am Eastern
>>
>> End Time: No earlier than December 9, 2021 10:30 am Eastern
>>
>> Vote for approval (7 days)
>>
>> Start Time: TBD
>>
>> End Time: TBD
>>
>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220104/127ed310/attachment-0001.html>
More information about the Servercert-wg
mailing list