The Sovereign Keys Project

But what if the turnover was because of domain-squatting, and the old owner doesn't want to hand over their domain, but they might be legitimately forced to anyway?

Or what if the old owner just stops paying for their domain and disappears, and someone else buys it later but can't authenticate their ownership because the old sovereign key is still around?

I don't know of a good answer to these questions. I'm not sure there is an answer that will still provide the level of security that the EFF wants (which I like).

The fundamental problem seems to be this: we have a bunch of identifiers (domain names in this case) and we want to associate them with people or organizations. How do we verify that identifiers can be transferred to different people or organizations, but only in some "legitimate" way? The only known solution is to have some other entity verify that the identifier->person mapping is legitimate. But this relies on the other entity to be trustworthy, which is what the EFF doesn't like.

A great talk from last DefCon http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Once the 'right' key is pushed into the global cache, you can't fool any users who can access that cache.

Revocation or recovery from the 'right' key itself being compromised or lost is still not really handled, though some ideas are discussed in the draft design. But at least later Certificate Authority compromises can't ruin the security provided by a server's declared long-lived key, once it's been registered in the global cache, as long as the server itself manages its own key well.