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 -- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
