It seems to me that RFC 4334 offers a way for an enterprise to assert that the certificate is intended to be used with a particular SSID. This seems better than a self-signed certificate with just a domain name.
I understand that CA/B Forum does not allow these extensions and attributes, but as already highlighted in thi discussion, these certificates are not part of the Web PKI. Russ > On Jan 19, 2020, at 10:07 AM, Alan DeKok <[email protected]> wrote: > > On Jan 18, 2020, at 6:30 PM, Ryan Sleevi <[email protected]> wrote: >> Great. Let’s focus on one problem at a time to make sure it’s easier to >> follow along. Earlier in the thread you seemed fixated on the first problem, >> so it’s unclear when/where/how shifted to the second. > > Perhaps less "fixated" than "trying to achieve a common understanding. > > It's best to understand the current situation before designing any solution. > >> The alternative is the application ships it’s own root store. Which >> applications have been doing for 20+ years and which modern OSes make even >> easier. > > 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? > >> Not really? CAs are plenty happy to sell whatever folks want. Look at stuff >> like the drone PKI being developed. > > CAs are in *theory* happy to sell things. In practice, it's difficult to > get non-WWW certificates. > >> I already gave that answer several times. Define your profile and policies, >> pick (different) roots, and ship them in your software. It’s mistaken to >> suggest that you HAVE to use the same roots as the OS. > > 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. > > The goal then is to get to the point where a supplicant can verify that the > server cert is signed by a trusted CA, *and* that it's the server cert that > the client wants. > > Shipping a trusted root CA on the supplicant OS is the *only* way to do this. > >> No, there doesn’t. That’s an unreasonable demand, because it’s insisting >> that advocates of the problem don’t want to actually do the work involved in >> developing a solution for the problem. There’s absolutely no reason to >> require that it be shipped as part of the OS. Plenty of PKIs exist without >> requiring that, and modern OSes make it easier. > > See above. > > This isn't just "ship a root CA with an EAP / RADIUS server". That's a > trivial problem to solve. If you want to use a RADIUS server, it may be OK > to trust the CAs included with that product. The same goes for browsers. > > But what are the poor end users going to do with their EAP supplicants? > Pretty much *zero* of them have ever downloaded a supplicant "application". > So that route is completely off of the table. > > 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. > > 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. > > Alan DeKok. > > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
