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

Toerless Eckert <tte@cs.fau.de> Thu, 18 March 2021 16:48 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 36C743A2F5C; Thu, 18 Mar 2021 09:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 llGhUtCkiHoW; Thu, 18 Mar 2021 09:48:41 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0AC3A2F59; Thu, 18 Mar 2021 09:48:40 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B23AE548056; Thu, 18 Mar 2021 17:48:33 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A56C5440166; Thu, 18 Mar 2021 17:48:33 +0100 (CET)
Date: Thu, 18 Mar 2021 17:48:33 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: lamps@ietf.org, acme@ietf.org, anima@ietf.org
Message-ID: <20210318164833.GA36050@faui48f.informatik.uni-erlangen.de>
References: <4360.1616072224@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4360.1616072224@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/P3RTWD6wzmeO68HVX1Zt3NI-TxI>
Subject: Re: [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 16:48:44 -0000

In ACP/BRSKI, we discussed for the semantic of lifetime of short-lived
certificates to distingish between different type of "uses" of the
certificate. At that time mainly two:

a) using the certificate for "anything"
b) using the certificate as an authenticator to get itself renewed.

And the argument was that registrars could forego checking the liftime
when performing b), because otherwise, the process would become potentially
a lot more complex, requiring for example a new voucher from the MASA.

If i recollect the reaction to this piece, it was that registrars should
indeed have this freedom, but it was unclear if/where/what "legal" (RFC)
text would or would not say so or what additional text would be required to
make it "legal" if it wasn't.

getting back to your problems: It is not clear to me exactly what all needs
to happen for the network to be fully functional and hence in a state where
short lived certificates should pose no issue. BUT: instead of defining
b) as just "ignore lifetime only as registrar when you do renewal", maybe
one could say "ignore lifetime for all applications of the certificate
necessary to establish/maintain minimum network operations so the PKI
system can work - but nothing else (or whatever else is the necessary
minimum level of operations that allows to recover from errors)".

For example, if an ACP was only used for BRSKI but nothing else, then this
would mean that ACP secure channel authentication would ignore the lifetime,
so that the BRSKI-proxy traffic would work across the ACP. But any other
use of the certificate, e.g.: for the hopefully existing data-plane security
would rely on the liftime, and hence the data-plane would not work until
a registrar finally renews the certificates (a process which may or may
not be convoluted due to the scenarios you mention).

Of course, in your scenarios there may not be (*sob* ;-) a full-blown
ACP, but that should make it likely even easier to figure out the
minimum operating set of functions to have a network-wide PKI be able to renew under
all circumstances.

Cheers
    Toerless

On Thu, Mar 18, 2021 at 08:57:04AM -0400, Michael Richardson wrote:
> 
> 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
> 
> 
> 
> 



> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
tte@cs.fau.de