Alternative to "web of trust"

Question

Let's say I have an SMIME platform where I want to easily establish trust across the entire world for a particular purpose, for example for sharing valid financial information. I think that a distributed trust environment is best because I don't want to dictate communities's certificate policies and practices and I especially don't want to be involved in the CA / RA process. This means that little communities can evolve and create their own practices. But this process hasn't even started yet, how do I facilitate this trust model?

Here are some options that I can think of:

1) One option would be to create a list of valid communities and have a link to their anchor certificate.

2) Another would be to create an anchor myself and I only allow valid and trustworthy communities to create anchors created off of my own anchor. But that's a lot of work and I'd prefer not to do that.

3) Another option is the PGP web of trust model where I try to cross-certify trustworthy anchors. But again, that's a lot of work and per wikipedia, that model never actually took off: http://en.wikipedia.org/wiki/Pretty_Good_Privacy#Web_of_trust.

4) A further option is kind of like #1, but is more like Reddit / Stack Exchange where I just provide a platform for these communities to update pages and vote up trustworthy communities.

5) Don't do anything but allow the active community members to share their anchors out of band and establish trust out of band.

6) Some other method outside of PKI though I'd prefer to stick with the PKI option because I already have some SMIME infrastructure in place.

Which option is best? Do I have any other options at my disposal and what are their potential upsides and downsides?

Answer 1

Web of Trust does not allow you not to be "involved in the CA / RA process". It is quite the opposite: with a Web of Trust, everybody is involved in the CA / RA process. That's the point of WoT: any single user can act as a CA+RA, by verifying the physical identity of other users (the RA part) and then signing their public key (the CA part).

An often overlooked aspect of Webs of Trust is the need for redundancy. To understand it, consider the certificate validation process. User A (let's call him Akhenaton) has a copy of a public key which is purported to be owned by user B (Burna-Buriash). But he wants to make sure of it before using that key for encrypting some diplomatic letters. Fortunately, Burna-Buriash's key was certified by Suppiluliumas: the latter signed (with his own private key) a document containing both Burna-Buriash's key and name. Akhenaton does not know Suppiluliumas' key either, but this key was in turn certified by Tushratta, and Tushratta is Akhenaton's friend and Akhenaton knows Tushratta's key. This allows Akhenaton to verify the signature on Suppiluliumas' certificate, and thus Akhenaton gains some trust in Suppiluliumas' key. He can then proceed to verify the certificate issued by Suppiluliumas to Burna-Buriash, and thus gain some confidence in the key which was alleged to be owned by Burna-Buriash.

Now we see that in the certificate validation process, Akhenaton had to trust both Tushratta and Suppiluliumas to do their job correctly. Indeed, while Akhenaton has first-hand knowledge of Tushratta's key, he must still somehow believe that Tushratta will not try to deceive him by issuing a fake certificate, one containing Suppiluliumas' name, but a key which is, in fact, controlled by Tushratta himself. Tushratta's signature protects the process from interference from third parties (like that never-do-well scheming Aziru), but they do not provide protection against treason by the participants themselves, or even gullibility: Tushratta might have drunk a bit too much of imported Mycenian wine that day, and might have been himself deceived by Aziru, wearing a fake Hittite beard and claiming to be Suppiluliumas.

Things are worse at the next step, because while Tushratta is a personal friend of Akhenaton, Suppiluliumas is unknown to him. Akhenaton has no way to assess the trustworthiness of Suppiluliumas; even if Akhenaton supposes that Tushratta is friendly and sober and that the key which is purported to be Suppiluliumas' is indeed owned by Suppiluliumas, this says to him nothing about whether Suppiluliumas will truthfully do the same RA job with Burna-Buriash.

To state things simply: trust degrades sharply when transferred.

Hierarchical PKI (like what X.509 was designed to support) and Web of Trust PKI (the normal model for OpenPGP) deal with this issue in distinct ways:

• In a hierarchical PKI, the structure is pyramidal, with few CA compared to the user base; say, one hundred CA for one million users. Each CA is bound to the upper CA (which certified it) by contractual and legal requirements, so that any mistake or fraud will imply heavy retaliation on the faulty CA. CA are thus "guaranteed" to stay in line and be trustworthy by threatening them with all the Might of the Law. This can work as long as there are not too many CA, and the whole structure is properly centralized.

• In a Web of Trust, every user is a potential CA. A WoT relies on the following assumption: there may be some black sheep in the lot, but the majority of users are honest and will not try to cheat, and (possibly) most of them will be cautious enough not to sign each other key after the third pint of Guinness. There is a bit of wishful thinking in that assumption, but let's believe it for a moment. In WoT, you cannot gain enough confidence in a key by verifying a single certificate path; instead, you must verify many paths going through distinct intermediates. This ensures safety to some extent because while some paths may go through cheaters, not all users are corrupt. That's the redundancy I was talking about.

Since redundancy is important for WoT, then user software involved in WoT-based validation MUST support it. The software must build several paths, check that they do not intersect, and verify them all. That's where S/MIME fails at doing WoT: although nothing prevents X.509 certificates from implementing a WoT model, X.509 was not designed for that, and, correspondingly, software which does S/MIME (i.e. email applications like Outlook or Thunderbird) just assume that they are in a hierarchical PKI model and declare themselves to be happy with a single verified path.

That's the important lesson here: the PKI model you choose must be implemented by the verifiers, i.e. the users' applications. If you want a Web of Trust, users must use applications which actively support it, and, currently, this means OpenPGP format (with, e.g., GnuPG).

^{In the end, Akhenaton trusted everybody. This did not turn well for the Egyptian empire.}

Answer 2

Depending on the requirements, the centralized solutions using some website may be unsuitable as they become the target for attacks. People will try to hack the web server, the web service, or the reputation system you're trying to set up on top of it.

If it is acceptable that trust is established gradually, a system based on key continuity management may be interesting. Participants simply create keys and get going. Over time, people will get to know and remember these keys/identities and trust them more. Then you use central services only for convenience/lookup services (like PGP key servers). The web-of-trust model, that you make events where people establish trust into each other and trust other peoples judgement, are optional components.

Another optional component could be a facility to run a actual out-of-band communication on top of the ad-hoc keying that you do anyway, and this way authenticating your keys. This is done, for example, in the Jabber OTR plugin of pidgin, or in the CryptoPhone. I can just communicate encrypted, but at any point I also have the option to actually authenticate keys in a very secure way if I desire to do so. It simplifies bootstrapping.

BTW, I've seen exactly this approach proposed as "90% security" for making secure eMail usable. Since you already have SMIME, check if you can use or build up upon some available plugins. You want the software to remember and keep statistics on key usage and warn the user if keys unexpectedly change. If the user requests additional information on some remote identity, give some options to increase the trust into the associated keys. Unfortunately, most clients do it the other way around: They ultimately trust all kinds of CAs, but the CAs in turn employ sometimes very simple authentication to attract users. So you never see if a strong or weak authentication is used and weak authentications are silently accepted.

Answer 3

Crypto does not provide a way to establish or create trust from nothing. It only provides a way to codify and respect trust relationships that already exist. If anyone tries to tell you differently, show them the door; they're probably trying to sell you something.

The corollary of this fact is: your system should reflect the trust relationships that already exist in your community. So, start by understanding your community or organization. What relationships do people already have? How do they already do their job? This is a question that involves a bit of anthropology: observing how people currently interact in the community you are focusing on.

Then, design a system whose software trust relationships mimic the pre-existing social trust relationships. Experience shows that if you design a security system that tries to force something different on people, it won't work well. People will bypass the security system so they can get their work done, or they will curse your name and try to undermine the success of your system, or work will be held up and productivity will suffer, or other bad things will happen.

Another corollary is: you can't build a trust system for the entire world. In your question, you talk about designing a cryptographic trust architecture for the entire world. That's just flat-out nuts! Imagine someone who came to you and told you they had designed a new architecture for relationships, and he plans to tell the entire world that henceforth all of their social relationships must make sure to fit into his categories and his architecture. You'd give him a funny look and wouldn't waste any more of your time on him. When people say they want a trust architecture fit for the entire world, you should give them the same funny look and move on. People are complicated, and the world just doesn't work like that. You can't fit all the complexities and rich variety of human relationships across the entire planet into a predetermined set of a few rigid little square holes.

To summarize: I guess what I'm saying is, the way you are talking suggests that you are heading down a dead-end path. I'm concerned you're setting yourself up to make mistakes others have made before, setting yourself up to fail. I think you need to re-think your goals and pick a more focused scope where the problem is actually solvable. I also think you need to remember that you cannot solve social problems through technology. Technology can help you solve technology problems, but it is not going to change human nature.

For more about the pitfalls of PKI, I highly recommend the following readings:

• Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure. Carl Ellison and Bruce Schneier. Computer Security Journal, volume 16, number 1, 2000, pp. 1-7.

• "Naming", Chapter 6.3 of Security Engineering, Ross Anderson, 1st edition. Or, better yet, read it in the 2nd edition -- buy the book, the entire thing is great stuff.

Answer 4

I would take a look at http://convergence.io/ It is well thought out and solves the distributed web-of-trust model, (for X509, but there is no reason why that isn't a good place to start for you.)