[Acme] Long-lived certificates, but frequently renewed certificates
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 18 March 2021 18:15 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FD03A310A; Thu, 18 Mar 2021 11:15:45 -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 KGfqcuIYlqxO; Thu, 18 Mar 2021 11:15:43 -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 26D113A3152; Thu, 18 Mar 2021 11:15:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 08531389A3; Thu, 18 Mar 2021 14:21:12 -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 G92JUGqqx-An; Thu, 18 Mar 2021 14:21:11 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 851B5389A1; Thu, 18 Mar 2021 14:21:11 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D6ED41B9; Thu, 18 Mar 2021 14:15:36 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: spasm@ietf.org, acme@ietf.org
CC: anima@ietf.org
In-Reply-To: <20210318130241.A6B44389A8@tuna.sandelman.ca>
References: <20210318130241.A6B44389A8@tuna.sandelman.ca>
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:15:36 -0400
Message-ID: <22886.1616091336@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Ka09Mv-PH2ENPrUFovpNnujthck>
Subject: [Acme] Long-lived certificates, but frequently renewed certificates
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2021 18:15:46 -0000
[resending with correct list name for spasm^Wlamps. I hate this] ANIMA is working on a more construction focused version of BRSKI, which you can read about in https://datatracker.ietf.org/doc/draft-ietf-anima-brski-async-enroll/, in which the last few meters of connectivity are by sneaker-net. (Literally: technicians walking up/down stairs into the basement of new construction with some commissioning device. Using object-security CMP rather than EST, and store-and-forward use case. Round trips are expensive until the network is up) The trend in building automation is that people are paranoid about downtime due to certificate expiry, and so long-lived certificates (multiple years to small number of decades) are deployed. In the case of new construction (a subdivision of houses), it might be a year before the building is occupied by the first owner. We were discussing the various transfers of ownership that we need to support. These include: 1) the building is sold 2) the building owner changes building management companies 3) the building management company changes technical maintenance companies 4) the building owner fires the building management company 5) the bank forecloses on the building owner, and forces a sale 6) the technical mainenance company is acquired by another company 7) the company providing the tools to the technical maintenance company (the "registrar") does a major product change, and/or is acquired by another company While (5) might be forced and require a "flash" rekeying, we think that all the rest of the transitions should be accomodated without downtime/flag days. If we could say that every device will check in with the Registrar frequently enough using EST, then we could push new trust anchors down and issue new certificates against the new trust anchors. So this argues for short-lived, STAR-type certificates. But, paranoia and concern about initial occupancy, and even long periods when there might be no occupant argues for longer-lived certificates. OTH, frequent renewal has the advantage that failures are caught much faster. As far as I know, the only signal for when to renew is notAfter. Generally, one should renew sometimes after the half-way point. (LetsEncrypt policy of 90 days, but discouraged to renew until 60 days) 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? I think that a smooth transition from one CA anchor to another can be accomplished by signing of the old CA by the new CA, and VV. I don't know how successful this has been in reality: I sense that it's a practice which is good in theory, but not in practice. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Acme] Long-lived certificates, but frequently re… Michael Richardson
- Re: [Acme] Long-lived certificates, but frequentl… John Gardiner Myers
- Re: [Acme] Long-lived certificates, but frequentl… Jacob Hoffman-Andrews
- Re: [Acme] [lamps] Long-lived certificates, but f… Michael Richardson
- Re: [Acme] Long-lived certificates, but frequentl… Michael Richardson
- Re: [Acme] Long-lived certificates, but frequentl… Phillip Hallam-Baker
- Re: [Acme] [lamps] Long-lived certificates, but f… John Gardiner Myers