On Tue, Mar 23, 2021 at 11:49:23AM -0400, Michael Richardson wrote: > 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. > > TLS discourages sending the root CA cert. > I prefer to send it for a number of reasons, and this is one of them.
You can only send them when they are available as certificates (which TAs are not required to be). But +1. > > 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). > > EST includes includes updating the CA trust anchors as a protocol item. > We don't have to have to replace the firmware. Yeah, I know, but in the enterprise we still use packages, though not necessarily packages with software, just configuration. > > 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". > > Yes, that's exactly what I'm after. > We can, as you suggest, do this as an HTTP header in EST. > It could also go into some new certificate extension, although it's rather > more meta data, and it isn't clear it should get shared with peers. Well, I suppose there one more way. I asked about the semantics of URI issuerAltNames, and maybe the right answer is that /.well-known for the base URI should let you discover... lots of things, like EST, and... this. > > Michael tells me maybe the CA software gets upgraded and other > > changes sneak in that one did not expect. > > So, I was thinking of a hypothetical that could result in a surprising change > in the field during what should be a non-event renewal. I agree it's possible, likely even. Nico -- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
