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

[Alan DeKok <[e-mail]>]

On Jan 20, 2020, at 10:44 AM, Ryan Sleevi <[e-mail]> wrote:
> 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.

  There has been consensus already that it's wrong to use the existing TLS CAs

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

  I agree.

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

  I don't think "doomed".  I think *required*.  i.e. the end goal *is* to have it "just work" out of the box.

  I think we may be arguing semantics, and avoiding some common points.

  I *do* agree that we can define new CAs just for EAP today.  I do agree that these CAs can be used by supplicants that exist today, via manual configuration.

  However, I do also believe that we will not get new behaviour without changing the supplicant implementations.  So the intermediate step of just using a "new CA" has near-zero benefits to the end user.

  And, if the new CA must be configured manually, then that step is no different than what we have today.  Which means that this intermediate step further has near-zero benefits.

  That's why I'm focussed on the end goal: updating the root CAs *and* supplicant implementations at the same time.  And, making sure that all of these updates ship with the product that the consumer buys.  The intermediate steps gain nothing.

  Alan DeKok.