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

Phillip Hallam-Baker <> Sat, 20 March 2021 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61C623A281D; Sat, 20 Mar 2021 11:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pUTE513FR5vq; Sat, 20 Mar 2021 11:35:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 878B13A281C; Sat, 20 Mar 2021 11:35:26 -0700 (PDT)
Received: by with SMTP id 8so1898229ybc.13; Sat, 20 Mar 2021 11:35:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jcu/OEvs0b60K6WjcisfVbcf5nf+wgHhO4x3XDeu1DA=; b=UhP3hLzCL2jO90P2SEKTdugrWPVNVlXjqEnAMgyxa933JrRMfGWnsThnibAPrcZed0 4GL9UR/lPAdk09WtcnjsPwUGlYuR8kB1pKu3qadEn7SMkIyMzHbPeFPp4J5DBilrYTx0 ENZVeJvWguBIhujw5T3ccI8Leyay9XLsMFcd+Yhxya+evl79/wviYNo25AzCUpAMzw8C QetWgYPIHAp6/TvFxnOzMBQ9M3zt5yrl3wc/kDQkKSsVEzwA+OG9K6J1JzzlHQyCaCoK HV5JtD6mmW28gFbcwD6MGwlMTgfaTFs7pSYMu8xkjAgPYKjrApQDB9mteLPu3I3ZsHzn /Dcg==
X-Gm-Message-State: AOAM532dC4RbO/2CSnsMjX3dmCqzGAIlOaWJUXg46wsMpwVYXnQ7HY0N Rp/hB43dTqjzJVHVeILe6JlpLzkgMrymFNJmIkYmf/kqaAs7mQ==
X-Google-Smtp-Source: ABdhPJwUYEZyUK1SywjC5WFWJKL1mubKdPnXSCZZ2iZVMWjmBQU4+v7RUkWzMjAA6j4Dv49dkhynUNinBeTAd6IzlHA=
X-Received: by 2002:a25:50d8:: with SMTP id e207mr14028669ybb.56.1616265325664; Sat, 20 Mar 2021 11:35:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <22886.1616091336@localhost>
In-Reply-To: <22886.1616091336@localhost>
From: Phillip Hallam-Baker <>
Date: Sat, 20 Mar 2021 14:35:14 -0400
Message-ID: <>
To: Michael Richardson <>
Cc: SPASM <>,,
Content-Type: multipart/alternative; boundary="000000000000995e8e05bdfc18b6"
Archived-At: <>
Subject: Re: [Anima] [Acme] Long-lived certificates, but frequently renewed certificates
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Mar 2021 18:35:29 -0000

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

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 +

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