Chain Of Trust

Where the devil is in the details

Chain of trust is simple at first glance but as soon as you look into it closely, it is not as simple as it seems. Let us try to tackle this in its pure raw form rather its X.509 implementation. So a certificate has the following structure:

struct Cert {
    unsigned char privkey[64];
    unsigned char pubkey[32]
    unsigned char signature[64];
    unsigned char issuerkey[32]; // pubkey of another
};

A certificate is a vouch of something. For example, you vouch that John is a good person. Therefore, a certificate vouches for a piece of information, usually belonging to another entity. A certificate that vouches for an information belonging to another entity is called an intermediate certificate. But if the information that it vouches for belong to itself, then it is a self-signed certificate.

Consider the following statements:

• According to Peter, John is a good person.

• According to Mary, Peter is an honest person

• According to Paul, Mary always tells the truth

The statement John is a good person can only be reliable if Mary is an honest person which in turn can only reliable if we believe what Paul said about Mary. The last part with regards to Paul is hanging because there is no existing statements that describes Paul. This means that the statement John is a good person is not a reliable information. This is an unverifiable chain of trust.

Let us add a fourth statement, so now it becomes:

• According to Peter, John is a good person.

• According to Mary, Peter is an honest person

• According to Paul, Mary always tells the truth

• According to God, Paul always tells the truth

• I am who I am

This is now a verifiable chain of trust. This is not as simple as it appears to be. The entire chain of statements really pivots into one and only one description and it is:

• John is a good person

The use of the supporting statements all pivots to proving that John is a good person. Outside of this support, the other statements are useless to us. This is a subtle point to consider and here is why.

Given a certificate chain: A' <- B <- C <- rootCA where A is vouching something about John and the ' notation beside it means, this particular entity is compromised. So entity A is vouching the statement: John is good. But A' is compromised or corrupted and is deemed found to be no longer reliable. Just because we see that B remains reliable from its vantage point downwards, WE CANNOT make a transitive application of B to the claim made by A. Because B has no such claim about John. Whereas, the entities and their chain relations in the remaining portion of the chain: B <- C <- rootCA has no iota of corruption in it and remains valid, but it has no useful claim. Yes the remaining segment of the chain is not compromised but what piece of information does it contain? Nothing. The entire value of a chain is in what the leaf is vouching for and the rest are just mechanical supports but without semantic involvement of what the leaf is vouching for. Therefore, we cannot use B to vouch that John is a good person because B only vouches for A but unfortunately A became mentally ill and is no longer reliable.

It is correct to observe that B is still reliable, and the only use for this remaining healthy chain is to re-key : Create a new certificate D that vouches John is a good person and have B signed it. The new chain, thus now becomes: D <- B <- C <- rootCA

A broken certificate renders the entire chain invalid but not all the certificates. Only A become invalid but the remaining certificates are still valid:

• B

• C

• rootCA

It is important to note that a certificate chain's validity and a particular certificate's validity are two different things. A broken chain does not mean that each of the certificates in it are broken. A broken chain only breaks the claim of the leaf node.

For example, if M is compromised, does not mean that A goes down with it if A has an alternate path via Q towards validation. But of course, X.509 can add settings to enforce such constraint. I'm not about X.509, but am purely on the concepts of chained digital signatures which is the material from which certificate chain is made of.

     A
    | |               
    M Q_________ rootCA
    |_____________| 

Two things:

• Certificate list

• Certificate chain (or list)

The value of a certificate chain is in what the leaf certficate is claiming. If one of the certificate in this list is broken, and the chain cannot find alternative path to validation, then the chain is broken. But the certificates are not, except for that one certificate that got broken.