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