Subject: [Acme] Long-lived certificates, but frequently renewed certificates

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Mar 2021 14:15:36 -0400

[resending with correct list name for spasm^Wlamps. I hate this]

ANIMA is working on a more construction focused version of BRSKI, which you
can read about in https://datatracker.ietf.org/doc/draft-ietf-anima-brski-async-enroll/,
in which the last few meters of connectivity are by sneaker-net.
(Literally: technicians walking up/down stairs into the basement of new
construction with some commissioning device.  Using object-security CMP
rather than EST, and store-and-forward use case.  Round trips are expensive
until the network is up)

The trend in building automation is that people are paranoid about downtime
due to certificate expiry, and so long-lived certificates (multiple years to
small number of decades) are deployed.
In the case of new construction (a subdivision of houses), it might be a year
before the building is occupied by the first owner.

We were discussing the various transfers of ownership that we need to
support.  These include:
  1) the building is sold
  2) the building owner changes building management companies
  3) the building management company changes technical maintenance companies
  4) the building owner fires the building management company
  5) the bank forecloses on the building owner, and forces a sale
  6) the technical mainenance company is acquired by another company
  7) the company providing the tools to the technical maintenance company
     (the "registrar") does a major product change, and/or is acquired
     by another company

While (5) might be forced and require a "flash" rekeying, we think that all
the rest of the transitions should be accomodated without downtime/flag days.
If we could say that every device will check in with the Registrar frequently
enough using EST, then we could push new trust anchors down and issue new
certificates against the new trust anchors.
So this argues for short-lived, STAR-type certificates.
But, paranoia and concern about initial occupancy, and even long periods when
there might be no occupant argues for longer-lived certificates.
OTH, frequent renewal has the advantage that failures are caught much faster.

As far as I know, the only signal for when to renew is notAfter.
Generally, one should renew sometimes after the half-way point.
(LetsEncrypt policy of 90 days, but discouraged to renew until 60 days)

It seems that a CA ought to be able to express some other kind of renewal
period directly.   Is there any work in this area?

I think that a smooth transition from one CA anchor to another can be
accomplished by signing of the old CA by the new CA, and VV.  I don't know
how successful this has been in reality: I sense that it's a practice which
is good in theory, but not in practice.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 18 Mar 2021 11:45:32 -0700

> period directly.   Is there any work in this area?

I would frame this in terms of impending revocation. Consider the case, 
as has happened in the past, where a CA discovers that there is a 
problem with some or all of the previously issued certificates requiring 
the CA to revoke said certificates within a few days. How can the ACME 
client managing renewal learn from the CA of the need to renew prior to 
the revocation, so to avoid a service interruption?

I believe this problem is within the scope of  the ACME WG's charter, 
but would require someone with CA experience to propose an ACME extension.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 18 Mar 2021 17:25:18 -0700

Roland Shoemaker sent a proposal a while back for ACME Renewal Info (ARI)
with the goal of solving both "impending revocation" and "expressing
suggested renewal times."
https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/. We
at Let's Encrypt hope to develop this idea further and implement it soon.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 20 Mar 2021 13:39:17 -0400

> I would frame this in terms of impending revocation. Consider the case, as
    > has happened in the past, where a CA discovers that there is a problem with
    > some or all of the previously issued certificates requiring the CA to revoke
    > said certificates within a few days. How can the ACME client managing renewal
    > learn from the CA of the need to renew prior to the revocation, so to avoid a
    > service interruption?

Would this signal occur at the time of issuance, or are you thinking that it
would occur some time into the validity period?

    > I believe this problem is within the scope of  the ACME WG's charter, but
    > would require someone with CA experience to propose an ACME extension.

In the environments I are talking about, if ACME is involved, it is because
we have a Registrar managing the enrollment (and having access to do the
DNS-01 updates), as described in acme-integrations.

In some cases, the Registrar and the device might communicate using
   https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/
and so the Registrar can effectively (and asynchronously) push a new
certificate to devices.
In other cases, the Registrar is passive, and so we need to get the devices
to in effect, poll the Registrar frequently enough to be effective, but no so
frequently as to be annoying.  We do not have, in RFC7030 or est-coaps, any
kind of clear "go away for a week" message.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 20 Mar 2021 13:54:24 -0400

> at Let's Encrypt hope to develop this idea further and implement it soon.

Ah, thank you for the reminder.
I was confused, because 20 Mar 2021 isn't here yet, but then I realized it
was 2020 :-)
I found the email via IMAP, and I see two replies.  One of them mine.
I didn't even remember thinking about this before.

Managing this through an OCSP infrastructure seems like it is probably the
right thing a Web Scale.

Within an Enterprise/Building/Residence, dealing with a (probably) private
CA, and with rather low energy networks... OCSP is a non-starter, I'd say.
In many cases, a session key (OSCORE) is derived from AKE and then kept for
months at a time.  No certificate operations are done at intervals frequent
enough for OCSP to be terribly useful.

{An example is a window smash sensor, that basically is primed "once",
and once the window is smased, it exhausts its battery.  Do we even care if
the certificate that was used for setup is expired?  Possibly not.  So maybe
this not a good example of a constrained device that cares}

So what I think I'd like is a signal that can be session layer multicast.
So it would be flood filled through unicast communications that happen to
already be occuring.   ("And they tell two friends, and so on, and so on...")
I think that a CRL fits within the constraints.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 20 Mar 2021 14:35:14 -0400

I have two separate answers to these issues.

Answer 1 is to start from a clean sheet of paper and design a PKI that
addresses the needs of IoT devices directly.

Answer 2 is to apply some of the techniques developed for Answer 1 to the
legacy infrastructure.

The biggest single simplification in the Mesh is that certificates do not
have a predefined expiry time and revocation is not considered to be part
of authentication. Revocation is an authorization issue as far as I am
concerned.

To apply the same sort of principle to the WebPKI, I would have a system in
which every device has two certs: A device cert issued during manufacture
bound to a device key with a 30+ year expiry that is bound to some
manufacturer or industry association root and a daily cert issued by a CA
that chains to a root of trust in the browser.

The way I would issue that cert is for the CA to generate a new keypair
every day and send a certificate and private key SHARE to the device,
either directly or by posting an encrypted package to a Web site somewhere.

To make this scheme secure, we use one of the ECDH curves for the keys and
threshold cryptography.

Let the device key pair be {d, d.P} and the daily key shares from the CA be
{c_0, c_0.P}, {c_1, c_1.P}, ...

The CA knows d.P and c_n.P and can calculate x_n.P =  d.P + c_n.P = (d +
c_n).P

The device knows d and is given c_n and so can calculate x_n.

This approach is very fluid and could be integrated into an ACME framework
with little fuss. Instead of validating each cert request, the CA makes a
periodic check. We would also have to tweak TRANS/CT so that instead of
entering every daily cert issued, the CA would only need to log a template
cert on d.P and refresh it when the cert comes up for revalidation. And we
would probably want an extension or two to let relying parties know what is
going on.

That is what I would be proposing at the moment if a CA was paying me to
maintain the WebPKI. Since they are not, I will leave the reification of
this concept in ASN.1 to others.

That approach has real advantages for the existing WebPKI. It could be
slotted in pretty cleanly and would solve a lot of problems. There is no
need for revocation in this scheme. Instead of OCSP stapling, the server
simply downloads the new key share and cert each day.

It is not a good fit for the IoT world because it relies on the systems
always being connected. That approach doesn't work for me living in the
Boston Metro region sitting on a 1Gbs Verizon FiOS Internet pipe. I am
pretty certain it won't work at all for anyone who decides Starlink is the
opportunity for them to realize their lifelong dream of living offgrid. One
day the generator will go out and the Starlink with it. And the owner will
return from a visit to civilization to find that they can't get into the
house because all the certs have expired.

DNS is a really poor match for IoT as well. Very few people own a DNS name
and they are ludicrously expensive and unaffordable as far as at least a
quarter of the world's population is concerned.

The answer for IoT is to build out the PKI and the name space at the same
time. That allows name assignments to be permanent which removes the need
to revalidate cert holders. I have a draft on this proposal which I am
circulating privately for now. A public version should be up in a few weeks
time.

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 23 Mar 2021 10:17:05 -0700

> would occur some time into the validity period?

It would have to occur some time into the validity period as the time of 
revocation would not be known at the time of issuance.

Roland Shoemaker's ACME proposal resonates with my thinking, with one 
exception: since an ACME client typically manages a stable of desired 
certificates and the lack of any recent or impending revocations is the 
common case, it might make sense for the client to query "are there any 
unexpired certificates issued through this ACME account that are being 
revoked soon or recently?"