On 2019-11-14 7:59 p.m., Alan DeKok wrote: > 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.
I understand. If the authentication server is manually configured, then it matters not in the last what OIDs might be in the certificate. We believe that TEAP-BRSKI (or BRSKI-WIFI) will result in supplicants being configured during an automated process. This would involve getting the organizational root CA, and it could pin the authentication server certificate, or it could pin just a DN, TBD. The OIDs might be be useful that point, but I would generally find them not interesting. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
