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

Nico Williams <nico@cryptonector.com> Tue, 23 March 2021 14:49 UTC

Return-Path: <nico@cryptonector.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 2F3EA3A10A7; Tue, 23 Mar 2021 07:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 iUxVyQ6xGhJJ; Tue, 23 Mar 2021 07:49:46 -0700 (PDT)
Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372FC3A109F; Tue, 23 Mar 2021 07:49:45 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 551CF1E409A; Tue, 23 Mar 2021 14:49:43 +0000 (UTC)
Received: from pdx1-sub0-mail-a45.g.dreamhost.com (100-96-27-144.trex.outbound.svc.cluster.local [100.96.27.144]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6CC6A1E3E90; Tue, 23 Mar 2021 14:49:41 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a45.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.27.144 (trex/6.1.1); Tue, 23 Mar 2021 14:49:43 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Squirrel-Cold: 0bb4e215724f00e1_1616510982809_2534514864
X-MC-Loop-Signature: 1616510982809:2975049115
X-MC-Ingress-Time: 1616510982809
Received: from pdx1-sub0-mail-a45.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTP id BDA547F22C; Tue, 23 Mar 2021 07:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=nLOq3dPaUIGUejtbGIn8RNlffak=; b=MB0zxB4Ux9e jYy9Cclu8touzFdSCvHF6NpZm8lTzBMs1+c0ZdNmcA3mxh3aT+JEoAqVBYxMJpCo NI/IOLezwxSyECCWa5XX3bu4q/Aj8pPbps2SfU/yuSPrLciS3qEsBnd1gacHo6W+ r7EXFy8bNzLmwf8ku7ArP5XUrqA1Jo9s=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTPSA id D6C5E7F036; Tue, 23 Mar 2021 07:49:37 -0700 (PDT)
Date: Tue, 23 Mar 2021 09:49:35 -0500
X-DH-BACKEND: pdx1-sub0-mail-a45
From: Nico Williams <nico@cryptonector.com>
To: Eliot Lear <lear@cisco.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Toerless Eckert <tte@cs.fau.de>, LAMPS <spasm@ietf.org>, anima@ietf.org
Message-ID: <20210323144934.GT30153@localhost>
References: <20210318165455.GM8957@faui48f.informatik.uni-erlangen.de> <20210318183001.GN30153@localhost> <2113.1616093888@localhost> <718D80AD-8F12-4AA0-9D2A-2D8806B487C2@cisco.com> <20210320203655.GR30153@localhost> <B38811EA-335C-4BEC-800C-B88DDA44DE74@cisco.com> <20210322212842.GS30153@localhost> <555B7B50-6264-4400-89F0-53F79C6F4C70@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <555B7B50-6264-4400-89F0-53F79C6F4C70@cisco.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/g1PhbmU6rmfzdzXeSCxbOXHbivw>
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: Tue, 23 Mar 2021 14:49:50 -0000

On Tue, Mar 23, 2021 at 07:46:53AM +0100, Eliot Lear wrote:
> > On 22 Mar 2021, at 22:28, Nico Williams <nico@cryptonector.com> wrote:
> > TA rollover needs a device update protocol.
> 
> Within the bounds of the enterprise, that’s EST (RFC 7030).  See
> Section 4.1.2 “/cacerts”.  This delivers a PKCS#7 pack of certs.  RFC
> 8951 modestly amends that.

Sure, but there's still a bootstrap issue that will be solved with
packaging (in the enterprise).

> > (Speaking of uniformResourceIdentifier type issuerAltNames, what are
> > their semantics?  If RFC5280 covers that, I've missed it.)
> 
> Good question.

I was hoping someone here would know the answer :)

Maybe EST (and any CA-relevant protocol that can be discovered through
/.well-known) could be used to provide semantics for http/https scheme
URI issuerAltNames.

> > So I think we're talking about the server indicating a refreshAfter time
> > or a doNotRefreshBefore time rather than a refreshAt time.  An
> > informative "you can refresh after this $time" and maybe a normative "do
> > not even think of refreshing before this $time".
> 
> That covers one case.  Another case that has to be covered is when
> there’s a need for an unscheduled rollover.  This might happen if
> there was some concern that a private key has been compromised.  And
> then...

And then?  Well, then you need a field update, possibly by sending out a
technician.  Firmware and software have eaten the world, and just as we
have to trim vegetation under power transmission lines and so on, we
must update devices in the field.  Currently this seems infeasible just
on account of abandonware (of which we'll have more and more), let alone
cost for non-abandonware.

> > That said, a simple certificate refresh where no algorithms change, no
> > parameters change, no critical extensions are added, etc. -- where the
> > only real change is the validity period -- surely this is safe to
> > perform whenever the device can talk to the online CA.  One could argue
> > that making sure that the only change is the validity period (and maybe
> > the SPKI, but not its alg or params) is difficult to ensure.  Michael
> > tells me maybe the CA software gets upgraded and other changes sneak in
> > that one did not expect.
> 
> Well, and we haven’t even begun to discuss secure time stamps here
> (you can track some recent discussion of that discussion on the
> openssl-users list).  [...]

Oh, you're concerned that a device might get a postdated certificate or
something?  Why would a CA issue a postdated certificate?  Or perhaps
RPs won't have access to secure time services and so they may observe a
valid certificate as invalid?  But I think secure time is an orthogonal
concern and it is present even in the absense of certificate rollover.

You could say that super-long-lived certificates don't have this
problem, but they have other problems.  And lacking secure time will
hurt devices in other unrelated ways.  The trade-off is validity period
length vs CRL size and online OCSP infrastructure requirements, and if
the choice made by implementors is long-lived certs w/ no revocation
then costly manual field updates will be needed in the event of
compromise.

I'm not keen on recommending very long-lived certificates for devices
just because of the potentially difficult rollover circumstances.

>               [...].  And you’re hitting another issue- stuff like RFC
> 4476.  I don’t know how widely that extension is found, but there are
> others; and there is something of a debate in some circles about
> whether to do RBAC et al in certs.

Rolling of ACs is relevant.  I'm not sure how much ACs get used in any
of these devices.  In the enterprise I've yet to see any AC use.
Haven't authorization token systems won out anyways?

Nico
--