On Mon, Jan 20, 2020 at 8:53 AM Alan DeKok <al...@deployingradius.com> wrote:
> I fully understand that applications can easily ship root CAs. We can > therefore agree that the root CAs MUST be distributed with the software. > > But, precisely *zero* end users download their supplicant software. The > supplicant software comes with the OS. Which means that the root CAs must > be distributed with the OS. > I tried to address this in my previous message, but it looks like that may not have come across clearly. It might seem like there's a distinction without a difference to say "must ship with the supplicant which ships with the OS" and "must ship with the OS", but going back to Owen's original message, there's a profound difference in the two. As this thread itself demonstrates, there's ample confusion on "distributed with the OS" and what trust purposes it's good for - policies, practices, operational procedures - and continuing to insist "distributed with the OS" is to continue to further that confusion. As I hoped my previous message conveyed, but it looks like it may not have been clear for you, I'm not dismissive that for supplicants distributed by the OS vendor, you (eventually) need to convince that OS vendor to distribute roots with their supplicants, and from the end-user perspective, a default install of that OS "just works". However, it's a very meaningful distinction in the context of root stores, even if it may not be for supplicant authors, to highlight the need to distribute roots _with the supplicant_, not the OS. This is not a corporate distinction, but it is meaningful to how solutions are engineered and the problem space, and that's why it does a great disservice to dismiss that distinction. > The same goes for root CAs. While it's superficially true that someone > can start "Billy Bobs Tackle Shop & CA", no one has any reason to *use* > that CA. Saying "you can start a CA" and by implication have people *use* > it, is no more realistic than me saying "you write software, Bill Gates > wrote software, there's nothing preventing you from being as rich as he > is." This is again shifting the discussion. If you don't believe it is, then certainly, how you're communicating is not coming across clearly. As I've mentioned several times, anyone can issue certificates, which is all that matters for manual configuration. There's no need for anyone special or blessed - it's just manual configuration. If you'd like to go to automatic configuration, then you need to define policies and practices for issuance and verification. Anyone who can comply with those can become a CA. The usefulness of "Billy Bob's Tackle Shop & CA" is dictated by those who need a CA - the supplicants - and how well Billy Bob complies with the policies and practices. You're absolutely correct that if you don't define those, then _no one_ can become a CA. There's no reason to believe that Billy Bob is more or less qualified than an extant CA unless and until you define those. And, of course, once you define those, the usefuless of Billy Bob - how likely his CA-slash-tackle-shop is to be included - is dictated by those defining the root store. That's where the SDOs come in to place. > > 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 demonstrates that vendors have shown little interest in making WiFi > easier to use for their end users. This decision is likely to have an > impact on these efforts. > Then why are we wasting electrons discussing how to do it? If you believe it's a doomed effort from the start, why bother replying? The nice thing about the transition plan I've outlined several times is you don't need the OS vendors to all adopt apriori for it to be useful. Other supplicant vendors can go ahead, define their policies and practices, select their CAs, and build their root store. If it provides something useful - i.e. users do find it easier and the security tradeoffs are appropriately mitigated, such as by taking the many concerns I've expressed on this thread into consideration - then vendors may eventually come around. As I mentioned several times, there's a risk/benefit calculus at play, and advocates of the idea of a common trust store need to make a compelling case as to how to mitigate those risks. With your proposed work flow, this is just impossible. It's really just > manual configuration with fewer steps. It still requires extra software / > configuration / whatever to be downloaded. I'm afraid you've considerably misunderstood the proposal then, as I've tried to express several times. I'm well aware the end goal is that on a 'stock' install of your OS of choice, everything just works. I've outlined several times a plan to get to that - and which does not involve shipping roots in the OS, but roots in the supplicant that comes with the OS. The distinction is quite meaningful for the reasons outlined throughout this thread, even if the end user experience is "it just works"
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
