On Nov 20, 2019, at 5:23 AM, Dan Harkins <dhark...@lounge.org> wrote: >> See RFC 4334 and its discussion of SSIDs. > > Is this _my_ certificate that has this attribute in it or is it in a > certificate I receive?
The Introduction of RFC 4334 says: Automated selection of client certificates for use with PPP and IEEE 802.1X is highly desirable. Which seems clear. > If it's my certificate then what is the point of putting it in my certificate? See the text in the document, which explains this in detail. > I am asking for > ambiguous data to be certified and placed in my certificate for my own use? > If this attribute > is in a certificate I receive then what does it mean to "select the correct > certificate for > authentication in a particular WLAN"? The text explains this in detail. I'll summarize. The use-case of the document is that an individual is issued a client certificate. That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store. The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use. Since it's selected a client cert, it can also verify the certificate chain back to the root. I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used. As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify: a) the server cert is intended for EAPoL (and is not just a cert taken from a web server) b) the SSIDs in the cert match the SSID used to authenticate c) the NAIRealm in the cert matches a user identifier stored in the client system In which case the client has *more* information than what is available to it today, and can thus make better decisions about whether or not to accept the cert. > This attribute seems useless to me and its ambiguity and therefore > unverifiability is a > large reason why. I would suggest not using it for your own purposes then. I would also suggest allowing *others* to use it, if they find it useful. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
