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

[Eliot Lear <[e-mail]>]

[Reducing]

Hi Nico,

> On 20 Mar 2021, at 21:36, Nico Williams <[e-mail]> 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