API for Certificate checking without date checks

[Jochen Bern]

On 05.03.24 13:00, openssl-users-request at openssl.org digested:
> Date: Mon, 04 Mar 2024 22:22:36 -0800
> From: Hal Murray <halmurray+openssl at sonic.net>
> 
> Context is the chicken and egg problem of using TLS before a system knows the
> time.
> 
> I work on NTP software.  NTP uses NTS (Network Time Security) which uses TLS
> to make sure it is talking to the right servers.
> 
> I'm trying to figure out how to get started on a system that doesn't know the
> time yet.  (Many low cost systems like the Raspberry Pi don't have a battery
> backed clock.)

Someone please correct me if I'm getting something wrong, but my memory 
of this topic's history is as follows:

1. NTP implements "v3" crypto (symmetric keys), which works OK to this 
day *if* you can handle the roll-out of (<64k different) shared keys.

2. NTP releases "v4" crypto (autokey? Not sure anymore), which gets 
broken on short notice.

3. NTP releases "v5" crypto (I remember a crypto scheme "inspired by 
cable TV encryption systems" promising to have clients set themselves up 
automagically being one of its operation modes, never saw a HowTo that'd 
have permitted me to actually set up such a beast), which also gets 
broken a while later.

4. NTP announces that it'll wait and adopt/adapt the crypto standard now 
being developed for PTP (rather than making another attempt of its own), 
presumably getting the chicken and the egg slain for good.

5. PTP, *meant* to be communicating between switch port and server NIC 
(can you say "physical security"?), drags its feet on the crypto topic.

6. NTP adopts NTS, which uses TLS, and thus X.509 certificates with a 
validity period ... and doesn't address the well-known chicken-and-egg 
problem at all.

... all this to say that truly solving this problem is *very* hard, if 
not theoretically impossible. For practical purposes, I guess that 
shipping installation images / devices / ... with a rather *short*-lived 
CA cert (to bootstrap stuff, not only NTS but also an update mechanism 
having the CA cert replaced frequently) and hoping that No Key Material 
Will Ever Get Leaked™ (and thoroughly wiped from your servers at its end 
of validity) is about the best you can do.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20240305/9d957f7e/attachment-0001.p7s>