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

Nico Williams <> Tue, 23 March 2021 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D802E3A135E; Tue, 23 Mar 2021 09:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iB5qToDQ5w3O; Tue, 23 Mar 2021 09:06:37 -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 168493A0AC5; Tue, 23 Mar 2021 09:06:36 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 80CB836238F; Tue, 23 Mar 2021 16:06:32 +0000 (UTC)
Received: from (100-96-133-36.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 1A93F3623A2; Tue, 23 Mar 2021 16:06:31 +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); Tue, 23 Mar 2021 16:06:32 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Lyrical-Whispering: 1651c3dd471543ef_1616515592279_2529862758
X-MC-Loop-Signature: 1616515592279:1461205021
X-MC-Ingress-Time: 1616515592279
Received: from (localhost []) by (Postfix) with ESMTP id 8C7037F22C; Tue, 23 Mar 2021 09:06:30 -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=WZNr/9PFcmyzY/ FqN+H2igvTWLQ=; b=a9siv1Dzmva7FfpGMAOxI3QfNuUXdtk+RZ7FR7FVAz/Tog 2gFukKql1vsmBcxKW+T7esVLbRP+fSst/C8YBPCKYDyEphbxcAKQfbGBeTjJlgmj CJ7zvSTSt/bZiW/TpDLO5hvqkBsgJBzUJK5gsUdWQVcic6Cy2xJE9OGmWJPtM=
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 D9EA77EFD0; Tue, 23 Mar 2021 09:06:26 -0700 (PDT)
Date: Tue, 23 Mar 2021 11:06:24 -0500
X-DH-BACKEND: pdx1-sub0-mail-a45
From: Nico Williams <>
To: Michael Richardson <>
Cc: Eliot Lear <>, Toerless Eckert <>, LAMPS <>,
Message-ID: <20210323160623.GU30153@localhost>
References: <> <20210318183001.GN30153@localhost> <2113.1616093888@localhost> <> <20210320203655.GR30153@localhost> <> <20210322212842.GS30153@localhost> <22432.1616514563@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <22432.1616514563@localhost>
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: Tue, 23 Mar 2021 16:06:42 -0000

On Tue, Mar 23, 2021 at 11:49:23AM -0400, Michael Richardson wrote:
> Nico Williams <> wrote:
>     > 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.
> TLS discourages sending the root CA cert.
> I prefer to send it for a number of reasons, and this is one of them.

You can only send them when they are available as certificates (which
TAs are not required to be).  But +1.

>     > 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
>     > PKI).
> EST includes includes updating the CA trust anchors as a protocol item.
> We don't have to have to replace the firmware.

Yeah, I know, but in the enterprise we still use packages, though not
necessarily packages with software, just configuration.

>     > 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".
> Yes, that's exactly what I'm after.
> We can, as you suggest, do this as an HTTP header in EST.
> It could also go into some new certificate extension, although it's rather
> more meta data, and it isn't clear it should get shared with peers.

Well, I suppose there one more way.  I asked about the semantics of URI
issuerAltNames, and maybe the right answer is that /.well-known for the
base URI should let you discover... lots of things, like EST, and...

>     > Michael tells me maybe the CA software gets upgraded and other
>     > changes sneak in that one did not expect.
> So, I was thinking of a hypothetical that could result in a surprising change
> in the field during what should be a non-event renewal.

I agree it's possible, likely even.