[Anima] Long-lived certificates, but frequently renewed certificates

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 18 March 2021 12:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1E0733A2AFA; Thu, 18 Mar 2021 05:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EJOdRVBQzdLw; Thu, 18 Mar 2021 05:57:07 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3D53A144F; Thu, 18 Mar 2021 05:57:07 -0700 (PDT)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id 12148389A6; Thu, 18 Mar 2021 09:02:39 -0400 (EDT)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id KhyrTyuZhYGV; Thu, 18 Mar 2021 09:02:38 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id 776AC3899E; Thu, 18 Mar 2021 09:02:38 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9F9941B9; Thu, 18 Mar 2021 08:57:04 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: lamps@ietf.org, acme@ietf.org
cc: anima@ietf.org
X-Attribution: mcr
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 08:57:04 -0400
Message-ID: <4360.1616072224@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/dztEJ8217jbV-pQBWiimM49nk1w>
Subject: [Anima] 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 12:57:10 -0000

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