On Nov 20, 2019, at 9:58 AM, Dan Harkins <dhark...@lounge.org> wrote: >> 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. > > So you asked for imprecise, ambiguous, and unverified information to be put > in your own certificate for you to use later. Just because something is in an > RFC doesn't make it right. And appeal to RFC is another form of appeal to > authority fallacy.
You asked how it worked. I pointed you to the RFC. You now claim I *can't* refer to the RFC, because it's an appeal to authority. To recap: appeals to authority are logical fallacies where someone says "I'm right because of this authority". I'm not saying that. I'm saying that some people find it *useful*. I'm pointing to the RFC as evidence that people find it useful. I'm pointing to the RFC as an explanation of how it works. I think some of this back and forth could have been avoided with a careful reading of the RFC. > Oh, and what's the point of verifying the chain of your own certificate > prior > to connecting to a network? Do you do OCSP responses to see if your > certificate > has been revoked? I had hoped my explanation was unclear. I guess not. The point was that when a client connects, it can check the *server* certificate chain back to the *same* CA which was used to issue the client cert. I've never seen a client check it's own certificate chain during authentication. Such a use-case would be ludicrous, which makes me wonder why you think that's what I was proposing. >> 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: > > Yea, and that's why I gave you the list of actions a client takes and asked > you to point out where in the list this happens. You deleted the list. Yes. Because I gave an explanation of how it works. I want to be sure that the explanation is understood before going into further details. If my explanation makes no sense, then there's no point in me discussing technical details. >> 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. > > If the information is ambiguous and unverified why would you use it in a > decision > to accept a certificate or not? Well we're going in circles. I've given explanations. You reject them whole-sale, and keep asking me for more explanations. > I'm not proposing to prevent you from doing anything. I'm asking what's the > point > and why. You didn't really provide one. And good luck getting a public CA to > put > ambiguous and unverifiable information in a certificate for you. I've already addressed these points. Please see my previous messages. I think this horse has been beaten to death. I don't see any point in continuing it, unless there is progress. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
