

Sovereign Keys, EFF's proposal to replace the certificate authority model - xyzzyrz
https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure

======
feralchimp
This is clever, and I think it relates in a neat way to the current TLS trust
imbalance between browsers and native clients.

When I write a native client app against my own server, I don't need to rely
on traditional appeals to CA trust because I know exactly what certificate the
server should be presenting to me.

TLS is weaker in browsers because arbitrary web clients don't know my server
ahead of time, so they trust me if one of the Super Trustworthy Oracles trusts
me. But the list of those CAs is large enough, and updated slow enough, that
the list is not particularly trustworthy in aggregate even when any individual
CA may be considered trustworthy at a particular point in time. So there's an
issue there, even with a savvy user class who would reject access in response
to a certificate warning.

The Sovereign Keys proposal strikes me as a way to let browsers 'phone a
friend' who, in essence, knows exactly what certificate the server should be
presenting. It makes an arbitrary client more like my native client.

But I think there's a scalability concern about Sovereign Keys that's related
to the problems we see with CAs today: When they become a popular commodity,
how will the system deal with millions of websites asking for Sovereign Keys?
Will it really take the time to verify that the requestors are valid, or will
it try to 'meet the demand' and sacrifice security in the process? And when
the system is fooled, as it occasionally will be, how quickly will revocations
or replacements be operational?

~~~
sirclueless
I don't think the scalability is as much of an issue as you think. The current
system allows a trusted CA (or untrusted if you are OK with warnings) to issue
a cert to a malicious party for, say, facebook.com. This means that in
aggregate it is difficult to trust the reliability of a cert that a browser
receives.

The strength of the Sovereign Key is that once facebook.com issues a Sovereign
Key, no one can possibly produce a key that is valid for facebook.com unless
facebook.com revokes its key, which is a cryptographically secure process that
only facebook.com can perform using its private key.

This largely alleviates the problem you describe. One can be relatively lax in
distributing new sovereign keys, because there is no way to attack an existing
one by granting another. One still has to be a little careful in granting them
because a site without a sovereign key might be attacked by creating one in
its name controlled by a malicious third party, but it's not as dangerous as
the current system where granting an overly broad certificate to Joe Schmo can
compromise google.com's SSL.

~~~
ajasmin
What would happen if a sovereign key for facebook.com was granted to a
malicious party before Facebook gets the chance to request one? Can such an
error ever be corrected?

~~~
feralchimp
This is exactly my concern, only less for facebook and more for the multitudes
of less-famous sites that nevertheless transact a lot of business.

------
lifty
There is already quite a bit of work done regarding using DNSSEC as a PKI for
distributing keys(any kind). One relevant paper is
<http://www.acsac.org/2005/papers/49.pdf>.

The nice part about storing public keys in DNS and authenticate them using the
trust chain starting from the DNS root servers, is that you have a solid
foundation that can be used for all kinds of interesting applications, much
more than just encrypting traffic between the webserver and the client. As an
example, we had a project where we stored a public key in the txt field of a
domain name(signed), and we would sign all HTTP responses with that key. The
client could then get the public key via DNSSEC and verify the signature of
the HTTP response. The advantage over SSL is that you get authenticity and
integrity for each HTTP response.
[http://tnc2010.terena.org/schedule/posters/pdf/100511170332n...](http://tnc2010.terena.org/schedule/posters/pdf/100511170332niek_tnc2010_poster.pdf)

The proposal from EFF also leverages DNSSEC as a trust source, which I think
is better than the current PKI that we are using, but its not without its
flaws. The biggest problem is that you are still dependent of a 3rd
party(registrar) to give you that trust, and usually these kind of entities
are very prone to being influenced by governments. We can see what kind of
legislation some governments are trying to promote, so I'm not sure if a
centralized solution is the best way we can go :)

~~~
pyre

      > usually these kind of entities are very prone to
      > being influenced by governments
    

A lot of registrars are down-right shady _without_ getting governments
involved...

------
cpeterso
In related news, Google has said they do not plan to implement Convergence, a
similar SSL alternative:

[http://www.theregister.co.uk/2011/09/08/google_chrome_reject...](http://www.theregister.co.uk/2011/09/08/google_chrome_rejects_convergence/)

------
billybob
"The main requirement for being able to [create a Sovereign Key] is that the
requesting party controls a CA-signed certificate for the relevant domain, or
uses a DNSSEC-signed key to show that they control that domain".

I don't quite understand this. If our problem is that CA-signed certificates
are not very trustworthy, why use them as the basis for the new system?

Can someone explain the DNSSEC alternative?

------
ryanwaggoner
My first thought when I saw the word "sovereign" was that this was a plan
advocating making nation-states the ultimate certificate authority or
something.

Now that I see this is just the opposite, the terror of that moment has
passed.

------
ajasmin
How does that compare to bitcoin? The distributed append-only data structure
sounds like it is similar to the bitcoin block chain.

But the article says this structure is "semi-centralized". Is there a good
reason why the sovereign key system isn't fully distributed like bitcon is?

