Comment Ssl should be tied to dns (Score 1) 243
Why not simply make SSL recursive and tied to DNS?
The root servers sign the root certificates for TLD CAs. These sign a domain-limited CAs when one registers their domain. And organizations can sign everything within their domain (and make that as complex or simple as they need).
So SSL is effectively free, apart from some minor administrative costs. It's unique (the current DNS system already has the rules and procedures in place to make sure a name is unique and can't be trivially transferred to another party). And you don't really put your trust into anything you didn't effectively trust in some way before.
To make this manageable you probably want some additional intermittent CAs (the signing CA and the one which is safely tukked away in some vault somewhere). So a simple verification for 'update.microsoft.com' would be something like:
root server extra secure CA (for signing TLDS) ->
trusts working root server CA (for signing TLDS) ->
trusts
trusts
trusts
trusts
trusts update.microsoft.com server certificate
Much of these validations can be cached. Any changes can result in warnings (kind of like SSH connections to a machine for which the key has changed) which can be prevented if their is also a double signature from the previous CA certificate for that level (though the extra signature is only sensible if the path from the root is already deemed to be correct, it's just to make it painless for CAs to have a pretty short lifetime and to transparently reissue a replacement).
Adding these warnings also prevents simple takeovers even if some part of the chain is temporarily compromised (only for certain types of compromisings) or if someone pressured a party to issue it a conflicting certificate. So secure parts that we've already been in contact with before will be almost impossible to redirect without some warning.
Warnings themselves would probably be pretty significant since self-signing is effectively a thing of the past for anybody who has an officially registered domain. And the amount of root CAs to keep updated is also very manageable.
Furthermore because of all the intermediate CAs (especially in the top of the hierarchy) that should be the same for most people on the internet, one can easily add some kind of external validation system like 'perspectives' (or a more mash like system) to monitor what others perceive these to be.
Sure it wouldn't be watertight, but at least it's tied to something that's uniquely identifiable and which is often transmitted out-of-band (I don't have to search for my bank on the internet, I know what their official domain is! and for stuff I didn't know what their domain is I probably don't even know if it's their official domain and no amount of signing legalize or technology will fix that).
So if we could just make trust recursive and implicit with domain registrations (which shouldn't warrant any big price changes for it it mostly an administrative issue, which anything related to dns already is). Than we have the basics for trust system that normal humans can comprehend.
And by all means let the current SSL companies do what they have been really doing all these years. Which effectively has nothing to do with SSL and which is a poor excuse for "authentication" (what good is authentication when "identification" is a much bigger problem in real life (if you know a "Jan Jansen" than it's probably another person than the "Jan Jansen" I know, which equally translates to some company in your village/country and some company with the same name in another village/country. So if you don't know exactly who it is you're supposed to be talking to it doesn't really matter that they have the papers to show that they are who they say they are). No, let those companies just sell insurances, for that's really what you're buying. That and a whole lot of air.
