On Tue, Mar 23, 2021 at 07:46:53AM +0100, Eliot Lear wrote: > > On 22 Mar 2021, at 22:28, Nico Williams <[email protected]> wrote: > > 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.
Sure, but there's still a bootstrap issue that will be solved with packaging (in the enterprise). > > (Speaking of uniformResourceIdentifier type issuerAltNames, what are > > their semantics? If RFC5280 covers that, I've missed it.) > > Good question. I was hoping someone here would know the answer :) Maybe EST (and any CA-relevant protocol that can be discovered through /.well-known) could be used to provide semantics for http/https scheme URI issuerAltNames. > > 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... And then? Well, then you need a field update, possibly by sending out a technician. Firmware and software have eaten the world, and just as we have to trim vegetation under power transmission lines and so on, we must update devices in the field. Currently this seems infeasible just on account of abandonware (of which we'll have more and more), let alone cost for non-abandonware. > > 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). [...] Oh, you're concerned that a device might get a postdated certificate or something? Why would a CA issue a postdated certificate? Or perhaps RPs won't have access to secure time services and so they may observe a valid certificate as invalid? But I think secure time is an orthogonal concern and it is present even in the absense of certificate rollover. You could say that super-long-lived certificates don't have this problem, but they have other problems. And lacking secure time will hurt devices in other unrelated ways. The trade-off is validity period length vs CRL size and online OCSP infrastructure requirements, and if the choice made by implementors is long-lived certs w/ no revocation then costly manual field updates will be needed in the event of compromise. I'm not keen on recommending very long-lived certificates for devices just because of the potentially difficult rollover circumstances. > [...]. 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. Rolling of ACs is relevant. I'm not sure how much ACs get used in any of these devices. In the enterprise I've yet to see any AC use. Haven't authorization token systems won out anyways? Nico -- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
