Chris's Wiki :: blog/tech/WebOfTrustFlaws

Flaws in the 'web of trust' approach to trust issues

January 1, 2009

One alternative to monolithic certificate authorities is a web of trust approach to trust issues. Here's my view of the flaws this model as an alternative to CAs, when used in practice.

First, you haven't actually removed the need to pick trust roots; every user has to start their web somewhere, and usually they are going to start from some well-known root or roots. What you have really done is made trust roots less subject to detailed scrutiny and criticism, and probably made it less obvious to people who they should start out trusting.

Next, a web of trust is only as strong as its weakest link, and there are a lot of links, which means a lot of places for the overall web to be weak and thus to let attackers in. The usual answer is revocation, but threats of revocation are subject to being gamed by attackers, for example by the attacker doing their best to have a bunch of valid nodes dependent on their certification in addition to the harmful nodes. Revocation also assumes that you can reliably identify the true start of the rogue nodes, which I think is optimistic; there is a lot that an attacker can do to cloak how far up the web of trust the rot truly goes.

There are more sophisticated schemes that try to work around the second issue (requiring more endorsements for more trust, see trust metrics), but I believe that it's been demonstrated that sufficiently determined attackers can eventually game them too.

Sidebar: I don't think trust is even transitive

I also think that there is a strong argument that trust is simply not transitive in the way that a 'web of trust' requires it to be. On a concrete basis, there are at least three sorts of trusts involved in a web of trust:

I trust that you are Joe.
I trust that you are making sure of the identities of people that you are trusting.
I trust you to make sure that other people are verifying the identities of people that they are trusting.

These trusts (and their further recursion) are entirely different things and cannot be bundled together. They are also increasingly hard to verify (to the point where I think that most schemes only really verify the first trust and wave their hands about everything else).

Comments on this page:

From 216.254.70.154 at 2009-01-05 14:11:10:

Trust is definitely not transitive, but common implementations of the Web of Trust (e.g. OpenPGP) makes no such assertion. Common implementations of hierarchical certificate validation (e.g. X.509), on the other hand, seem to assume that there is transitive trust by default granted to any "trusted CA". In OpenSSL, for example, a chain up to 9 levels deep (!) is trusted by default.

If you look at gpg's implementation of OpenPGP, you can see that even a key/userid pair with hundreds of signatures will be treated as "unknown validity" if none of the signatures are made by users to whom you have assigned ownertrust. Note the distinction between "validity" and "ownertrust". These two concepts correspond to the first two "levels of trust" that you've described. GnuPG's documentation of this has been confusing, but the underlying concepts are there (and recent changes in the gnupg documentation make things a bit clearer). By default, this trust hierarchy is flat; if i trust your certifications, and you certify Mary's identity, Mary's certifications hold no special import for me.

However, to represent the third level of trust with OpenPGP's web of trust (and indeed, 4th, 5th, etc. levels as well), you can use a trust signature, should you want to implement the type of chain currently widely used by X.509.

The web of trust is important (and useful!) because of the ability to adjust which edges in the graph you accept as useful (note also that marginal levels are supported: you can even express "i'll accept a certificate from this authority only if two other similar authorities corroborate its assertion"). You can see this advantage clearly when a CA starts to become untrustworthy; presumably the vast majority of certificates published by the CA are actually still legitimate, and not everyone can get a new certification immediately (nor can every client change their root trusts immediately). Under the current X.509 hierarchy, a client disabling trust in that CA would mean an immediate failure for them of any service using a cert from that CA. With a WoT model with multiple possible trust paths, it's possible to smoothly walk away from any given CA by adding certifications from more trustworthy authorities, allowing clients to deprecate the failing CA as their schedules/urgency permits, but without causing a 'net-wide disruption. (i've written this scenario up in more detail if you're interested).

A web of trust, properly implemented, offers basically the same features as current hierarchical models if that's what the users and implementors actually want, because the same structure can be represented. But in addition, it offers the ability for a healthier infrastructure, and discourages structural monopolization of trust. Yes, most apps will still need to choose their default roots, but they would have more latitude to do so based on the actual trustworthiness of those authorities under a web of trust model than they currently do.
-- Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Written on 01 January 2009.

«	Certificate authorities seem to be a real weakness in SSL

Why SSL needs certificate authorities, or at least trust roots