On 11/20/19 8:07 AM, Alan DeKok wrote:
On Nov 20, 2019, at 9:58 AM, Dan Harkins <[email protected]> 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.
[snip]
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.
Above you refer to a client checking its own certificate in order to
find an appropriate
one to use for an SSID. And now this is the use case you claim is
ludicrous. EXACTLY!
Asking a CA to certify something that is ambiguous and unverifiable
in order to use it
yourself is ludicrous.
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.
It doesn't make sense because it's too late. You can't use
unverifiable information in a
certificate you have not yet obtained in order to make a network
connection decision. So
this unverifiable and ambiguous nonsense you want to put in a
certificate is for a client
certificate and that use case is, as you note, ludicrous.
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.
I think we have made progress and closure. The use case for
unverifiable and ambiguous
nonsense in a certificate is ludicrous.
Dan.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
