The length of the cert chain doesn’t really help for decentralization purposes, because in X.509 the signatures only relate to trust delegations from one entity to another, and not to checking the content of the cert (so when entity X appears in the middle of the trust chain, they’re not saying “this end-entity cert is right”, they’re saying “we agree to delegate trust to entity Y; if you accept us as a CA, you can also accept Y as a CA”).
For example, for the current Let’s Encrypt chain, we might sign a cert for the end-entity
example.com using our Let’s Encrypt intermediate cert, which in turn is signed by IdenTrust. Now the chain contains three things: IdenTrust’s root, our intermediate, and the end-entity
example.com cert. However, IdenTrust not only didn’t check the correctness of the
example.com cert, it doesn’t even know it exists! IdenTrust’s role in this chain is limited to saying that Let’s Encrypt is a real, trustworthy CA.
That structure doesn’t change in a longer cert chain; if IdenTrust signed a certificate nominating SuperKeen CA as a certificate authority and SuperKeen signed a certificate nominating Great Security as a certificate authority and Great Security signed a certificate for Trusty Certificate Trust and Trusty Certificate Trust signed a certificate for you, Geremia, none of the entities in the chain would even know you exist or check or confirm the correctness of the Geremia cert except for the last one, Trusty Certificate Trust. There is no sort of day-to-day involvement or awareness or direct supervision of the content of the end-entity certs by the CAs earlier in the chain. The only thing the other folks in the chain can do is revoke their own signatures if they think that a downstream CA is misbehaving egregiously.
So the basic structure of X.509 really supports hierarchy, not decentralization. If you make chains long then anyone in the chain has a kind of veto power, but not over individual certs, just over the yes-or-no validity of the remainder of the chain. So again, IdenTrust could choose to revoke its signature for Let’s Encrypt as a whole, but can’t approve or disapprove individual certificates that Let’s Encrypt issues.
One way of putting this issue is that X.509, as deployed and implemented, doesn’t really allow for multiple signatures on the same cert, so there isn’t a useful way that you could get certificates from 10 CAs in parallel (or 10 whoever or whatevers in parallel) and present them all to a user to help in making trust decisions and to confirm the same information via multiple sources. Instead, you get the signatures in series, in a delegation hierarchy. There are minor exceptions to this having to do with different entities having different views of what is a root vs. an intermediate CA, but I don’t think they change the picture qualitatively.
There’s an interesting PKI reform and decentralization project called Monkeysphere
that does directly aim to decentralize trust on the web; the big difficulty is that it means accepting new certs is much less automatic and requires much more conscious and explicit decisions by the relying party (the end user). The challenge of that is that most people don’t currently understand exactly what these decisions mean, and if they come to understand, they’re still not accustomed to spending a lot of time making these decisions in order to use the web, and don’t necessarily even have a specific basis on which to make them. An advantage of the centralized PKI is that you can automatically have browsers make these decisions on behalf of the user (as “user agents”) in a relatively automated and relatively predictable way. Of course the centralized PKI has other serious disadvantages which are well-known to advocates of decentralized communications systems.
The existing browser trust model and the technology behind it are really not adapted for decentralized trust decisions, so something significant will have to change on that end.