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

[Ryan Sleevi <[e-mail]>]

On Mon, Jan 20, 2020 at 10:13 AM David B. Nelson <[e-mail]>
wrote:

> The arguments about the differentiated policies for use of certificates
> and trust of CAs is probably technically sound.  I think the notion that
> supplicant components can ship with a separate root CA store from that used
> for the browser is perhaps workable.  However, it’s still the OS vendor
> that must include this configuration for it to “just work out o the box”.
> For that reason, I think the claim that it’s not the OS which must support
> the appropriate CAs is a distinction without a difference, and perhaps a
> red herring.


It’s a distinction that cuts to the heart of the original proposal, echo’d
several times on this thread: Can’t we just use the TLS CAs shipped by the
OS today for this, ideally so that OS vendors don’t have any added work.

In that context, it’s essential to make the distinction that while the
end-user experience is indistinguishable, the engineering involved - and
the work of standards here - is meaningfully different. If we conflate the
two or think “let’s just use what we have”, then the world of zero touch
will not happen. That’s why it’s essential to focus on the notion of
defining a new root store, one that doesn’t have to be generally available
to software running on that OS, limited for a particular purpose, so that
we can enumerate the necessary profiles and practices.

It’s also essential to understanding that this solution isn’t gated on a
first-mover problem, as had also been suggested, where everything is doomed
unless and until the OS moves. There’s considerable work that can - and
should - be done, which makes it easier to bring about the second solution
(“zero-touch”), by making sure that the first problem (“what SHOULD you
do”) adequately focuses on making a transition possible.

>