On Nov 13, 2019, at 6:23 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > I think that the issue isn't, can we find or define a OID that has the > right semantics. > I think that the issue whether or not any public CAs are willing to > include that into a certificate.
That's less relevant than it may be. The common practice for years has been to recommend self-signed or "internal" CAs. The original reason was that supplicants didn't do certificate pinning. So if they were configured to trust a root CA, they would send user credentials to *any* EAP authentication server which had a certificate signed by that CA. With certificate pinning, they now warn if the server certificate changes. The other reason is that supplicant configuration is still largely a manual process. If admins need a complex process to configure the supplicant, then adding a self-signed CA to the mix has near-zero cost. And supplicant vendors seem entirely disinterested in a standard way to configure them. The other benefit of self-signed CAs is that they're free. No verification is required. Since the admin controls both the CA and the end user machine, he's free to do whatever he wants, when he wants. As to why self-signed CAs are appealing, here's an example. I've had "interesting" times trying to renew a simple certificate for HTTPS usage. The CA was happy to take my money and "verify" ownership of a domain. But they were entirely uninterested in sending me an actual certificate. Their support system was similarly unhelpful. In the end, I went with a simpler approach. And I can't be the only person that this happened too. The gating issue for me is supplicants. It's easy to update Open Source supplicants to check new OIDs. The larger vendors might upgrade. Eventually. Maybe. On a technical front, a major issue is also *how* to upgrade. What do supplicants do? Allow both OIDs? When do they start rejecting certificates with the "TLS web server" OIDs? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
