On Tue, Mar 02, 2021 at 04:43:10PM -0800, Michael Thomas wrote: > On 3/2/21 4:23 PM, Nico Williams wrote: > > I wouldn't want to do this. It's much more complex than the client > > sending a certificate. > > Huh? It's a bit of configuration on the server side that is probably > captured in provisioning systems. And client provisioning -- which is what > certs imply -- is extremely problematic. How do I get a client ssh cert onto > my phone's ssh app, for example? Not having to change client behavior or > provisioning significantly simplifies the problem. It's the same problem as getting the keys into the directory. > 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. > > > If you care about that, I suppose. I think most people do the leap of faith > > > and known_hosts ignores the problem. > > I very much care about that. Certainly in a corporate network. > > It's orthogonal to the client side authentication problem though. It's a similar problem, and you can't ignore it. > Uploading a new public keys is the ~same for both. Downloading a client cert > is a whole lot of something. And if your corpro directory is down, you are > already in a world of hurt. The advantage of offline verification in the age > of 24/7 internet is very niche. 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. Nico --
