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

[Ryan Sleevi <[e-mail]>]

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

>   The distinction doesn't even matter in the content of root stores.  The
> vendor downloads N root CAs, and places them into files / DBs in the
> product.  Whether those files from from A and go to B, or come from C and
> go to D is *entirely* irrelevant to the end product.  Whether it's
> Department A that downloads the roots CAs or Department B is also
> irrelevant.


This is not at all how root stores work or have worked for ages, and I
suspect this lack of familiarity may be the cause of the significant
confusion demonstrated here.

There isn’t “a” root store on any modern OS. Even if you factor Linux with
the LSB, there are multiple root stores. Multiple independent root stores
are maintained for separate purposes, with their own policies and profiles,
administered not only by different parts of the organization, but also
against different standards and with different industry bodies.

This basic understanding of how modern PKI works is essential to
understanding how to make productive contributions in this space, because
it shapes how the profiles are developed, how the policies are
administered, and how one makes progress convincing the right stakeholders
of the vision.

  Whether we have to convince "the OS vendor", or just "the supplicant
> division in the OS vendor" is largely the same thing.


It isn’t, and there’s been zero evidence to support that conclusion, but I
can tell reality isn’t that convincing :)

  But again, this doesn't *help*.  I can't get my CA shipped with vendor
> products, and nothing you've said convinces me that it's possible.


You can’t get your non-existent CA that issues against undefined profiles
and undefined practices included, and you’re lamenting that? I mean,
there’s no place I can go buy a unicorn burger, but I’m not exactly sending
letters to McDonald’s complaining about this.

The path to getting it shipped with vendor products involves, as I’ve said
repeatedly: define the profile and define the policies. That makes it even
possible for Billy Bob to issue in the first place, and to assess how well
Billy Bob does issue, and that’s the path forward. Lamenting that you can’t
get a unicorn burger today doesn’t move the discussion further.

  And not a single person will download and use the new supplicant
> software.  Making it 100% useless.


This sort of fatalism is doomed to be unproductive. Fixating on the OS
vendor as an excuse to not do the work just means won’t get done.

Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You
have paths forward.

   When I do RADIUS stuff, I say "the vendor has to do X".  It's never been
> useful to say "Bob in engineering department X has to do it".  The
> distinction you're making is 100% irrelevant.


You’re confusing “everyone at the vendor needs to move their car” with “Bob
needs to move his car”. You’re doomed to failure if you keep insisting
everyone at the company needs to move their car, when all you need is Bob
to move and not block your car in.

The distinction you keep insisting on is like asking “You must invest $10
million”, when all you need is $10. Yes, if you had $10 million, you would
have your $10. Continually saying “but I really need the money” rather than
“I just need $10” leads to impasses.

This is not about which department is involved. The distinction is about
the scope of trust. Saying shipped in the OS, both in the context of this
thread and more generally, is presuming a broad scope and maintained
interfaces for third-parties, neither of which you need. Not recognizing
that a “root store” on a modern OS is merely an abstraction over disparate
trust bits is meaningful, particularly when not addressing what the “trust
bits” should be or how they’re maintained.

A good example of this is HotSpot 2.0. It works, it’s not part of the root
stores on Windows or Android, yet it uses its own roots and policies and
practices and works out of the box. To any developer on those platforms,
it’s not part of the OS, yet to the user, it just works.

The IETF primarily targets those developers, not the end-user, and it’s
essential to understand why and how it works to understand what work is
needed to make something similar for EAP. Dismissing that as organizational
structure just means dismissing the requirements and means to success, in
which case, you’re going to be as unsatisfied as my appetite for a fresh
unicorn burger.

>