Sovereign Keys for certificate verification

> but in other ways to most end users it may sound like replacing one remote authority with another

Possibly you could say we are replacing one central authority with another that has an open, forced audit trail. I guess this is supposed to make it faster to find out when the system has been compromised, and makes identifying the compromise easier. However the current compromises were discovered pretty quickly, and there were no problem identifying whose lack security was responsible, and appropriate action was taken fairly quickly to ensure they didn't do it again.

It's not a huge gain, and the costs are substantial: this proposal needs a large, always online, coordinated set of servers which the client must interact with. If I put myself in Iran shoes, my first step would be to block those servers. Then what? Are the users denied an encrypted connection completely, or do they use a possibly compromised cert?

That aside, the design of the current PKI system and its proposed replacements seems a little crazy to me. The PKI system is needed because there no way for two people who don't know each other (eg you and this cool shop you just found in some forum) to set up a secure encrypted connection that isn't vulnerable to a man in the middle attack. To do that you need a third party trusted by both you and the shop. That trusted third party is the PKI system. However once you and the shop have set up a secure connection you are no longer unknown to each other. You could for example exchange a cert for all future communications, and thus no longer need to trust the PKI system to set up secure communications. Yet the current system does ask us to trust the PKI system each and every time we connect to the HTTPS server, insisting we have a third party involved in every transaction. Having to reply on this third party weakens the system considerably, and since there is no real need to have that third party around after the initial contact, from a security point of view this is crazy. This craziness is the real reason the Iran hack far more devastating than it should of been.

Government sponsored attacked on the PKI system aside, right now the number 1 phishing exploit is to send an email with a URL pretending to be www.bank.com, where they are in fact www.hackme.com. We all know of course that no one should ever click on a URL in an email. Well everyone except PayPal it seems, who urged me to click on a URL they in the message they sent me. (The point being if PayPal doesn't get it, how on earth can we expect job blow at home to get it?) Preventing these phishing attacks would be a major step in enhancing Internet security. And guess what - we probably can reduce them, with a bit of client side and server side magic.

All you have to do is bundle up a set of certs into a, err, well lets call it a signin bookmark. The initial connection is set up using PKI as now, but the only thing that is used for is to get the user to identify themselves using some credentials, and then sending the signin bookmark to the users browser, which stores it. The browser than lets the user to click on the signin bookmark, which invokes a procedure that signs the user into the web site, as the name implies. Thus it contains a URL just like a normal bookmark. However it also does authentication, so it contains a cert identifying the user, and it contains a cert identifying the server. The certs mean the user never has to use the PKI system again to get a secure connection to site, thus the Iraq CA hack is rendered almost impotent. This is pretty simple, well understood stuff - ssh already does it.

The magic sauce is the site knows whether the user accessed it via the signin bookmark as opposed to just typing in a URL. If they use a random URL they get told they are naughty. If it is a bank or something, the site might make them jump through a few hoops to get a new sigin bookmark - like going into a branch or phoning a human. Thus we get to train the users to never click on random URL's. Even better, since we can safely put a pointer to the signin bookmark in an email, we can now put put clicky things in email's that take you to the site, and are safe.

PKI in this system just gets reduced to a transport for that initial contact. It could be replaced, and in some cases probably should be. For example a bank might insist on sending you your signin bookmark on a USB key, which arrives via post. In fact am puzzled why banks seem happy to put their faith in a PKI system that regularly gets man in the middled by governments, schools and McDonald’s.

This has been a long winded way of saying I think all these new proposals for replacing the current PKI system with a new stronger PKI system that nonetheless works in much the same way are on the wrong track entirely. We are tinkering at the edges. We need to replace the entire HTML authentication with something far stronger, and while we are at it we should take the opportunity to get rid of the firesheep hole as well. Setting up authenticated, unencrypted connections is not exactly rocket science. IPSEC has no trouble doing it.