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

Nico Williams <nico@cryptonector.com> Tue, 23 March 2021 16:06 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D802E3A135E; Tue, 23 Mar 2021 09:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB5qToDQ5w3O; Tue, 23 Mar 2021 09:06:37 -0700 (PDT)
Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168493A0AC5; Tue, 23 Mar 2021 09:06:36 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 80CB836238F; Tue, 23 Mar 2021 16:06:32 +0000 (UTC)
Received: from pdx1-sub0-mail-a45.g.dreamhost.com (100-96-133-36.trex.outbound.svc.cluster.local [100.96.133.36]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1A93F3623A2; Tue, 23 Mar 2021 16:06:31 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a45.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.133.36 (trex/6.1.1); Tue, 23 Mar 2021 16:06:32 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Lyrical-Whispering: 1651c3dd471543ef_1616515592279_2529862758
X-MC-Loop-Signature: 1616515592279:1461205021
X-MC-Ingress-Time: 1616515592279
Received: from pdx1-sub0-mail-a45.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTP id 8C7037F22C; Tue, 23 Mar 2021 09:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=WZNr/9PFcmyzY/ FqN+H2igvTWLQ=; b=a9siv1Dzmva7FfpGMAOxI3QfNuUXdtk+RZ7FR7FVAz/Tog 2gFukKql1vsmBcxKW+T7esVLbRP+fSst/C8YBPCKYDyEphbxcAKQfbGBeTjJlgmj CJ7zvSTSt/bZiW/TpDLO5hvqkBsgJBzUJK5gsUdWQVcic6Cy2xJE9OGmWJPtM=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a45.g.dreamhost.com (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 <nico@cryptonector.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Eliot Lear <lear@cisco.com>, Toerless Eckert <tte@cs.fau.de>, LAMPS <spasm@ietf.org>, anima@ietf.org
Message-ID: <20210323160623.GU30153@localhost>
References: <20210318165455.GM8957@faui48f.informatik.uni-erlangen.de> <20210318183001.GN30153@localhost> <2113.1616093888@localhost> <718D80AD-8F12-4AA0-9D2A-2D8806B487C2@cisco.com> <20210320203655.GR30153@localhost> <B38811EA-335C-4BEC-800C-B88DDA44DE74@cisco.com> <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: <https://mailarchive.ietf.org/arch/msg/anima/W_wgpssL1klP9lKqY1bKTefBzGU>
Subject: Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=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 <nico@cryptonector.com> 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...
this.

>     > 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.

Nico
--