On 11/20/19 4:11 AM, Alan DeKok wrote:
On Nov 20, 2019, at 5:23 AM, Dan Harkins <[email protected]> wrote:
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.
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.
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 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.
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?
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.
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.
Dan.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
