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

[Ryan Sleevi <[e-mail]>]

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

> > Supplicant vendors - whether they are open-source or operating system -
> are taking on the work to manage and police that root store.
>
>   They "are" doing this?  I don't see that.


This was trying to describe the world in which the second problem was
solved. They “would be”, which is why the message later clarified how to
justify the risk/value proposition.

> They are not at all different. In both cases, the client has a principal
> it wants to validate: in RFC 6125, this is the reference name. This is the
> name in your credential in the case of EAP, the name of the host in the URL
> in WWW. The client wants to make sure it’s talking to the entity authorized
> for that name.
> >
> > You can manually preconfigured exactly that entity. In EAP, this is
> incredibly easy to do when you’re provisioning the client credential to
> also provision the peer identity. This is the existing flow.
>
>   I agree that they're similar, I'm not sure that they're identical.


This is why advocates need to define the profile and policies :) Figuring
our what information is needed is essential to figuring out the
similarities and differences.

> This may seem like splitting hairs, but it’s a _profound_ distinction if
> you’ve ever managed PKIs on operating systems, as this is not true.
> Shipping a CA list in the supplicant shipped in the OS != shipping a CA
> list in the OS. They are very different models of managing and configuring
> that should not be conflated. Android has plenty of OS components that ship
> their own root stores, separate from the root store it provides as part of
> its public API contract. We only need the former, not the latter.
>
>   What matters is that the product the user ends up with has the CAs
> preconfigured for EAP.  The internal corporate structure is (to me)
> irrelevant.


Don’t conflate technical requirements with corporate structure. You’re
insisting on a precise technical requirement, and I’m explaining to you why
you’re using the term wrong, and in a way that meaningfully detracts and
profoundly conflates things. There’s a tremendous amount of difference in
cost and engineering between the two approaches, and so it’s important to
be clear the requirement - which is the less expensive one.

  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 seems we’re in agreement that the status quo is manual configuration, it
seems we’re in agreement that there’s no technical or procedural reason to
use the set of publicly trusted CAs for TLS (it doesn’t get you automatic
recognition, it does increase your risk surface), and it seems we’re in
agreement that defining a unified store is a lot of work with an unclear
value proposition that justifies that work.

> Going back to the original mail, there’s nothing to be gained from trying
to repurpose extant stores, and best practice remains manual configuration.
If folks want more than that, they need to define what they want and how
it’s validated, and figure out what CAs do that. All of this was part of
that first reply, so are we just in agreement?