On Jan 20, 2020, at 11:51 AM, Ryan Sleevi <ryan-i...@sleevi.com> wrote: > On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok <al...@deployingradius.com> wrote: > The distinction doesn't even matter in the content of root stores. The > vendor downloads N root CAs, and places them into files / DBs in the product. > Whether those files from from A and go to B, or come from C and go to D is > *entirely* irrelevant to the end product. Whether it's Department A that > downloads the roots CAs or Department B is also irrelevant. > > This is not at all how root stores work or have worked for ages, and I > suspect this lack of familiarity may be the cause of the significant > confusion demonstrated here.
In a word: no. > There isn’t “a” root store on any modern OS. Even if you factor Linux with > the LSB, there are multiple root stores. Multiple independent root stores are > maintained for separate purposes, with their own policies and profiles, > administered not only by different parts of the organization, but also > against different standards and with different industry bodies. So in a message where I explicitly say that CAs go to multiple places, your conclusion is that I believe there's only one root store? > This basic understanding of how modern PKI works is essential to > understanding how to make productive contributions in this space, because it > shapes how the profiles are developed, how the policies are administered, and > how one makes progress convincing the right stakeholders of the vision. I could say the same thing about previous misconceptions in how EAP is implemented. > Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You have > paths forward. Cisco: yes. Jouni: No. wpa_supplicant / hostap is just a collection of source code in a git tree. It includes no CAs. And if it did, people would ignore them. Any open source author has minimal influence on how their end product is used. I know this from 20+ years of experience. You seem to think you can convince me if you just repeat often enough "but you can define your own CA!" I know this. I don't care. It's irrelevant, for reasons I've explain. > When I do RADIUS stuff, I say "the vendor has to do X". It's never been > useful to say "Bob in engineering department X has to do it". The > distinction you're making is 100% irrelevant. > > You’re confusing “everyone at the vendor needs to move their car” with “Bob > needs to move his car”. You’re doomed to failure if you keep insisting > everyone at the company needs to move their car, when all you need is Bob to > move and not block your car in. That is absolutely not the conclusion you can draw from what I said. When I say "the customer sees one end product, and therefore I don't care which group does the update", I do NOT mean "every individual department which works on the OS has to be updated in order to get this new EAP functionality". To be frank, this insinuation uncalled for. You're implying that I'm an idiot who "keeps insisting everyone at the company needs to" do the update. That is absolutely not true, and you should apologize for saying something so outlandish. > The IETF primarily targets those developers, not the end-user, and it’s > essential to understand why and how it works to understand what work is > needed to make something similar for EAP. In a word: no. In a longer phrase: you're essentially claiming that the entire IETF process (which does NOT do this) is wrong, and doesn't work. Since we're not making progress, I'll stop. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
