Re: What ASN.1 got right

[Nico Williams <[e-mail]>]

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
--