I think perhaps I'm doing a poor job at explaining the specific issue I encounter regularly, but if a system has been offline for a day, it will be askew by a day. Unless you're assuming a hardware clock that's on battery power is always available, and that the time/ntp daemon checks that and updates the clock fast enough.

My use case isn't unique, if you have an embedded device, I'm sure there are even more stringent limitations. Is there really that big of a difference if the notBefore is a day instead of an hour, or even a week? Perhaps when shortening notAfter, notBefore should be increased.

> Unless you're assuming a hardware clock that's on battery power is always available, and that the time/ntp daemon checks that and updates the clock fast enough.

Not "and", just "or". A hardware clock is assumed, but in absence of that it's the job of the OS to fix the clock before it breaks anything.

And an hour is already generous. Extending it to a day or a week gets weird and helps almost nobody.

The overwhelming majority of consumer laptops/desktops/etc today have a RTC so that yes, there's a battery keeping a RTC chip awake that keeps the clock reasonably correct after it's been powered off / hibernating / etc.

You're totally right, but how much is the very small minority?

What irks me slightly is that this is the type of thinking I typically see from companies like Google, where only 0.1% of users will be affected by a change, but 0.1% of a billion is 1 million people.

I'm not saying I disagree with you, perhaps I'm the only person who might be affected, in which case who cares. But LetsEncrypt is a critical service provider at this point, they shouldn't calculate impact like a commercial entity that can ignore people due to lack of revenue implications.

How unreasonable would I be if I expected TLS client clock precision to be part of the TLS spec, and such changes should require a version bump? That's probably extreme, but how can we ensure stability and reliability when these systems billions use change? Is the CA/B making decisions for everyone, even the minority? Do browser vendors care if some IoT device stops working?

We can ensure stability and reliability with RTCs and NTP. The minority here is systems with no RTC that try to perform TLS operations before NTP is operational. The fix is to move NTP earlier in the dependency tree. Or just wait a minute.

I don’t want the CAB to defer security wins for the 99% because of hardware and software trade offs the 1% made.

I'll trust you know more than I and concede on this then. I didn't consider the security benefits to be worth even a minor convenience to even a handful of people.