On 11/18/19 3:42 PM, Alan DeKok wrote:
On Nov 18, 2019, at 6:22 PM, Dan Harkins <dhark...@lounge.org> wrote:
On 11/12/19 3:40 PM, Alan DeKok wrote:
On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) <t...@hpe.com> 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.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
