Ballot SC-XX: Measure all hours and days to the second #470
Conversation
In light of https://bugzilla.mozilla.org/show_bug.cgi?id=1865080, this ballot ensures that all readers of the BRs understand that time periods measured in days (such as validation document reuse periods, random value usage periods, and revocation timelines) are measured precisely, not in calendar days. Notes: - This ballot bears some similarity to Ballot SC-52, which never came to a vote. - This ballot does not strictly define a "month", allowing infrequent tasks to continue to be executed on the same numeric day of each month, regardless of the number of days in that month.
Add a sentence modeled after Clint's statement that relying parties interpret periods of time to be their minimum value. Scope the existing high-precision sentence to just validity periods and validity intervals.
| @@ -490,6 +490,8 @@ The script outputs: | |||
|
|
|||
| **Validation Specialist**: Someone who performs the information verification duties specified by these Requirements. | |||
|
|
|||
| **Validity Interval**: For CRLs and OCSP Responses, the period of time from thisUpdate through nextUpdate, inclusive. | |||
There was a problem hiding this comment.
In order to avoid confusion, perhaps we could rename the "Validity Period" to "Certificate Validity Period" since it seems to apply only to Certificates, and then introduce "Validity Interval" that focuses on CRL and OCSP Responses.
There was a problem hiding this comment.
Hmm, interesting idea. I kinda like it, but I also don't want to rename "Validity Period", because that defined term (and its definition) is taken directly from RFC 5280.
There was a problem hiding this comment.
We could just add the word "Certificate" in front of it, which is already the subject of the term, so in essence you are not changing the definition :)
In any case, I don't have any strong feelings about this.
| @@ -595,6 +597,10 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S | |||
|
|
|||
| By convention, this document omits time and timezones when listing effective requirements such as dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC. | |||
|
|
|||
| All statements of time periods (for example, "5 days") SHALL be taken to mean exactly that period of time, and not a fractional period more (e.g. not "5 and a half days"). | |||
There was a problem hiding this comment.
I'm afraid this will extend beyond the definition of "days" and "hours" within the BRs, EVGs and NSRs, and cause some confusion. For example:
- NSR 1l: "within six (6) months"
- NSR 2j: "every three (3) months"
- NSR 2g: "two years"
- NSR 4c: "every three (3) months"
- BR 4.9.7: "every twelve (12) months"
- BR 5.4.3: "two (2) years"
- BR 5.5.2: "two (2) years"
- BR 8.1: "one year"
- BR 8.6: "three months"
- EV 11.2.2: "six months"
- EV 14.1.1: "three months"
I'm not sure how to expand this example into the time periods of the cases above. If we want more precision on any time period that is not stated as "X number of days" or "X hours" in the documents, we probably need to update those time periods and call out specific days.
For example, NSR 3e states "once every 31 days", which covers months that have 30 days or February that has 28 or 29 days. Similarly, we could change 3 months to 92 days and so on.
There was a problem hiding this comment.
On the whole, I agree. I would love for all time periods throughout these documents to be measured in days. But the last time I advocated for that, I received pushback from folks who think that having different granularities is useful.
I think this will resolve more confusion than it will cause.
Right now, someone could read EV 14.1.1 "three months" and interpret that as over 100 days: "We conducted the verification on Jan 1, it's now April 15, and April is three months after January". In contrast, I think it would be very very difficult for someone to interpret "three months" as (say) 28*3=84 days, since there is no point in the calendar in which there are three 28-day months.
My original plan here was to apply this only to "hours" and "days", as noted by the draft title. But during the validation call, others expressed that they'd prefer that we treat all periods of time equally, and not clarify hours/days differently from months/years. I'm okay doing it either way, but the community will have to come to consensus.
|
Oh, please no.
I don’t want to have to deal with all the “fun” that will ensue if CABF defines “Certificate Validity Period” to be something other than the “Validity Period” from RFC 5280. Terminology is confusing enough without unnecessary complications like that.
-Tim
From: Dimitris Zacharopoulos ***@***.***>
Sent: Tuesday, January 16, 2024 1:06 PM
To: cabforum/servercert ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [cabforum/servercert] Ballot SC-XX: Measure all hours and days to the second (PR #470)
@dzacharo commented on this pull request.
_____
In docs/BR.md <#470 (comment)> :
@@ -490,6 +490,8 @@ The script outputs:
**Validation Specialist**: Someone who performs the information verification duties specified by these Requirements.
+**Validity Interval**: For CRLs and OCSP Responses, the period of time from thisUpdate through nextUpdate, inclusive.
We could just add the word "Certificate" in front of it, which is already the subject of the term, so in essence you are not changing the definition :)
In any case, I don't have any strong feelings about this.
—
Reply to this email directly, view it on GitHub <#470 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIFREHHOO6JIQTRQVCYQCF3YO26RXAVCNFSM6AAAAABA6XX6NGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQMRUGQ4DONBRGU> .
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
In light of https://bugzilla.mozilla.org/show_bug.cgi?id=1865080, this ballot ensures that all readers of the BRs understand that time periods measured in days (such as validation document reuse periods, random value usage periods, and revocation timelines) are measured precisely, not in calendar days.
Notes: