[cabf_validation] CRL Validity Interval Ballot

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Wed Oct 13 07:07:58 UTC 2021


Thank you for the attempt to clarify the nextUpdate values for CRLs to 
match the language from section 4.9.10 regarding the OCSP response validity.

After some review, and since it appears there is consensus to move to 
the "1 sec" accuracy in various fields, HARICA believe we should also 
define that 1 month is equal to 30 days. We already have language to 
specify that 1 day is equal to 86400 seconds but some interpret 12 
months to be 365 days, others consider 360 days as being more accurate, etc.

It would be even better to specify the /nextUpdate /for subCAs in /days/ 
instead of /months/. There are only 4 areas where a requirement is 
specified in months:

  * Section 4.9.7 (as already mentioned)
  * Section 4.9.10 (as already mentioned)
  * Section 8.1 Frequency or circumstances of assessment: /"//The
    point-in-time readiness assessment SHALL be completed no earlier
    than twelve (12) months prior to issuing Publicly-Trusted
    Certificates and..."/
  * Section 8.6 Communication of results: "/The CA MUST make its Audit
    Report publicly available no later than three months after the end
    of the audit period. In the event of a delay greater than three
    months, the CA SHALL provide an explanatory letter signed by the
    Qualified Auditor."/

Thus, if we converted these to days, we would not need to define that a 
month is equal to 30 days.

We also noted that there are already *two places* where we "define" the 
duration of a day:

  * Section 4.9.10: /"//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."/
  * Section 6.3.2: /"For the purpose of calculations, a day is measured
    as 86,400 seconds. Any amount of time greater than this, including
    fractional seconds and/or leap seconds, shall represent an
    additional day. For this reason, Subscriber Certificates SHOULD NOT
    be issued for the maximum permissible time by default, in order to
    account for such adjustments."/
    //

Instead of creating another instance of the same definition in 4.9.7, it 
might be better to use the already defined term "Validity Period" and 
add the following sentence /"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."/

It would be even clearer if in 4.9.7 and 4.9.10 we added a statement 
about the value of the nextUpdate field as being "i.e. /nextUpdate ≤ 
thisUpdate + 365 * 86400s/" for the subCAs and "i.e. /nextUpdate ≤ 
thisUpdate + 10 * 86400s/" for Subscriber Certificates.

Thoughts?


Dimitris.

On 7/10/2021 8:34 μ.μ., Wayne Thayer via Validation wrote:
> Here is a draft of the ballot that we discussed on today's call to 
> clarify the maximum permitted validity interval of a CRL in the BRs. 
> I've gone ahead and reserved a ballot number and inserted Tim as the 
> proposer and Trev and Kati as endorsers.
> *
> *
> *BALLOT SC52: Specify Validity Interval of CRLs*
>
>
>     PURPOSE OF BALLOT
>
> Ballot SC31 included a clarification of the maximum allowed validity 
> interval for OCSP responses in section 4.9.10 of the Baseline 
> Requirements. A similar ambiguity has been identified in section 4.9.7 
> for the validity interval of CRLs. This ballot better specifies the 
> maximum validity interval for CRLs issues after 1-Feb-2022 by applying 
> the language from section 4.9.10 to CRLs.
>
> 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/main...wthayer:ballot-SC52 
> <https://github.com/cabforum/servercert/compare/main...wthayer:ballot-SC52> 
> (NOTE: THIS LINK NEEDS TO BE UPDATED TO REFERENCE SPECIFIC COMMITS IN 
> THE FINAL BALLOT)
>
>
>     MOTION ENDS
>
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
>
>
>       Discussion (7+ days)
>
> Start Time: TBD
> End Time: TBD
>
>
>       Vote for approval (7 days)
>
> Start Time: TBD
> End Time: TBD
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211013/b00fcdf9/attachment.html>


More information about the Validation mailing list