API for Certificate checking without date checks

[Ladd, Watson]

Consider roughtime, arriving Real Soon Now (tm) from the NTP WG

________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Jochen Bern <Jochen.Bern at binect.de>
Sent: Tuesday, March 5, 2024 5:27 AM
To: openssl-users at openssl.org
Subject: Re: API for Certificate checking without date checks

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 --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20240305/7758bd38/attachment.htm>