# Chain Of Trust

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:

```cpp
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.&#x20;

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.&#x20;

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.

```cpp
     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.