On Nov 11, 2019, at 6:15 PM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > > This is also related to ongoing anima discussions about RFC 8366, and how it > can bootstrap trust when the pinned domain cert is a public PKI CA, and not a > private CA, and hence additional domain (or realm or FQDN) info is also > needed in order for the peer to verify the identity of the server. > > Its also relevant for ongoing Wi-Fi Alliance DPP discussions about > bootstrapping a supplicant onto an 802.1X network - after a supplicant > completes DPP and gets provisioned with a trust anchor - what if that trust > anchor is a public PKI? It’s the same problem. > > One deployment consideration is if an operator wants to use a public PKI > (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, > before these extensions could be supported (as Alan alludes to), so it would > also be good to define how this could work with standard RFC 6125 DNS-IDs / > RFC 5280 dNSNames.
That sounds reasonable. Certificates for 802.1X authentication already use DNS names. It's not wide-spread, but it's not rare. There's no *meaning* to these names, as nothing checks them. It would be useful to suggest how a supplicant can use these fields to further verify a server certificate. And for servers, what these fields should contain. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
