On Mon, Jan 20, 2020 at 3:31 PM Alan DeKok <al...@deployingradius.com> wrote:
> > 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. I’m afraid this is quite disconnected from reality, then. The premiere root store on more devices than any other is the Mozilla Root Store, developed as part of the open-source NSS package, shipped in virtually every mainstream Linux/BSD distro, and used in wide swaths beside that (e.g. curl, server programming languages, IoT, cars, thermostats) The decisions made by Mozilla - to add or remove CAs for given purposes, like TLS or S/MIME - reverberate on a host of ecosystems, for better and for worse. The reason for that adoption is on the strength of the profiles and policies, and addressing a real need, which are the things not being addressed here for EAP. There’s nothing that prevents a “Like-Mozilla-but-for-EAP” root store being developed. Like all root stores, it requires defining your profiles for how the information is expressed, the practices for how clients validate and use that information, and the policies for how CAs appropriately vet and validate that information. The first two - profiles and practices - are excellent candidates for standardization efforts. The latter, policies, is as the name suggests, more about policy and left to industry efforts. The technical decisions in the profiles and practices affect the policies - some decisions create more work, some less, such as the discussions around EKUs. The choice to implement, as an OS/supplicant vendor, is about evaluating the risk of the policies. How much do the technical decisions expose users to risk vs mitigate risks of misconfiguration? How can those policies be customized or adjusted to the needs of the vendor, and what interoperability risks exist when they are so customized? If you’re talking PKI, it’s inherently risk management, which is managing the policies to support the technologies. We generally don’t hear, for example, the SSH community remarking on a lack of an out-of-the-box PKI that just works for all their hosts. That’s because the policies, and the needs of constituents, aren’t really aligned with that sort of global model. Local PKIs - whether TOFU or local SSH PKIs - better balance the risk. Today, that calculus is largely true for EAP, at least from the POV of supplicant implementors. If you want to convince otherwise, it’s about defining those profiles and policies that can show that different calculus. 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". This is not what I said either. The notion of “add to the OS root store” has impact on every OS component, which needs to be evaluated holistically. The decision _impacts_ them, from a risk management standpoint, even when it doesn’t need to and shouldn’t. That’s everyone having to move their car, or asking for $10 million.. You don’t need impact on every OS component. You only care about EAP, clearly. Thats why it’s important to be precise on what is needed - something _just_ for EAP. That’s only needing Bob to move his car, or asking for $10. So when talking about what this hypothetical root store should be, it needs to be clear that it’s only for EAP, and saying “added to the OS” is far more than EAP, with far more impact than needed or intended. It leads to confusion, such as in the original message, around concepts like “public CAs”, which only hurts the conversation. Plenty of folks have been confused, for example, ingesting the Mozilla source files without realizing it is three separate root stores, each with their own policies, management, and constraints, some of which are not expressed purely in a single file. That this happens often, or messages like Owen highlight “public CAs” without qualification, are the same reason it’s important to be clear we’re talking about a _new_ root store for a _new_ purpose, and thus nothing extant has any bearing whatsoever on this store.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
