On Nov 18, 2019, at 7:39 PM, Dan Harkins <dhark...@lounge.org> wrote: >> What happens if the CA checks some things, and not others? > > Then it means the CA is certifying things it shouldn't.
Well, that's what happens with most CA's. >> Define "validation" :) > > I'll pass on playing that game. We have a good "feel" for what validation means in casual conversation. We're less clear what it means as a *process*. How does a CA validate a field? The answer is too often "it validates the field", which seems a bit circular. My point is that validation isn't black and white. There are various kinds of validation, each of which give you different kinds of information. My goal is to understand what those are, and to find out how we can use that information. Your position seems to be "it's either perfectly validated or perfectly useless". >> 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)? RFC 4334 describes this in some detail. See section 3 for discussion on SSIDs. >> 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) Certificates contain serial numbers. They haven't been validated by a CA. The lack of validation therefore means that you can't infer anything from that field? I would argue that you *can* make inferences from that field. >> 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? This isn't difficult. It means that the certificate owner has claimed he can be reached at that number. And the CA has signed the statement, agreeing that it's a statement made by the certificate owner. >> 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. See RFC 4334 and its discussion of SSIDs. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
