Re: What ASN.1 got right

[Nico Williams <[e-mail]>]

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