What happens if a domain name changes hands legitimately? Maybe the old owner of the domain would have to sign off on the turnover?
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.
I may be misreading the summaries, but it seems like this is sort of a "bitcoin-like" style protocol, albeit with the history dags being stored centrally, plus additional machinery for all the standard certificate functionality. Am I interpreting this proposal correctly?
It's not really bitcoin-like other than the fact the store is append only. There aren't any DAGs in SK. There aren't really any DAGs in the bitcoin blockchain either (correction: bitcoin transactions - not blocks - do actually form a DAG). There is a tree with a single "correct" path that everyone eventually agrees on (the one which had the most work/computation go into it).
Since sovereign keys are an optional extra layer of protection, it doesn't have to support every configuration. But I think Citibank could just sign all their SSL keys with their sovereign key.
If I understand correctly, this proposal uses a globally-shared append-only log (like the Bitcoin blockchain) as a shared cache of server keys (like SSH's caching of the key first seen with a new endpoint).
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.
From the proposal it doesn't sound like it's even a single log, but that each timeline server has its own log. I'm assuming when you publish your SK you send it to all of the timeline servers. So there will be 10-30 global append-only logs which are then mirrored by lots of SK mirroring servers. So not really like the bitcoin blockchain.
update: From the overview it definitely does sound like a single log, but the draft doesn't seem to specify how entries are submitted, replicated, or kept consistent between the timeline servers. This doc seems to hint at some of that: https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/ti...
They do handle the key-being-comprised problem. When you register you can list third party keys you trust, which can be used to re-register in case of a key being comprised and revoked (by you).
But you're right they don't handle the key being lost problem (make sure you back it up!)
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.