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

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Mar 2021 08:57:04 -0400

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Mar 2021 17:48:33 +0100

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

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]