Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Dan Harkins <[e-mail]>]

On 11/20/19 8:07 AM, Alan DeKok wrote:
> On Nov 20, 2019, at 9:58 AM, Dan Harkins <[e-mail]> 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.