On Thu, Mar 04, 2021 at 09:57:47AM -0500, Phillip Hallam-Baker wrote: > X.509 is really optimized around the totally offline case. And that is a > bad choice for many applications. But it does work for some. No, that's not it. X.509 tries to minimize online infrastructure, but not to zero. In particular, it minimizes *state*. Kerberos too tries to minimize online infrastructure, but does much less well than X.509, and, crucially, as-implemented, Kerberos does NOT minimize STATE. When we started using elastic clouds and hosts coming and going we started having trouble scaling Kerberos even with very nice self-service tooling for it because creating and key-rotating and deleting service principals requires mutating and replicating state. What we ended up doing is implementing a notion of namespace wherein all host-based service principals have their keys derived from base keys, the principals' names, and the _clock_, leading to an unforgiving key rotation schedule and needing host-based roots of trust other than long-term keys for host-based services (since, after all, hosts/apps need credentials to fetch these fast-changing Kerberos keys). To make Kerberos scale we had to remove its dependence on state mutation. Fortunately the state mutation aspect of Kerberos is not inherent in its specification, just in all KDC implementations to date (except Heimdal, which has the feature described above). Now, if you start binding public keys to users via a directory, you'll be unhappy because you'll have all the problems directories have, and because you might get the schema wrong and allow only one key per-user, and even if you don't get the schema wrong you'll have a garbage collection problem, and even if you manage to solve that with expirations then the act of registering new keys is still more complex than the act of signing new certificates. Nico --
