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

[Alan DeKok <[e-mail]>]

On Jan 18, 2020, at 4:11 PM, Ryan Sleevi <[e-mail]> wrote:
> 
> You’re conflating several things, as well as seemingly shifting the goal posts here. Perhaps it’s just a poor expression of the problem, as you see it, in which case, it might help to be clearer.

  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.

> Can’t get eapOverLan from a TLS CA? Ok. That’s not a bug, that’s not a misdesign, that’s how it works and is supposed to work.

  Where you say "TLS CA", you mean "WWW CA".  All these other applications use TLS, too.

  In practice, that WWW CA design translates into "CAs which are included with OS distributions".  Which means "CA trivially usable by applications".  ALL applications.  Not just the browser.

  Is it any surprise that *all* applications ended up leveraging that functionality?

  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.

  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.

  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.

> >   That is mostly true, but unhelpful.  Windows doesn't ship with "Billy bob's tackle shop & CA" root certificates.  Neither does Linux, OSX, etc.  Your statement here is just a rephrasing of "use a private CA", and "manually configure things".
> 
> Yes, exactly, which is why I’m not sure the objection.

  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?

> If you don’t like those policies, or you want more purposes, do your own thing. The same modern OS distributions provide that capability for applications to do so, to allow the application vendor to select their trust store, and It Just Works.
> 
> Can’t find someone who does what you want? That’s not a problem: you can do it yourself. In discussing the second problem, there is absolutely zero reason to use anything existing. None whatsoever.

  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.

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

  Answer: even Microsoft and Apple can't do it for their own applications.  They just leverage the pre-existing WWW PKI.

  If trillion dollar companies can't deploy a new PKI for their own applications, it's entirely unreasonable to ask that of a minor cog like me.

  Alan DeKok.