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

Eliot Lear <lear@cisco.com> Sun, 21 March 2021 09:27 UTC

Return-Path: <lear@cisco.com>
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 62CF83A1A25; Sun, 21 Mar 2021 02:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.698
X-Spam-Level:
X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 W9ZQK2SsJtXL; Sun, 21 Mar 2021 02:27:07 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6203A1A23; Sun, 21 Mar 2021 02:27:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6714; q=dns/txt; s=iport; t=1616318827; x=1617528427; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=+dPNK4TT4z+yqhD9zSX4HayNes1P4KK4ZCmb6CTBeNM=; b=eU6yoBzkRiIYUJwf9pUBAYSDp8t1T9ftu9AtAocljz85Xt9zBMfHggYb 3u0O0odSImZNHYV6pBtvKpN0S2n2IWqAZMn0gRX7ZvcHLwXRNnKOyxFnf fpKMNvQ8FZcBXtKZl3s0XzXdEC15gXsxx42AMEahUfrtRCZEycRztIPfk 0=;
X-Files: signature.asc : 488
X-IPAS-Result: =?us-ascii?q?A0AwAAAaEFdgjBbLJq1aGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAYF/AwEBAQsBg3YBJxIxhEKJBIg+A5Q+iB8EBwEBAQoDAQE0BAEBhFACg?= =?us-ascii?q?XwmNwYOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAYZHhkQBAQEDASNWBQsLG?= =?us-ascii?q?CoCAlcGE4JwAYF8aiGrI3eBMoVYhGgQgTkBgVKFKgGGRUKCC4E4HIJZPoN9g?= =?us-ascii?q?1k1gisEgkAGgVtbCj8ZFgyRNwqMVZxygxCDOYFBl1wDH4NEkEeQL5cMm3ZwA?= =?us-ascii?q?YN7AgQGBQIWgWoigVszGggbFWUBgj4+EhkNjjgdjhNAAy84AgYBCQEBAwmNE?= =?us-ascii?q?i2CFgEB?=
IronPort-HdrOrdr: A9a23:dwPn3aA5Z1moSaXlHeku55DYdL4zR+YMi2QD/UoZc203TuWzkc eykPMHkSLlkTp5Yh0dsP2JJaXoexLh3LFv5415B92fdSng/FClNYRzqbblqgeBJwTb+vRG3a ltN4hyYeecMXFfjcL3pDa1CMwhxt7vys+VrNzTxXtsUg1mApsIh2xEIz2WHUFsSA5NCYBRLu v42uN8uzGidX4LB/7UOlA5WYH41r/2vaOjRRYHAhI9gTP+6Q+A2frdDwWS2AsYXndpx7ovmF K19TDR1+GEr+yxzAPa2ivoy6lu3PHlytdFGaW3+68oFgk=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,266,1610409600"; d="asc'?scan'208,217";a="34301981"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Mar 2021 09:27:02 +0000
Received: from [10.61.144.61] ([10.61.144.61]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 12L9R18k013633 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 Mar 2021 09:27:01 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <B38811EA-335C-4BEC-800C-B88DDA44DE74@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4477FF27-D63E-4D45-864C-9EA48AF96472"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Sun, 21 Mar 2021 10:27:00 +0100
In-Reply-To: <20210320203655.GR30153@localhost>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Toerless Eckert <tte@cs.fau.de>, LAMPS <spasm@ietf.org>, anima@ietf.org
To: Nico Williams <nico@cryptonector.com>
References: <20210318165455.GM8957@faui48f.informatik.uni-erlangen.de> <20210318183001.GN30153@localhost> <2113.1616093888@localhost> <718D80AD-8F12-4AA0-9D2A-2D8806B487C2@cisco.com> <20210320203655.GR30153@localhost>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Outbound-SMTP-Client: 10.61.144.61, [10.61.144.61]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/f3D5jt70Z8iX30GQ8og_sXtmypk>
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: Sun, 21 Mar 2021 09:27:12 -0000

[Reducing]

Hi Nico,

> On 20 Mar 2021, at 21:36, Nico Williams <nico@cryptonector.com> wrote:
>> 
>> This is definitely a problem in a number of deployments.  One aspect
>> that people have to deal with is not so much the gross expiry time,
>> but when it is convenient to take a risk of moving to a new cert.  Of
>> course you’re going to want to make that operation as bullet-proof as
>> possible, but in some environments they want multiple levels of
>> resilience.  So scheduling does become an issue.
> 
> Can you elaborate on this?  Is the issue validation path construction in
> complex PKIs?

Mostly not.  There are two objects that have to be addressed:

Device LDevID expiration and update.
Trust Anchor roll.

The Second case is generally easier, so long as the device is regularly in service; and it may even be easy when the device is out of service for extended periods (think years) so long as it is thought about in advance by both implementor and deployment.

The LDevID change out is harder.  A device can have many trust anchors, but the LDevID change-out has to be handled a bit more carefully.

And how this happens may well vary.  Let’s consider several use cases:

An electrical substation, in which the device is expected to remain in service for perhaps two decades without an outage.  In this case, the updates have to occur in service.
A hospital bed.  In this case, the device will be out of service as often as in, and updates can occur when it is out of service.
A railroad box car/container.  These things are expected to run on battery without maintenance for five years, and may sit idle for weeks or months without any connectivity.  This case is extremely tough and is a bit of a stretch goal.

Each of these sorts of examples occurs in nearly every vertical.  One question is whether scheduling should be in protocols like EST or in device configuration.

Eliot