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

[Ryan Sleevi <[e-mail]>]

On Mon, Jan 20, 2020 at 8:53 AM Alan DeKok <[e-mail]>
wrote:

>   I fully understand that applications can easily ship root CAs.  We can
> therefore agree that the root CAs MUST be distributed with the software.
>
>   But, precisely *zero* end users download their supplicant software.  The
> supplicant software comes with the OS.  Which means that the root CAs must
> be distributed with the OS.
>

I tried to address this in my previous message, but it looks like that may
not have come across clearly. It might seem like there's a distinction
without a difference to say "must ship with the supplicant which ships with
the OS" and "must ship with the OS", but going back to Owen's original
message, there's a profound difference in the two. As this thread itself
demonstrates, there's ample confusion on "distributed with the OS" and what
trust purposes it's good for - policies, practices, operational procedures
- and continuing to insist "distributed with the OS" is to continue to
further that confusion.

As I hoped my previous message conveyed, but it looks like it may not have
been clear for you, I'm not dismissive that for supplicants distributed by
the OS vendor, you (eventually) need to convince that OS vendor to
distribute roots with their supplicants, and from the end-user perspective,
a default install of that OS "just works". However, it's a very meaningful
distinction in the context of root stores, even if it may not be for
supplicant authors, to highlight the need to distribute roots _with the
supplicant_, not the OS. This is not a corporate distinction, but it is
meaningful to how solutions are engineered and the problem space, and
that's why it does a great disservice to dismiss that distinction.


>   The same goes for root CAs.  While it's superficially true that someone
> can start "Billy Bobs Tackle Shop & CA", no one has any reason to *use*
> that CA.  Saying "you can start a CA" and by implication have people *use*
> it, is no more realistic than me saying "you write software, Bill Gates
> wrote software, there's nothing preventing you from being as rich as he
> is."


This is again shifting the discussion. If you don't believe it is, then
certainly, how you're communicating is not coming across clearly.

As I've mentioned several times, anyone can issue certificates, which is
all that matters for manual configuration. There's no need for anyone
special or blessed - it's just manual configuration.

If you'd like to go to automatic configuration, then you need to define
policies and practices for issuance and verification. Anyone who can comply
with those can become a CA. The usefulness of "Billy Bob's Tackle Shop &
CA" is dictated by those who need a CA - the supplicants - and how well
Billy Bob complies with the policies and practices. You're absolutely
correct that if you don't define those, then _no one_ can become a CA.
There's no reason to believe that Billy Bob is more or less qualified than
an extant CA unless and until you define those. And, of course, once you
define those, the usefuless of Billy Bob - how likely his
CA-slash-tackle-shop is to be included - is dictated by those defining the
root store. That's where the SDOs come in to place.


> >   There have been attempts to simplify supplicant configuration with a
> standard XML format.  The vendors expressed zero interest.  And that's a
> *lot* easier to do than adding a new root store.
> >
> > I’m not sure how this is relevant?
>
>   It demonstrates that vendors have shown little interest in making WiFi
> easier to use for their end users.  This decision is likely to have an
> impact on these efforts.
>

Then why are we wasting electrons discussing how to do it? If you believe
it's a doomed effort from the start, why bother replying?

The nice thing about the transition plan I've outlined several times is you
don't need the OS vendors to all adopt apriori for it to be useful. Other
supplicant vendors can go ahead, define their policies and practices,
select their CAs, and build their root store. If it provides something
useful - i.e. users do find it easier and the security tradeoffs are
appropriately mitigated, such as by taking the many concerns I've expressed
on this thread into consideration - then vendors may eventually come
around. As I mentioned several times, there's a risk/benefit calculus at
play, and advocates of the idea of a common trust store need to make a
compelling case as to how to mitigate those risks.

  With your proposed work flow, this is just impossible.  It's really just
> manual configuration with fewer steps.  It still requires extra software /
> configuration / whatever to be downloaded.


I'm afraid you've considerably misunderstood the proposal then, as I've
tried to express several times. I'm well aware the end goal is that on a
'stock' install of your OS of choice, everything just works. I've outlined
several times a plan to get to that - and which does not involve shipping
roots in the OS, but roots in the supplicant that comes with the OS. The
distinction is quite meaningful for the reasons outlined throughout this
thread, even if the end user experience is "it just works"