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+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
