On Mon, Jan 20, 2020 at 10:13 AM David B. Nelson <d.b.nel...@comcast.net> 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. >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
