jcase
The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries.
I'm putting my eggs on certificate pinning.
[0] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...
If someone wanted to be a dick about it they could release modified GPL code as one big diff and publish it on some obscure webpage only their customers have access to. Instead we see more and more companies and individuals becoming friendly open source citizens. Perhaps some because the GPL mandates it but I would like to think mainly because they feel it's right thing to do—copyleft or not.
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...
Ideally OS/Browser vendors would drop compromised CAs. That happened with DigiNotar. It's not always an option though — the three largest CAs have a 83.97%[0] market share. Dropping any one of them breaks the internet.
Unfortunately a lot of people seem hell bent on destroying rather than improving on top of it.
For what it's worth, many CA's are trying to raise the bar by way of the CA/Browser Forum.[1] The public mailing list is quite interesting at times.
[0] https://en.wikipedia.org/wiki/Convergence_(SSL)#Background
[1] https://blog.heroku.com/archives/2013/4/24/europe-region (near the bottom).
Fun (semi-fictional) read about Electronic Funds Transfer, crypto and the FBI.
AWS CloudHSM: Secure Key Storage and Cryptographic Operations
The source provides a hint:
/* Schneier specifies a maximum key length of 56 bytes.
* This ensures that every key bit affects every cipher
* bit. However, the subkeys can hold up to 72 bytes.
* Warning: For normal blowfish encryption only 56 bytes
* of the key affect all cipherbits.
*/
[1] http://bcrypt.sourceforge.net/[2] http://security.stackexchange.com/questions/21524/bcrypts-72...
The issue is that it doesn't solve anything. We merely shift (more) responsibility to registrars and NICs. You can change (untrust) registrars I suppose but if you have a .com you'll have to trust Verisign _forever_. Well, at least as long as they operate the .com tld. So if Verisign loses your trust, there is even less you can do than today.
Your experience running a homebrew setup is exactly why I think CAs will continue to exist—even if self-signed certs would be widely supported via DANE. I doubt many businesses are going to run their own CA in order to save < $1000 a year.
Because business model. StartSSL.com is afaik the first (only?) CA that charges solely for identity validation and then let's you create unlimited (wildcard) certificates (with the exception of EV certs).
* No ties, just a customer.
* Convergence.io
* DNS-based Authentication of Named Entities (DANE) + DNSSEC
* Tack.io
For various reasons listed in [1] Convergence is not likely to be implemented (by default) in major browsers.
On DANE + DNSSEC, where the cert is authenticated via the information published in your DNS, Moxie Marlinspike has said it better then I can:
"CAs are sketchy, but this is a whole new world of sketchiness. Think,
sketchasaurus. Registrars were never built or selected with security in mind,
and most of them don’t have a very good track record in this area. Shouldn’t it
be laughable that the current first step in deploying DNSSEC is to create an
account with GoDaddy?"[2]
The 2011 BlackHat video[3] and blog post[2] by Moxie Marlinspike are great sources of information.IMO, Tack.io is the most viable solution. It's compatible with the current model but removes the thread of one CA being able to compromise all domains.
[1] http://www.imperialviolet.org/2011/09/07/convergence.html
[2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...