How long can X.509 certificate chains be?

Question

Usually, I only see certificate chains with a root CA, an intermediate one, and a third one for the particular SSL/TLS website; but can X.509 certificate chains be deeper than 3 levels? Is there a limit to how long they can be? Wouldn't using longer chains that are more interconnected with other root and intermediate CAs help make the chain of trust stronger, more decentralized, and less prone to a single point of failure?

This seems to be the idea behind okTurtles's DNSChain—a decentralized, blockchain-based DNS network that solves the problem of having to rely on a centralized network of CAs; thus, it is resistant to man-in-the-middle (MitM) attacks.

Answer 1

There is no technical/specification limit imposed on the length of certificate chains. (However, there are X509v3 attributes which can impose policy-based limits on the length of a certificate chain for a CA; see the pathLenConstraint field of Basic Constraints, RFC 5280, Section 4.2.1.9.)

With longer chains, verifying clients need to perform a little more validation work, constructing and walking and verifying each certificate in that chain, every validation, every time. But that's not necessarily a bad thing. However, it does increase the odds that at some point in time, one of the certificates in the chain will have expired, or been revoked. Many certificate chains are constructed such that there is only one path from the e.g. leaf certificate (server/client) to a trusted root CA; should that path be invalidated anywhere along the way, that leaf certificate would not be considered trusted.

There are ways for CAs to do cross certification, indicating that two CAs trust each other (discussed in RFC 5280, Section 3.2). I'm not sure how common/widespread the usage of this mechanism is. It allows for some kind of delegation, but it is still very hierarchical and centrally managed, rather than being fully decentralized.

Hope this helps!

Answer 2

Theoretically, X.509 chains are unlimited in length. The Basic Constraints extension can apply a per-chain limit; this is used mostly for CA that agree to issue a sub-CA certificate but want to constraint that sub-CA to issue only end-entity certificates.

Implementations may have limitations. In fact, with some carefully crafted certificates, one can make a path-building application explore n! potential paths of depth n, and since factorials go up pretty fast, this can lead to huge denial-of-service attacks. Correspondingly, implementations tend to impose a relatively low maximum length (I know I used '8' for my own implementations).

In broad conceptual terms, trusts dilutes pretty fast upon delegation. When a CA issues a certificate to a sub-CA, it not only asserts that the sub-CA public key is owned by that sub-CA, but it also empowers it to perform that kind of verification on behalf of the parent CA. When a CA issues a certificate for an end-entity, it checks its identity; when it issues a certificate to a sub-CA, it also needs to make sure that the sub-CA won't be gullible. With a third level, the CA must ensure that the sub-CA is not gullible and won't issue a certificate to a gullible sub-sub-CA.

So the reflex would be to try to keep chains short rather than long.

Be wary of the "single point of failure" expression. It normally applies to operational continuity. Here, we are talking about security: a single rogue CA compromises security, regardless of how many other paths you create. This goes somehow in reverse with the SPOF rule: you avoid SPOF by adding redundancy, but in the case of certification, any involved CA is by nature able to compromise things -- the more CA you add in the mix, the more vulnerable you get.