> On 22 Mar 2021, at 22:28, Nico Williams <[email protected]> wrote: > > 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.
The presumption we make in the enterprise is that distribution of TAs in services happens as a matter of normal system management. Absent those TAs the service is going to experience a whole lot of failures. At the application level beyond the bounds of the enterprise, this is a different matter, to be sure. > > TA rollover needs a device update protocol. Within the bounds of the enterprise, that’s EST (RFC 7030). See Section 4.1.2 “/cacerts”. This delivers a PKCS#7 pack of certs. RFC 8951 modestly amends that. > > (Speaking of uniformResourceIdentifier type issuerAltNames, what are > their semantics? If RFC5280 covers that, I've missed it.) Good question. > >> 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 covers one case. Another case that has to be covered is when there’s a need for an unscheduled rollover. This might happen if there was some concern that a private key has been compromised. And then... > > 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. Well, and we haven’t even begun to discuss secure time stamps here (you can track some recent discussion of that discussion on the openssl-users list). And you’re hitting another issue- stuff like RFC 4476. I don’t know how widely that extension is found, but there are others; and there is something of a debate in some circles about whether to do RBAC et al in certs. And so an occasional query also seems appropriate. EST doesn’t really define that. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
