[einhverfr]

> Validating that a digital identity is tied to a specific real world identity is a separate problem.

But it isn't for the main areas of SSL usage (e-commerce, ensuring your passwords are sent to the right party, etc). Those require trust. I don't know how you get around that.

I.e. I can imagine the concern being that X.509 ties together validating identity with public key infrastructure but since one use of a public key is to validate identity I am not convinced that is a bad thing, and to be honest, I can't see a trustless alternative for most of the current uses.

I can imagine many better alternatives to X.509 (anything that starts with a letter . three digit number is OSI legacy crap), but I don't see how to get rid of the identity vouching aspect of it.

[vertex-four]

As a general rule, people care that their connection is secure, because they've been told to worry about people stealing their card numbers on insecure sites. They've generally established trust in other ways - more commonly, they simply trust it because they've heard about it elsewhere or it ranks highly on Google, and they use a trusted payment provider such as Paypal.

Most people honestly don't go to the effort of verifying that a certificate matches the real-world identity they think it does. It's difficult, especially with smaller stores that don't use EV certificates.

For cases where people think third-party attestation is a necessary thing for their purposes, frankly, we have nothing better than the CA model right now; but that can easily be integrated with Namecoin, allowing for only those who need it to use it, and the rest to have access to secure communications and proofs of digital identity without having to pay up.