A good way to check if does the right thing is to make sure it does not depend on the security of DNS. Is this the case? (I'm still trying to find out.)
From that document:
"destination.com retrieves Alice's public key from mailhost.com by using a webfinger lookup over SSL."
So it looks to me that the system's security depends on the attacker not having compromised DNS such that the relying party's query of mailhost.com is intercepted. Depending on the implementation doing this "over SSL" provides some additional security over unchecked reliance on DNS, but given how frequently keys roll, it may not be that much in practice.
Apparently, it does not do what I hoped it would. Assertions are about ownership of an email address, not about control of the private part of a key pair.
Yeah, even using them over at GitHub (well, pushing with Git over SSH in general) has proven to be a rather steep learning curve for a lot of people. But hey, it's being widely adopted there, so that's a step in the right direction for this.
Something like this already exists. Your browser can already identify itself with a certificate.
The interface is ugly and cumbersome for the non-technical (even in Firefox) and I don't think it's used very often, but I know that MIT issues certificates to students which identify them to all MIT's web applications, as well as third parties like the Apple and Dell student discount pages.
Dartmouth does this as well, and I agree the interface sucks in browsers. Especially since most browsers will gladly show expired certificates for you to choose so you have to manually prune your list.
Email addresses are typically controlled by a third party, so it doesn't make much sense to me that they should be equated with identity. Would you equate your identity with your IRL work address?
On the other hand, private keys are held only by the person whose identity they represent. They are a better way to represent identity because they do not rely on third parties.
They don't equate with identity but give a way of communicating with the user using a different channel. In a world of passwords this allows that password to be reset.
It's discontinued though unfortunately. Although there are still people out there making it work with newer versions of Firefox: https://grepular.com/FireGPG_on_Firefox_5
Will you and the website owner each verify the key fingerprints? What I'm getting at is it's a hard problem to solve, because users want it to be quick and easy. But that often works against the stated goal of security.
I don't see why the website would need to verify my key fingerprint. Verification is needed when you care who a key comes from. For typical websites, they don't need to know who I am. They only need to know enough to recognize on subsequent logins that I'm the same person who provided the key at account creation, and the key itself has all they need for that.
I just don't get it. I've seen it in HN comments for a few days now, but I fail to understand how 'this.' relates any new information. Reply indenting already tells me you are referring to an antecedent post. (A specific post in fact.)
Am I missing something, or is this just a new web fad I'm not savvy too? (Second option is not entirely unlikely...)
That's essentially what this is... with a verification service and web based UI to help bootstrap it.