Kudos to the author for pointing out that the SSL PKI infrastructure is a terrible model in _practice_. In _theory_, it may be otherwise, but that does nothing for the user.
Usage of the internet will always require trust. But the idea of a mandatory "chain of trust" system to which _every_[1] computer user on the internet must submit is neither realistic nor reasonable, IMO. Nerds might be comfortable with these mechanisms, but nerds know how the mechanisms work. Most users do not.
1. Certificates might still be a great fit for _internal use_ within an organization.
The idea of "chain of trust" is fine in theory. In the real world, you see it everywhere. People trust middlemen all the time. From movie reviews to background checks. We routinely build trust of a certain person indirectly through others.
But I think people are good enough at building their own systems of trust. And they may not all follow the same steps to arrive at trust. Maybe they prefer one middleman in the chain, or maybe they don't mind several of them, or maybe they prefer to cut out the middlemen and go directly to the source. And maybe they don't agree on the same middlemen. IMO, no one should be forced into using a system where they must accept a predermined chain of "trustworthy" parties, whether in the real world or in the world of computers.
For some reason (maybe because OpenSSL is a mix of too many things at once?), people seem to have a difficult time getting their head around the SSL PKI system. "Certificates" are anything but user friendly (even if you are technically minded). Collecting them, verifiying them, generating them, installing them. None is easily understood. Not to mention protecting certificates from theft. (I'll bet the NSA's collection of stolen private certificates is a beauty.)
You can't even _compile_ OpenSSL without Perl. What does that suggest about the authors' threshhold for complexity? Maybe nothing. But to me it signals that simplification is not a top priority. OpenSSL is a complex conglomeration of software from disparate sources; considering the trust we place in it, maybe that's relevant. Anyway...
Contrast the hassle of certificates with the concept of authentication in SSH, specifically the "known_hosts" file. Not perfect, but much simpler, IMO. You keep a unique string of characters called a "host key" in a file on your computer. When someone wants to connect to your computer, they can verify it's really your computer by checking the computer on the other end for the presence of that unique string. If it's there, they know it's you.
Bob met Alice and gave her a card with her host key printed on it. Bob goes home and copies Alice's host key into his "known_hosts" file. If she runs an SSH daemon, Bob can now use an SSH client to identify Alice's computer on a network.
We might call this "SSH authentication."
SSH allows the use of SSL style certifcates as well. But my understanding is they are rarely used. My guess is because to the users, they're not needed: SSH authenication is good enough for users.
The concept is sufficiently simple and the system is sufficiently manageable in practice. IMO.
What about if the UX of the Root Certificates management gets betters? In OSX keychain you can just click on e.g. the DoD CA root certificates and permanently un-trust them globally.
We need an easy and good UX for every new thing, so why not improve the usability of the existing X.509 world instead of re-inventing the wheel?
Eg. S/MIME support in recent versions of Mail.app and iOS mail got really nice. There is improvement, it's currently just enterprise-driven.
We need to talk to the industry leaders like Google and Mozilla to fix their horrible X.509 browser experience and make this thing available/usable to/for consumers, too.
If users can't configure their Facebook privacy settings I'm not too optimistic about their ability to manage root certificate trust bits. It's a good start though.
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.
Usage of the internet will always require trust. But the idea of a mandatory "chain of trust" system to which _every_[1] computer user on the internet must submit is neither realistic nor reasonable, IMO. Nerds might be comfortable with these mechanisms, but nerds know how the mechanisms work. Most users do not.
1. Certificates might still be a great fit for _internal use_ within an organization.
The idea of "chain of trust" is fine in theory. In the real world, you see it everywhere. People trust middlemen all the time. From movie reviews to background checks. We routinely build trust of a certain person indirectly through others.
But I think people are good enough at building their own systems of trust. And they may not all follow the same steps to arrive at trust. Maybe they prefer one middleman in the chain, or maybe they don't mind several of them, or maybe they prefer to cut out the middlemen and go directly to the source. And maybe they don't agree on the same middlemen. IMO, no one should be forced into using a system where they must accept a predermined chain of "trustworthy" parties, whether in the real world or in the world of computers.
For some reason (maybe because OpenSSL is a mix of too many things at once?), people seem to have a difficult time getting their head around the SSL PKI system. "Certificates" are anything but user friendly (even if you are technically minded). Collecting them, verifiying them, generating them, installing them. None is easily understood. Not to mention protecting certificates from theft. (I'll bet the NSA's collection of stolen private certificates is a beauty.)
You can't even _compile_ OpenSSL without Perl. What does that suggest about the authors' threshhold for complexity? Maybe nothing. But to me it signals that simplification is not a top priority. OpenSSL is a complex conglomeration of software from disparate sources; considering the trust we place in it, maybe that's relevant. Anyway...
Contrast the hassle of certificates with the concept of authentication in SSH, specifically the "known_hosts" file. Not perfect, but much simpler, IMO. You keep a unique string of characters called a "host key" in a file on your computer. When someone wants to connect to your computer, they can verify it's really your computer by checking the computer on the other end for the presence of that unique string. If it's there, they know it's you.
Bob met Alice and gave her a card with her host key printed on it. Bob goes home and copies Alice's host key into his "known_hosts" file. If she runs an SSH daemon, Bob can now use an SSH client to identify Alice's computer on a network.
We might call this "SSH authentication."
SSH allows the use of SSL style certifcates as well. But my understanding is they are rarely used. My guess is because to the users, they're not needed: SSH authenication is good enough for users.
The concept is sufficiently simple and the system is sufficiently manageable in practice. IMO.