On Fri, Jun 8, 2012 at 5:09 AM, Jimmy Hess <mysidia@gmail.com> wrote:
The PKI infrastructure and authority validation components are not required. Even if they were -- anyone can setup a PKI infrastructure, the problem is trust.
We don't need all the 'PKI' crap to do this. We already have SSL/TLS for this purpose. Let's face it. 99% of the sites I use don't actually verify and/or trust who I am. But those sites DO trust that they have my e-mail address (click here to activate) and that I'm using the password I had when I first signed up. So forget all PKI infrastructure. Just establish that I'm the person who originally signed up for the account. Something as simple as an ssh-style key exchange would be perfect. No other information needs to be exchanged. Anonymous users could still be anonymous (sites like slashdot allow 'anonymous' posting--or you could create an account with a certain keypair and then throw that keypair away) and non-anonymous users have a better method of signing in.
This would allow websites to accept user signup without a need to spam the user with additional "Click this link here to prove that this is actually your real e-mail address".
In the grand scheme of things, I don't think this is a huge hassle.
Or an alternate CA that will validate their e-mail address and optionally additional fields, such as a real name. Only fields listed on a certificate need to be verified.
...and now you need checking to figure out which CAs are anonymous or not, combined with the original problem--a single point of failure. One (or a handful) of providers that control access to your identity. Would you switch to a version of SSH that requires signed certificates--even if those certificates were free through cacert.org?
SSH is vulnerable to MITM on the first connection to a new host, you are prompted to save a host key, but noone really verifies this.
That's what the existing PKI infrastructure is for--verifying the site you are connecting to is 'legit'. (The brokenness of that system is an entirely different topic.) Another thing to keep in mind is that SSH can verify key fingerprints automatically too--you can publish them in DNS. Not infallible, but it should be very difficult once DNS is secured. And for sites that don't publish that info (like my podunk home machine) you can prompt the first time to validate the fingerprint. So what. How many geeks bypass the cert warnings in their browser almost out of habit? (Obviously not when going to your bank--but for smaller sites.)
After you've saved a host key, if the host has to change keys for legitimate reasons, such as previous host key compromised, the SSH client refuses to connect, and the user has to manually remove entries from their known_hosts file.
That could be solved by updating the DNS records or prompting the user to update the key. But seriously--what's going to happen if someone does an MitM on me connecting to my bank and doing SSH auth? The bank connection uses TLS. They'd have to forge that. Then I get the home page and I click the 'sshauth' icon in my browser....and it submits what? My username and does some key negotiation? What's the MitM guy going to do? What's he going to steal? He doesn't have my private key--nor the server's.
Username, password is more user-friendly than the SSH behavior, unfortunately. Which means username/password would still be used in preference.
So have the browser 'sshauth' plugin ask for a username and your 'ssh passphrase' but call it a 'password'. Most users wouldn't know or care about the difference.
OpenID requires setting up your own server or using a third party. Most options that exists require setting up your own server or using a third party.
The whole point of my original rant was to remove the ability of website operators to screw up and release your password which you may have used in multiple places. We have a simple system like that called SSH (simple as opposed to SSL/TLS certs) that centralizes everything on the user-side rather than the hundreds or thousands of servers the user uses. -A