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. 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. 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. Whether we have to convince "the OS vendor", or just "the supplicant > division in the OS vendor" is largely the same thing. It isn’t, and there’s been zero evidence to support that conclusion, but I can tell reality isn’t that convincing :) But again, this doesn't *help*. I can't get my CA shipped with vendor > products, and nothing you've said convinces me that it's possible. You can’t get your non-existent CA that issues against undefined profiles and undefined practices included, and you’re lamenting that? I mean, there’s no place I can go buy a unicorn burger, but I’m not exactly sending letters to McDonald’s complaining about this. The path to getting it shipped with vendor products involves, as I’ve said repeatedly: define the profile and define the policies. That makes it even possible for Billy Bob to issue in the first place, and to assess how well Billy Bob does issue, and that’s the path forward. Lamenting that you can’t get a unicorn burger today doesn’t move the discussion further. And not a single person will download and use the new supplicant > software. Making it 100% useless. This sort of fatalism is doomed to be unproductive. Fixating on the OS vendor as an excuse to not do the work just means won’t get done. Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You have paths forward. 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. The distinction you keep insisting on is like asking “You must invest $10 million”, when all you need is $10. Yes, if you had $10 million, you would have your $10. Continually saying “but I really need the money” rather than “I just need $10” leads to impasses. This is not about which department is involved. The distinction is about the scope of trust. Saying shipped in the OS, both in the context of this thread and more generally, is presuming a broad scope and maintained interfaces for third-parties, neither of which you need. Not recognizing that a “root store” on a modern OS is merely an abstraction over disparate trust bits is meaningful, particularly when not addressing what the “trust bits” should be or how they’re maintained. A good example of this is HotSpot 2.0. It works, it’s not part of the root stores on Windows or Android, yet it uses its own roots and policies and practices and works out of the box. To any developer on those platforms, it’s not part of the OS, yet to the user, it just works. 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. Dismissing that as organizational structure just means dismissing the requirements and means to success, in which case, you’re going to be as unsatisfied as my appetite for a fresh unicorn burger. >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
