On Jan 19, 2020, at 10:54 AM, Ryan Sleevi <[email protected]> wrote: > There’s zero need to use any existing CAs.
I agree. > Of course, the CAs are only going to do that if there are users: those who > will buy or rely on those certificates. So you need to convince supplicants > that a zero-touch world is worth it, AND that it can be as secure as manual > configuration. First the solution needs to be defined. > Supplicant vendors - whether they are open-source or operating system - are > taking on the work to manage and police that root store. They "are" doing this? I don't see that. > They are not at all different. In both cases, the client has a principal it > wants to validate: in RFC 6125, this is the reference name. This is the name > in your credential in the case of EAP, the name of the host in the URL in > WWW. The client wants to make sure it’s talking to the entity authorized for > that name. > > You can manually preconfigured exactly that entity. In EAP, this is > incredibly easy to do when you’re provisioning the client credential to also > provision the peer identity. This is the existing flow. I agree that they're similar, I'm not sure that they're identical. > This may seem like splitting hairs, but it’s a _profound_ distinction if > you’ve ever managed PKIs on operating systems, as this is not true. Shipping > a CA list in the supplicant shipped in the OS != shipping a CA list in the > OS. They are very different models of managing and configuring that should > not be conflated. Android has plenty of OS components that ship their own > root stores, separate from the root store it provides as part of its public > API contract. We only need the former, not the latter. What matters is that the product the user ends up with has the CAs preconfigured for EAP. The internal corporate structure is (to me) irrelevant. > It sounds like this has circled back into “How do we get > Apple/Microsoft/Google/whomever to have their supplicants trust a set of CAs > by default”, and the steps outlined above continue to be it. For > Google/Android/ChromeOS, I’m not going to want to conflate the TLS PKI and > the EAP PKI if they have different operational considerations (e.g. the ease > of replacement of certs and the ability to respond to CA incidents), > different profile considerations (the information being attested), and > different policy considerations (how that information is validated). The > advocates of such a solution need to do the work in defining the profiles and > policies and presenting that as the use case for why. Sure. > To the OS vendor, managing these profiles and policies is a non-trivial > undertaking involving a host of folks: Legal (for contracts and CP/CPS > review), Engineering, Project/Program Management (it’s a lot of work to > review several thousand CAs a year, let alone the 60-70 organizations in the > root store), Release Management, etc. There has to be a value proposition > here, because the convenient part of the much maligned manual configuration > is that it outsourced all the risk the OS vendor might be taking on, and > instead allows it to be the customer’s problem. That may seem unfair and > non-ideal, but that’s where the risk/value calculus is right now, and to get > vendors to change, you need to present a compelling value case that > demonstrably minimizes risk. Trust is hard and expensive 🤷 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. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
