[Ntp] Antw: [EXT] Getting started using NTS ‑‑ clock accuracy vs certificates

>>> Hal Murray <halmurray@sonic.net> schrieb am 29.07.2022 um 20:11 in
Nachricht
<20220729181119.A49C928C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net>:
> Checking certificates requires that the clock be close enough.  How close is

> that?
> 
> Assume you have an embedded system without a battery backed clock.  Assume 
> it 
> has something like fake‑hwclock that stores the time in a file and restores

> it 
> on booting.  So the clock is within an hour of the last time the system was

> running.
>   https://manpages.debian.org/stretch/fake‑hwclock/fake‑hwclock.8.en.html 
> 
> What happens if the system sits on the shelf for a month?  The system will 
> try 
> to verify certificate chains with a clock that is a month out of date.

So maybe the person that takes the device from the shelf has to perform some
"initialization" that sets the time close to current.

> 
> Do certificate geeks consider that case?  When they setup a new certificate,

> 
> do they back‑date the starting time or just use "now"?  If not, then the max

> clock error is the time since the certificate was issued.
> 
> Has this issue come up in other contexts?
> 
> Is there a good description of the problem that I can refer to?
> 
> Should we consider things like coordinating certificate updates so that the

> update times are staggered?  Lets‑encrypt certificates are only good for 90

> days.  So there is a 1/3 chance one of their certificates will be too‑new if

> a 
> system has been sitting on the shelf for 30 days.  (Probably a bit more 
> since 
> the operator won't wait until the last minute to renew the certificate.)
> 
> ‑‑‑‑‑‑‑
> 
> There is also DNSSEC.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 