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

[Nico Williams <[e-mail]>]

On Sun, Mar 21, 2021 at 10:27:00AM +0100, Eliot Lear wrote:
> [Reducing]

[Whenever possible]

> > 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.

End entities send a validation chain for their EE certs, but not the
root CA's cert, and anyways, RPs need to know trust anchors a priori.
Therefore rolling out new TAs is tricky.

TA rollover needs a device update protocol.  Which is a pain in large
part because it's completely unstandardized and anyways implies a
separate trust structure for update signing (e.g., a package signer
PKI).

Maybe the chains should always have included the roots so that rollover
could have been handled via the old one signing the new one.  Or maybe
we need an extension like AuthorityInfoAccessSyntax (or maybe just use a
URI issuerAlternativeName?) to indicate rollover information for roots
that can be used by RPs to update trust anchors (again, with
old-signs-new or with a signature by some separate PKI as in the
packaging case).

(Speaking of uniformResourceIdentifier type issuerAltNames, what are
their semantics?  If RFC5280 covers that, I've missed it.)

> 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.
>
> [...]

Yes, devices can have considerations that an EST server may not be able
to know.

So I think we're talking about the server indicating a refreshAfter time
or a doNotRefreshBefore time rather than a refreshAt time.  An
informative "you can refresh after this $time" and maybe a normative "do
not even think of refreshing before this $time".

That said, a simple certificate refresh where no algorithms change, no
parameters change, no critical extensions are added, etc. -- where the
only real change is the validity period -- surely this is safe to
perform whenever the device can talk to the online CA.  One could argue
that making sure that the only change is the validity period (and maybe
the SPKI, but not its alg or params) is difficult to ensure.  Michael
tells me maybe the CA software gets upgraded and other changes sneak in
that one did not expect.

Nico
--