Delegated trust vs Web of Trust

When working with certificates or digital signatures there's two main trust models - "delegated trust" and "web of trust".  This post provides an overview of the models and discusses the pros and cons of each.  Certificate Authorities take advantage of delegated trust, while mechanisms such as PGP (or GPG) use the web of trust.

(Apologies, this post is acronym heavy but all acronyms are defined.)

Certificate Authorities and issuing certificates

A Certificate Authority (CA) is an entity that is trusted to generate certificates for third parties.  Additionally they can issue a certificate for themselves.  Whenever you access a website over HTTPS (like this blog), your browser is receiving a certificate that's been issued by a CA.

Different certificate verification types exist, commonly known as Domain Validation (DV), Organisation Validation (OV) and Extended Validation (EV) - costs increase as you move from left to right in that list.  With DV, the CA just checks that a domain (e.g. blog.jonsdocs.org.uk) exists and that the certificate requester has some form of control for the domain.  I regularly use Let's Encrypt who provide DV certificates - they check that a file they specify exists on the website before issuing the certificate.  Because they (or another CA) control the file that has to be found it is assumed the requesting party has permission to request the certificate.  Alternatively there's just a link to click in an email.

Organisation Validation involves the CA performing more in-depth checks.  Often this takes the form of a phone call to a named individual, via a phone number found in a third party directory such as the Yellow Pages or Dun & Bradstreet.

Extended Validation takes this all one step further, delving deep into the recorded history of an organisation.  EV was once seen as the highest standard for trust, however, with browsers such as Chrome and Firefox removing EV indicators it's fair to say EV is essentially dead.

What's delegated trust?

When trust is delegated you're essentially saying "if this organisation does something, I trust it completely", and this is the model used when working with Certificate Authorities.  Your computer knows who to trust based on a published list of CAs that are considered worthy.  On Windows this displays like this:

Due to this list, if I possess a certificate that's issued by one of the Root CAs your device will trust my certificate.  This becomes a problem if I can perform a man-in-the-middle attack against you while in possession of a certificate for someone else, say mail.google.com.  Because you trust my certificate, as it was given to me by someone that you delegated trust to, you wouldn't know I was an attacker.

Do CAs get it wrong?

Yes, DigiNotar famously issued many certificates after being hacked in 2011 and ceased operation not long after going public.  The incorrectly issued certificates were used to intercept traffic (the aforementioned man-in-the-middle attack) and allegedly used to spy on the browsing activities of Iranian citizens.

Symantec also saw their certificates distrusted by Firefox and Chrome after a number of issues were identified in Symantec's processes.

Web of trust

For systems such as PGP, an entity (perhaps an individual or an organisation) generates a private / public key pair.  As a rule you have an absolute trust for your own key - after all, you know that you made it.  Using your key you can sign other people's public keys, effectively saying "I believe this key belongs to the named entity".  As more people sign the key a web is built:

In the diagram above the leftmost person has signed three keys (the green arrows), so that person has said "I trust that the keys owned by these people actually belong to them".  The person at the bottom has had their key signed by four different people although how much checking each person did before signing is up to them.

In my case, I make sure I've checked who the person is (I'll either already know them, or see some official ID) and also confirm with them that the key in question is theirs.  Then I'll sign the key.

Now imagine that I trust Chris completely - I know that he performs due diligence when he's asked to sign keys, he makes the same checks as I do.  On the other hand, Amity is happy to sign anybody's key.  The concern for me would be that someone else hasn't performed good checks, so a well signed key actually has little value unless the signers have value to me.

As the level of trust is down to me I have full control.  Different people have different approaches here, but ideally you'll find that someone you trust has signed the key.  

Jeff Carouth has written a fantastic, technical, blog post about key signing and his approach and mentions key signing parties.  Not being one for traditional parties these at least appeal to my geeky nature.

Which is better?

The answer is neither as both have benefits and drawbacks.  Delegated trust has a much lower friction as "it just works".  To fully participate in the web of trust you really need to be comfortable with PGP or similar.  Mostly web of trust is used for exchanging messages, whereas delegated trust powers HTTPS.

Keybase - an honourable mention

Keybase's goal is to make encryption and identity available to everyone in a very easy and friendly way.  After creating a Keybase identity you link your other identities via a set of cryptographic proofs.  For example, my Keybase identity shows that I own @joncojonathan on Twitter, my Github profile, and also https://blog.jonsdocs.org.uk among other things.  The Keybase app makes all of this nice and easy to use, whereas PGP can be a pain to work with.  Most of my Keybase graph is shown below, and indicates how my various keys have signed (proven) that I own others.

Banner image: my web of trust graphic, stick person images from Google Image search.