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

_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu

Reply via email to