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

[Dan Harkins <[e-mail]>]

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