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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 23 March 2021 15:49 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 C4C873A12D0; Tue, 23 Mar 2021 08:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 AL8ibrfqJAFH; Tue, 23 Mar 2021 08:49:29 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D763A12D5; Tue, 23 Mar 2021 08:49:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 11683389CB; Tue, 23 Mar 2021 11:55:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wj1geH7qmvw9; Tue, 23 Mar 2021 11:55:17 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CC5C389C8; Tue, 23 Mar 2021 11:55:17 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DEB3560A; Tue, 23 Mar 2021 11:49:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Nico Williams <nico@cryptonector.com>, Eliot Lear <lear@cisco.com>, Toerless Eckert <tte@cs.fau.de>, LAMPS <spasm@ietf.org>, anima@ietf.org
In-Reply-To: <20210322212842.GS30153@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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 23 Mar 2021 11:49:23 -0400
Message-ID: <22432.1616514563@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/U_6cdX3RDtdAe6ag7BAFxddwoWU>
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 15:49:35 -0000

Nico Williams <nico@cryptonector.com> wrote:
    >> 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.

TLS discourages sending the root CA cert.
I prefer to send it for a number of reasons, and this is one of them.

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

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

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

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide