[Reducing]

Hi Nico,

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

Attachment: signature.asc
Description: Message signed with OpenPGP

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

Reply via email to