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

Nico Williams <> Mon, 22 March 2021 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76A4B3A12A9; Mon, 22 Mar 2021 14:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pioq3qDIAzqb; Mon, 22 Mar 2021 14:28:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5F693A12A4; Mon, 22 Mar 2021 14:28:53 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 4A54D3225E6; Mon, 22 Mar 2021 21:28:53 +0000 (UTC)
Received: from (100-96-16-31.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 04B453218D7; Mon, 22 Mar 2021 21:28:51 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by (trex/6.1.1); Mon, 22 Mar 2021 21:28:53 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Average-Macabre: 40f143fd46063e79_1616448533133_641053768
X-MC-Loop-Signature: 1616448533133:780149083
X-MC-Ingress-Time: 1616448533133
Received: from (localhost []) by (Postfix) with ESMTP id AB1077F60A; Mon, 22 Mar 2021 14:28:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=gCtcJGyOgRMxhU 4B+UYup9reorU=; b=wkjgZHyoBGAqVhZ4D1YKeAPvKe5GyJ3Hg1ldf/7TNBueGF N8+pnjOchDXTKSYNkVc0+AfgUUg0+fyCzQYD+wglwvqQEdINfZFgV9zcfsP7r3jn UEmmg9E+9Bi9Z74b0HyVflKLg0IbLPlufj3k47XhoIipQY003oZEvRXLkthPo=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id F29997EFD9; Mon, 22 Mar 2021 14:28:45 -0700 (PDT)
Date: Mon, 22 Mar 2021 16:28:42 -0500
X-DH-BACKEND: pdx1-sub0-mail-a45
From: Nico Williams <>
To: Eliot Lear <>
Cc: Michael Richardson <>, Toerless Eckert <>, LAMPS <>,
Message-ID: <20210322212842.GS30153@localhost>
References: <> <20210318183001.GN30153@localhost> <2113.1616093888@localhost> <> <20210320203655.GR30153@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <>
Subject: Re: [Anima] [lamps] 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: Mon, 22 Mar 2021 21:28:59 -0000

On Sun, Mar 21, 2021 at 10:27:00AM +0100, Eliot Lear wrote:
> [Reducing]

[Whenever possible]

> > Can you elaborate on this?  Is the issue validation path construction in
> > complex PKIs?
> Mostly not.  There are two objects that have to be addressed:
> Device LDevID expiration and update.
> Trust Anchor roll.
> The Second case is generally easier, so long as the device is
> regularly in service; and it may even be easy when the device is out
> of service for extended periods (think years) so long as it is thought
> about in advance by both implementor and deployment.

End entities send a validation chain for their EE certs, but not the
root CA's cert, and anyways, RPs need to know trust anchors a priori.
Therefore rolling out new TAs is tricky.

TA rollover needs a device update protocol.  Which is a pain in large
part because it's completely unstandardized and anyways implies a
separate trust structure for update signing (e.g., a package signer

Maybe the chains should always have included the roots so that rollover
could have been handled via the old one signing the new one.  Or maybe
we need an extension like AuthorityInfoAccessSyntax (or maybe just use a
URI issuerAlternativeName?) to indicate rollover information for roots
that can be used by RPs to update trust anchors (again, with
old-signs-new or with a signature by some separate PKI as in the
packaging case).

(Speaking of uniformResourceIdentifier type issuerAltNames, what are
their semantics?  If RFC5280 covers that, I've missed it.)

> The LDevID change out is harder.  A device can have many trust
> anchors, but the LDevID change-out has to be handled a bit more
> carefully.
> [...]

Yes, devices can have considerations that an EST server may not be able
to know.

So I think we're talking about the server indicating a refreshAfter time
or a doNotRefreshBefore time rather than a refreshAt time.  An
informative "you can refresh after this $time" and maybe a normative "do
not even think of refreshing before this $time".

That said, a simple certificate refresh where no algorithms change, no
parameters change, no critical extensions are added, etc. -- where the
only real change is the validity period -- surely this is safe to
perform whenever the device can talk to the online CA.  One could argue
that making sure that the only change is the validity period (and maybe
the SPKI, but not its alg or params) is difficult to ensure.  Michael
tells me maybe the CA software gets upgraded and other changes sneak in
that one did not expect.