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

[Dan Harkins <[e-mail]>]

On 11/18/19 3:42 PM, Alan DeKok wrote:
> On Nov 18, 2019, at 6:22 PM, Dan Harkins <[e-mail]> wrote:
>> On 11/12/19 3:40 PM, Alan DeKok wrote:
>>> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) <[e-mail]> wrote:
>>>> How does a public CA prove ownership of an SSID?
>>>    Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates?
>>>
>>>    Do public CAs verify that email addresses in the certificate work?
>>>
>>>    Do public CAs verify that the OIDs in the certificate match the intended use-cases?
>>>
>>>    Is there a global registry of SSIDs which the public CA could use to verify the SSID?
>>    I'm taking these as rhetorical questions with an implied "no". If that is
>> not the correct way of taking them then please let me know.
>    The implication is that many of them are "no".  Some are "yes".  Some *should* be "yes", and are in practice often "no".
>
>>    So the issue is, if the CA does not check any of these things then you cannot
>> trust them in the certificate.
>    What happens if the CA checks some things, and not others?

   Then it means the CA is certifying things it shouldn't.

>> The reason you trust the contents of a certificate
>> is because you trust the CA has done the appropriate due diligence to validate
>> the stuff it is certifying. If a CA doesn't do the due diligence on any of the
>> above stuff and still issues a certificate containing that stuff then I would
>> question the integrity of the CA and probably not trust other things it is
>> certifying. In other words, I'd probably remove that CA's cert from my TADB.
>    That's up to you.

   Let me put it another way. There is no reason to trust a CA that does 
not perform
due diligence on the things it certifies. Convince me otherwise.

>>>    To put it another way, I'm not sure why this question is being posed.
>>    Here's one: Why would you trust an attribute that was not validated?
>    Define "validation" :)

   I'll pass on playing that game.

>    If the certificate contains an NAIRealm OID, then I know how the CA should validate it: check that the realm matches the domain.
>
>    For SSIDs, since there's no registry, it's not possible to "validate" it against a registry.  So "validation" here means... what, exactly?
>
>    My point for SSIDs is that validation means whatever we define it to mean.  So long as everyone agrees that the SSID field is a hint and is not validated by the CA, it's OK to use it.

   Use it how? What value do you put in an attribute that hasn't been 
validated (and
don't ask me what that word means since you used it)?


>    In addition, CAs currently validate *control* of a domain.  But they don't (and can't) really validate *ownership* as such.  i.e. if I own a company, I can tell an employee to ask a CA for certificates for that domain.  He may be making that request, even if he doesn't "own" the domain.  He can convince the CA that he controls the domain.  I'm not sure how the CA would check that the owner of the domain has properly delegated the certificate request to the employee.

   Then what you can infer from a domain name in a certificate issued by 
such a CA
is that the holder of the corresponding private key controls that 
domain. Nothing
more, nothing less. But you can't infer anything from other attributes 
that have not
been validated (again, using a word you used yourself)

>    The same applies for telephone numbers.  Do CAs call the numbers?  Do they check that the person answering is the same person who made the request?  Maybe.

   You tell me if a CA "calls the numbers". If it doesn't then what can 
you infer
from a telephone number in a certificate it signs?


>    These issues can't be answered with simple black & white statements.  If the data in a certificate is imperfect, it might still be useful.

   OK, convince me of its utility.

   Dan.