[Servercert-wg] Ballot SC-52 version 2: Specify CRL Validity Intervals in Seconds

Wed Dec 15 22:10:34 UTC 2021

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.

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

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 listServercert-wg at cabforum.orghttps://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/20211215/5d1fbb6b/attachment-0001.html>