> There should have been two separate mechanisms for encryption > and identity verification in the first place; it's silly to lump the > two together as one mechanism.
Encryption is entirely useless if you can't confirm the identity of the other party, because it is subject to man-in-the-middle attacks. In other words, I could open an encrypted link to someone who claims to be ibm.com, and if I don't have any way to confirm that they really are authorized representatives of IBM, the encryption is NOT going to prevent my data from getting into the wrong hands. The point of the X.509 certificate is to give me trusted third parties that can provide information to confirm that the web site is really operated or authorized by the party that owns the domain. The trusted third parties are the certificate authority, and the browser vendor who put the root cert for that CA into their browser. (Sophisticated users might choose what root certs to use, but the average user does not.) However, contrary to what some have claimed here, all I expect out of the certificate is proof that the server that handles IP traffic for the domain name "www.ibm.com" is being operated by (or at least with the authorization of) the party that is responsibile for the ibm.com domain. Whether the party that is responsible for the ibm.com domain is the legal entity owning the IBM trademark or doing business as International Business Machines is an entirely separate issue, and I don't expect SSL certificates to solve that problem. Therefore I find it perfectly acceptable for the authentication requirements to obtain a certificate to be no more strict than those to obtain or transfer a domain name. Eric
