Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

[Ryan Sleevi <[e-mail]>]

On Sat, Jan 18, 2020 at 5:58 PM Alan DeKok <[e-mail]>
wrote:

>   I'm trying to solve the problem of bootstrapping.  I agree that various
> CAs have various rules.  I agree that anyone can run their own private CA,
> and do whatever they want.  I've been doing that, and recommending it, for
> ~20 years.


Great. Let’s focus on one problem at a time to make sure it’s easier to
follow along. Earlier in the thread you seemed fixated on the first
problem, so it’s unclear when/where/how shifted to the second.

  When the CA *isn't* included with the OS distribution, it means that CA
> *cannot* be used to bootstrap TLS-enabled applications.  Each application
> (not just EAP) MUST be manually configured with the CA.


This isn’t true, if you mean that the end user needs to manually configure.
Modern OSes allow the application vendor - such as the supplicant vendor -
to explicitly configure.

  The alternative is to ask the application to naively trust a CA it
> doesn't know, and a CA which isn't included with the OS distribution.  I
> don't think that will happen.


The alternative is the application ships it’s own root store. Which
applications have been doing for 20+ years and which modern OSes make even
easier.

  It's easy for a browser vendor to tell a CA "issue certs our customers
> can use".  It's much, much, harder for anyone else to do the same thing.


Not really? CAs are plenty happy to sell whatever folks want. Look at stuff
like the drone PKI being developed.

What other application developers can’t do - and this is intentional - is
to get their certs and profiles for the same roots, even if they’re the
same issuing organization.

  It's less of an objection than a statement that we're back to the initial
> conclusion: use a private CA, manually configure, and ignore the root CAs
> shipped with the OS distribution.
>
>   How does that help with the bootstrapping problem?


I already gave that answer several times. Define your profile and policies,
pick (different) roots, and ship them in your software. It’s mistaken to
suggest that you HAVE to use the same roots as the OS.

  I'm happy to use a new PKI.  But we *cannot* and *must not* rely on every
> application to "do it yourself".  There must be a trust anchor shipped with
> OS distributions, that applications can leverage.


No, there doesn’t. That’s an unreasonable demand, because it’s insisting
that advocates of the problem don’t want to actually do the work involved
in developing a solution for the problem. There’s absolutely no reason to
require that it be shipped as part of the OS. Plenty of PKIs exist without
requiring that, and modern OSes make it easier.

Now, it may be that OSes do this, in the future, but that only happens by
first building the profile and policies. Because that’s all an OS root
store is: a set of CAs known to meet particular profiles and policies.
Anyone can define that.

> It’s completely unreasonable to be complaining “CA X won’t let me use
> certificates for this purpose” if you’re not addressing that with CA X. And
> it’s completely unreasonable to complain that Root stores intended for use
> case Y cannot be used with use case Z. Hammers make lousy screwdrivers,
> even if they are both “tools one uses when building furniture”
>
>   Sure.  So how does *my* application get Microsoft, Apple, etc. to ship a
> new PKI?


Provide a problem statement and a solution that’s compelling enough for
them to use? Fixating on the “new PKI” or “must be shipped in the OS” is
completely unreasonable expectation, especially when even the _existing_
PKI doesn’t solve the bootstrap problem unless you convince the OS. There’s
zero advantages to using extant PKI, and ample downside, and you can move
quicker and ship things by just doing the work.