

The Sovereign Keys Project - adulau
https://www.eff.org/sovereign-keys

======
noahl
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.

------
alecco
How does this solution deal with the "Citibank problem"? (a website with a
huge number of SSL keys from multiple certificate authorities)

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

~~~
wmf
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.

------
carterschonwald
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?

~~~
coderrr
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).

------
gojomo
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.

~~~
coderrr
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...](https://git.eff.org/?p=sovereign-
keys.git;a=blob;f=issues/timing-corner-
cases.txt;h=ff2bd76b271aacc10b40e77596fba50ece07b70a;hb=HEAD#l71)

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!)

