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

[Phillip Hallam-Baker <[e-mail]>]

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.