Bugzilla

(In reply to Grzegorz Prusak from comment #5)
> Does RFC or BR requires a browser to round down the measured current time to full seconds, before comparing them against the validity period?

Here's the short answer version (I have a longer answer, but like... woah, wall of text)

Since X.509/88, the `notBefore` is the _first_ date that the certificate is **valid**, and the `notAfter` is the _last_ date that the certificate is **valid**. Specifically, from Section 7.2

  > TA indicates the period of validity of the certificate, and consists of two dates, the first and last on which the certificate is valid. Since TA is assumed to be changed in periods not less than 24 hours, it is expected that systems would use Coordinated Universal Time as a reference time base

The question I understand you to be then asking is what happens if the `notAfter` is expressed in seconds, but the system measures time in fractional seconds. That is, if `notAfter` (for HHMMSS) is `000000`, and the system determines the time is `000000.123`, do you:

  1. Truncate the system time to the same precision as `UTCTime`/`GeneralizedTime` (e.g. `000000.123` -> `000000`)
  2. Extend the `notAfter` to the same precision as the system time (e.g.  `000000` -> `000000.123`)
  3. (Bonus) Round the system time **up** (i.e. `ceil()`) to the same precision as `UTCTime`, treating fractional seconds as a whole second (`000000.123` -> `000001`)

The answer here is (historically) 1. The validity period of `000000` represents all values from `000000.000` to `000000.999`, which is clearer when you examine the `notBefore`. The same logic applies to the `notAfter` - representing all fractional values within that range, and it is not expired until `000001.000`.

Comment #6 may be cheeky, but this is then the question of "Is 0.999... equal to 1", which like many great things, as [a whole Wikipedia page answering that question](https://en.wikipedia.org/wiki/0.999...).

I realize that folks are no doubt interested in this, given the implications to (effectively) 100% of Let's Encrypt issued certificates, and potentially other CAs simply not-yet-detected. Comment #1 captures that this has come up before and been answered, while Comment #4 accurately captures that there are tradeoffs and implications here for the ecosystem. Ultimately, incidents like this are up to the CA to demonstrate how they balance these equities and expectations, and the processes to improve and prevent things (which Comment #8 will further expand on)

(In reply to Grzegorz Prusak from comment #5)
> Does RFC or BR requires a browser to round down the measured current time to full seconds, before comparing them against the validity period?

Here's the short answer version (I have a longer answer, but like... woah, wall of text)

Since X.509/88, the `notBefore` is the _first_ date that the certificate is **valid**, and the `notAfter` is the _last_ date that the certificate is **valid**. Specifically, from Section 7.2

  > TA indicates the period of validity of the certificate, and consists of two dates, the first and last on which the certificate is valid. Since TA is assumed to be changed in periods not less than 24 hours, it is expected that systems would use Coordinated Universal Time as a reference time base

The question I understand you to be then asking is what happens if the `notAfter` is expressed in seconds, but the system measures time in fractional seconds. That is, if `notAfter` (for HHMMSS) is `000000`, and the system determines the time is `000000.123`, do you:

  1. Truncate the system time to the same precision as `UTCTime`/`GeneralizedTime` (e.g. `000000.123` -> `000000`)
  2. Extend the `notAfter` to the same precision as the system time (e.g.  `000000` -> `000000.000`)
  3. (Bonus) Round the system time **up** (i.e. `ceil()`) to the same precision as `UTCTime`, treating fractional seconds as a whole second (`000000.123` -> `000001`)

The answer here is (historically) 1. The validity period of `000000` represents all values from `000000.000` to `000000.999`, which is clearer when you examine the `notBefore`. The same logic applies to the `notAfter` - representing all fractional values within that range, and it is not expired until `000001.000`.

Comment #6 may be cheeky, but this is then the question of "Is 0.999... equal to 1", which like many great things, as [a whole Wikipedia page answering that question](https://en.wikipedia.org/wiki/0.999...).

I realize that folks are no doubt interested in this, given the implications to (effectively) 100% of Let's Encrypt issued certificates, and potentially other CAs simply not-yet-detected. Comment #1 captures that this has come up before and been answered, while Comment #4 accurately captures that there are tradeoffs and implications here for the ecosystem. Ultimately, incidents like this are up to the CA to demonstrate how they balance these equities and expectations, and the processes to improve and prevent things (which Comment #8 will further expand on)