Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 18 March 2021 18:58 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 F315D3A31D9; Thu, 18 Mar 2021 11:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 pgFJtqDjCD1o; Thu, 18 Mar 2021 11:58:10 -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 C5AB63A31DC; Thu, 18 Mar 2021 11:58:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CB31C389B2; Thu, 18 Mar 2021 15:03:43 -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 La3uYtbCM_g6; Thu, 18 Mar 2021 15:03:43 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C865389B1; Thu, 18 Mar 2021 15:03:43 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 835171B9; Thu, 18 Mar 2021 14:58:08 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Nico Williams <nico@cryptonector.com>, Toerless Eckert <tte@cs.fau.de>, spasm@ietf.org
CC: anima@ietf.org, netconf@ietf.org
In-Reply-To: <20210318183001.GN30153@localhost>
References: <20210318165455.GM8957@faui48f.informatik.uni-erlangen.de> <20210318183001.GN30153@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: Thu, 18 Mar 2021 14:58:08 -0400
Message-ID: <2113.1616093888@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/XaWNoMsSwR4_-wieOVFtULtM-6c>
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: Thu, 18 Mar 2021 18:58:12 -0000
Nico Williams <nico@cryptonector.com> wrote: > On Thu, Mar 18, 2021 at 05:54:55PM +0100, Toerless Eckert wrote: >> On Thu, Mar 18, 2021 at 08:57:04AM -0400, Michael Richardson wrote: >> > It seems that a CA ought to be able to express some other kind of renewal >> > period directly. Is there any work in this area? > Well, it's a simple certificate extension to do that. But do RPs need > to see it? It seems like the enrolment protocol should tell the holder > when to come back. Still, it's simplest to stick it in the certificate > as an extension. No idea if there's any work going on around that. Yes, I agree, the RP doesn't need to know. It could well be state somewhere during the enrollment protocol. A pity that EST (and I think SCEP, but I haven't read it all), just returns the resulting certificate, and not something more useful, like a JSON dict that includes the certificate. RFC7030 has a 202, Retry-After, which could be used to tell the holder to go away and come back later, but the intended use is not to say not now, but rather, "I'm working on it". If the whole thing was more RESTful, then holders could be told to GET their certificate from some place, and we could use ETag, and Expiry headers to tell the holder that it hasn't changed, and isn't expected to change for awhile, so piss off and come back then. In the full ACP situation, then we might expect holders to have active RESTCONF management, and then we can renew certificates in a push scenario using draft-ietf-netconf-sztp-csr-01, which I note is now past WGLC. > A related idea is that an RP can want certificates to be "fresh" enough > regardless of when their notAfters are, and again, there's no signaling > that via the supplicant's certificate unless somehow the issuer is > expected to know a policy all RPs want. I'm much less concerned about the RP here. The reason to issue long lifetime certificates is that things don't break just because some less critical infrastructure is not alive, or not reachable. Our reference example/use case in brski-async-enroll is communication between thermostats and furnaces in a (newly built) residence. The furnace needs to heat keep the home above zero even when the house is not occupied, and possibly has not yet been occupied. Maybe abuse of the certificate renewal process is the wrong way to accomplish transfers of ownership. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Anima] Long-lived certificates, but frequently r… Michael Richardson
- Re: [Anima] [Acme] Long-lived certificates, but f… John Gardiner Myers
- Re: [Anima] [lamps] Long-lived certificates, but … Michael Richardson
- Re: [Anima] [lamps] Long-lived certificates, but … Nico Williams
- Re: [Anima] [lamps] Long-lived certificates, but … Eliot Lear
- Re: [Anima] [Acme] Long-lived certificates, but f… Jacob Hoffman-Andrews
- Re: [Anima] [lamps] Long-lived certificates, but … Michael Richardson
- Re: [Anima] [lamps] [Acme] Long-lived certificate… Michael Richardson
- Re: [Anima] [lamps] Long-lived certificates, but … Tomas Gustavsson
- Re: [Anima] [Acme] Long-lived certificates, but f… Michael Richardson
- Re: [Anima] [lamps] Long-lived certificates, but … Michael Richardson
- Re: [Anima] [Acme] Long-lived certificates, but f… Phillip Hallam-Baker
- Re: [Anima] [lamps] Long-lived certificates, but … Nico Williams
- Re: [Anima] [lamps] Long-lived certificates, but … Eliot Lear
- Re: [Anima] [lamps] Long-lived certificates, but … Eliot Lear
- Re: [Anima] [lamps] Long-lived certificates, but … Michael Richardson
- Re: [Anima] [lamps] Long-lived certificates, but … Nico Williams
- Re: [Anima] [lamps] Long-lived certificates, but … Eliot Lear
- Re: [Anima] [lamps] Long-lived certificates, but … Russ Housley
- Re: [Anima] [lamps] Long-lived certificates, but … Nico Williams
- Re: [Anima] [lamps] Long-lived certificates, but … Michael Richardson
- Re: [Anima] [lamps] Long-lived certificates, but … Nico Williams
- Re: [Anima] [lamps] [Acme] Long-lived certificate… John Gardiner Myers
- Re: [Anima] [lamps] Long-lived certificates, but … Nico Williams