I think we’re in more agreement than disagreement here, but I think part of your analysis missed the mark.
On Sun, Jan 19, 2020 at 10:07 AM Alan DeKok <[email protected]> wrote: > The question here is *what* root store? It's easy for browsers to ship > root stores. The WWW root stores are well known. > > What root store is already widely known, and trusted for EAP? There isn’t one today, which is exactly why you have no need to use anything existing. You define your certificate profile. You define your certificate policies - what information they validate and how they validate. The root store is the result of defining those two, and then allowing CAs interested in that set to apply and be evaluated against that. There’s nothing extant, as we’ve agreed multiple times, because everyone manually configures. There’s zero need to use any existing CAs. If the concern is “Our root store is initially empty”, well then yes, it matches the status quo today: there is no root store. Rome wasn’t built in a day, and figuring out who should be in that store takes time. There’s no doubt a dozen CAs that would happily issue, if they knew what the expected profile and policies were, and would stand up dedicated roots. 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. Supplicant vendors - whether they are open-source or operating system - are taking on the work to manage and police that root store. To ensure that the CAs included follow the profiles, policies, and practices. So you have to convince them that it’s worthwhile for their users. If this sounds like a lot of work: Yes. It is. Yet organizations like the WiFi Alliance or the Wireless Power Consortium or the USB-IF have all managed to do so, to varying degrees of success. I think you're operating from a WWW perspective. That use-case is very > different from EAP. In WWW, 99% of the TLS-enabled traffic is from the > server to the client. The client doesn't know what the information is, and > doesn't really care. Even secret information like passwords sent to a web > server are generated by / on that web server. So a client can verify (a) > the password was created for a proven server using a trusted CA, and next > time (b) prove it's the same server, so it's OK to send over the password.. > > EAP is completely different. I have *my* password. It's secret, and I > made it. I want to be sure that I give it *only* to the site which is > authorized. This means that I don't really care that a root CA is > trusted. That root CA might sign certificates for 1000 companies. I want > to have my password only to one company; the correct one. I want the > client supplicant to *not* hand my password to the other ones. I have no > DNS to leverage, either. > > To put it another way, in WWW, the server has data that the client > wants. In EAP, the client has data (passwords) that the server wants. The > trust models are very different. 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. The long-term goal seems to be to want to indirect that, so that explicitly provisioning credentials is not necessary. In that model, you need a third-party, the CA, to vet and validate the identity, so your EAP server can attest it. Rather than having to rely on a preconfigured identity, you want to make sure the reference name matches the names presented in the certificate. The trust model is _identical_ to WWW, as you describe it. If the argument is that the only information that needs validation is a DNS name, and that it’s profile is similar to, or could be identical to, TLS, then you still have the burden of demonstrating the operational considerations are the same before you make the case to reuse the existing. For example, the payment terminal example I mentioned used the same policies and profiles, but the operational consideration was these devices are not field upgradable and only support certificates from a limited number of CAs. The lack of updates and the lack of agility were an insurmountable gulf of difference from the constraints of operating systems (patches) and browsers (regular updates), and so these devices need separate PKIs, which ANSI X-9 is happy to oblige: https://x9.org/asc-x9-launches-new-security-study-groups-on-public-key-infrastructure-pki-and-transport-layer-security-tls/ If this future world is a world where the provisioning of certificates is only done via ACME, and manual configuration is “unsupported” (even if technically capable, it’s in the “may break you at any time if you decide to do this” level of support), and your profiles are explicitly short-lives to help ensure this, then yes, it’s reasonable to talk about overlap. > Shipping a trusted root CA on the supplicant OS is the *only* way to do > this. This is not true. Shipping the trusted root CA list in the supplicant _software_ totally works. Conflating the supplicant with the OS is continuing to muddy the waters. Instead the supplicant is shipped with the OS. Therefore, any root CAs > needed by the supplicant MUST be included with the OS. > > It really is that simple. 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. 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. 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 🤷 In conclusion, we need a new PKI, and the root CAs must be included with > OS distributions. But the OS vendors won't do that until we define the > requirements, solution, and transition path. The transition path has been repeatedly defined, so that’s 1/3 of the way there 👍
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
