Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ballot SC-XX: Measure all hours and days to the second #470

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Ballot SC-XX: Measure all hours and days to the second #470

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
c3e928e
Ballot SC-XX: Measure all hours and days to the second
aarongable Dec 21, 2023
510e130
Clearer use of "shall"
aarongable Dec 21, 2023
a2e3c01
Changes based on discussion in ServerCert WG meeting
aarongable Jan 4, 2024
988c789
Simplify phrasing
aarongable Jan 8, 2024
c6aaa77
Rephrase note
aarongable Jan 16, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
20 changes: 12 additions & 8 deletions docs/BR.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -460,7 +460,7 @@ The script outputs:

**Root Certificate**: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.

**Short-lived Subscriber Certificate**: For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds).
**Short-lived Subscriber Certificate**: For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days. For Certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days.

**Sovereign State**: A state or country that administers its own government, and is not dependent upon, or subject to, another power.

Expand Down Expand Up @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


**Validity Period**: From RFC 5280 (<http://tools.ietf.org/html/rfc5280>): "The period of time from notBefore through notAfter, inclusive."

**WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website.
Expand Down Expand Up @@ -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").
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


For the purpose of computing Certificate Validity Periods and CRL and OCSP Validity Intervals, one hour is defined to be exactly 3,600 seconds, and one day is defined to be exactly 86,400 seconds, 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 an additional day.

# 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.
Expand Down Expand Up @@ -1332,14 +1338,12 @@ The following SHALL apply for communicating the status of Certificates which inc

OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954.

The validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. 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.

For the status of Subscriber Certificates:

1. OCSP responses MUST have a validity interval greater than or equal to eight hours;
2. OCSP responses MUST have a validity interval less than or equal to ten days;
3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.
4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.
1. OCSP responses MUST have a Validity Interval greater than or equal to eight hours;
2. OCSP responses MUST have a Validity Interval less than or equal to ten days;
3. For OCSP responses with Validity Intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the Validity Interval before the nextUpdate.
4. For OCSP responses with Validity Intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.

For the status of Subordinate CA Certificates:

Expand Down Expand Up @@ -1772,7 +1776,7 @@ The CA SHALL protect its Private Key in a system or device that has been validat

Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.

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.
Due to the precision with which the Certificate Validity Periods is measured, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, to prevent off-by-one-second errors.

## 6.4 Activation data

Expand Down