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