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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 20 March 2021 17:54 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 498F73A2747; Sat, 20 Mar 2021 10:54:29 -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 HdHTgC8yeZEy; Sat, 20 Mar 2021 10:54:27 -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 281B13A2745; Sat, 20 Mar 2021 10:54:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E2810389B5; Sat, 20 Mar 2021 14:00:07 -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 8e3q6Ua2BFvJ; Sat, 20 Mar 2021 14:00:06 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B3926389B4; Sat, 20 Mar 2021 14:00:06 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8C361240; Sat, 20 Mar 2021 13:54:24 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jacob Hoffman-Andrews <jsha@letsencrypt.org>, spasm@ietf.org, acme@ietf.org, anima@ietf.org
In-Reply-To: <CAN3x4QmmAiA+L9fqj8_or8z0o1Uu9VHb8RFua6x_BAF41Z2A2Q@mail.gmail.com>
References: <20210318130241.A6B44389A8@tuna.sandelman.ca> <22886.1616091336@localhost> <CAN3x4QmmAiA+L9fqj8_or8z0o1Uu9VHb8RFua6x_BAF41Z2A2Q@mail.gmail.com>
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: Sat, 20 Mar 2021 13:54:24 -0400
Message-ID: <2607.1616262864@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/8zI3yp3WtaRgKXzwmFtyL5xov_g>
Subject: Re: [Anima] [Acme] 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: Sat, 20 Mar 2021 17:54:29 -0000

Jacob Hoffman-Andrews <jsha@letsencrypt.org> wrote:
    > Roland Shoemaker sent a proposal a while back for ACME Renewal Info (ARI)
    > with the goal of solving both "impending revocation" and "expressing
    > suggested renewal times."
    > https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/. We
    > at Let's Encrypt hope to develop this idea further and implement it soon.

Ah, thank you for the reminder.
I was confused, because 20 Mar 2021 isn't here yet, but then I realized it
was 2020 :-)
I found the email via IMAP, and I see two replies.  One of them mine.
I didn't even remember thinking about this before.

Managing this through an OCSP infrastructure seems like it is probably the
right thing a Web Scale.

Within an Enterprise/Building/Residence, dealing with a (probably) private
CA, and with rather low energy networks... OCSP is a non-starter, I'd say.
In many cases, a session key (OSCORE) is derived from AKE and then kept for
months at a time.  No certificate operations are done at intervals frequent
enough for OCSP to be terribly useful.

{An example is a window smash sensor, that basically is primed "once",
and once the window is smased, it exhausts its battery.  Do we even care if
the certificate that was used for setup is expired?  Possibly not.  So maybe
this not a good example of a constrained device that cares}

So what I think I'd like is a signal that can be session layer multicast.
So it would be flood filled through unicast communications that happen to
already be occuring.   ("And they tell two friends, and so on, and so on...")
I think that a CRL fits within the constraints.

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