On Tue, Mar 02, 2021 at 05:06:47PM -0800, Michael Thomas wrote: > > It's the same problem as getting the keys into the directory. > > But it's not the same problem as getting a cert (chain) out of the CA and > installing it on the client. [...] The latter is strictly simpler for the reasons I gave. > > > Not having to do anything at all on the client is a significant savings. I > > > would much rather the help desk cost of nothing different than taking calls > > > on how to install the ssh certs on exotic and not so exotic clients. > > Yes, if you ignore the part about having to get the keys into the > > directory. > They both have to do that, so it cancels that out. But the directory case requires things that don't exist (e.g., schema, tools) and also online infrastructure. Certificates don't. > > We have an online CA with an HTTP API. You POST a CSR authenticating > > with whatever credentials you've got, and you get back a short-live > > certificate for your authenticated name(s) or for the requested name(s) > > if you're authorized to them. Using this is trivial. > > That doesn't alter that needing offline authentication is niche. A Mars > rover might need that. My phone connected to the internet, not so much. You say niche, but it's not at all. And before anyone mentions CRLs and/or OCSP, the real answer to revocation os short-lived credentials (with fast, unforgiving rotation schedules). We issue 5 day server certs, for example. We also have a Kerberos KDC extension that uses virtual service principals keyed on a clock, with services having to fetch "keytabs" frequently via an HTTP API. This is strictly simpler than having to modify a bunch of applications and libraries to do directory lookups. And there is no online infrastructure at the point of authentication in the PKIX case. Nico --
