I am excited to announce that PGPainless will receive funding by NGI Assure to develop an implementation of the Web-of-Trust specification proposal!

The Web-of-Trust (WoT) serves as an example of a decentralized authentication mechanism for OpenPGP. While there are some existing implementations of the WoT in applications such as GnuPG, their algorithms are often poorly documented. As a result, WoT support in client applications is often missing or inadequate.

This is where the aforementioned specification comes into play. This document strives to provide a well-documented description of how to implement the WoT in an interoperable and comprehensible way. There is already an existing implementation by the Sequoia-PGP project (Neal, the author of the specification is also heavily involved with Sequoia) which can serve as a reference implementation.

Since I imagine implementing the Web-of-Trust isn’t a straight-forward task (even though there is now a specification document), I decided to dedicate a series of blog posts to go along with my efforts. Maybe this helps others implementing it in the future.

What exactly is the Web-of-Trust?

The essential problem with public key infrastructure (PKI) is not to obtain the encryption keys for contacts, but rather verify that the key you have of a contact really is the proper key and not that of an attacker. One straight-forward solution to this is used by every user of the internet every day. If you visit a website on the internet, the web server of the site presents your browser with its TLS certificate. Now the browser has to figure out, if this certificate is trustworthy. It does so by checking if there is a valid trust-path from one of its root certificates to the sites certificate. Your browser comes with a limited set of root-certificates already preinstalled. This set was agreed upon by your browsers/OS vendor at some point. These root certificates are (mostly) managed by corporations who’s business model is to vouch for your servers authenticity. You pay them so that they testify to others that your TLS certificate is legitimate.

In this case, a trust-path is a chain of certifications from the trusted root certificate down to the sites TLS certificate. You can inspect this chain manually, by clicking the lock icon in your browsers task bar (at least on Firefox). Below is a visualization of the TLS certificate chain of this blog’s TLS certificate.

The certificate “ISRG Root X1” belongs to let’s encrypt, a not-for-profit CA that very likely is embedded in your browser already. R3 is an intermediate certificate authority of let’s encrypt. It certified my blogs TLS certificate. Since during the certificate renewal process let’s encrypt made sure that my server controls my domain, it has some degree of confirmation that blog.jabberhead.tk in fact belongs to me. This step can be called manual identity verification. As a result, it can therefore attest the legitimacy of my TLS certificate to others.

One property of this model is that its centralized. Although there is a number of root certificates (hundreds in fact, check your /etc/ssl/certs/ directory!), it is not trivial to set up your own, let alone get browser/OS vendors to include it in their distributions.

Now lets take a look at the Web-of-Trust instead. The idea that describes the difference between the centralized TLS model and the WoT best, is that people trust people instead of corporations. If Alice trusts and vouches for Bob, and Bob trusts and vouches for Charlie, Alice could transitively trust Charlie. These trust paths can get arbitrarily long and the whole network of trust paths is what we call the Web-of-Trust. Instead of relying on a more-or-less trustworthy certificate authority to attest key authenticity, we gather evidence for the trustworthiness of a key in our social circle.

This model can be applied to corporate environments as well by the way. Let’s say FooBank is using the Web-of-Trust for their encrypted email traffic. FooBanks admin would be tasked with keeping a list of the email addresses of all current employees and their encryption keys. They would then certify these keys by signing them with a company key which is kept secure. These certification signatures are valid as long as the employee is working at the bank. Other employees would in return sign the company key and mark it as trustworthy. Now they can build a trust path from their own key to that of each other current employee. In that sense, the CA model can be seen as a special case of the Web-of-Trust.

The main problem now is to find an algorithm for determining whether a valid trust path exists between our trust-root and the certificate of interest. You might wonder “What is the trust-root? I thought the WoT comes without centralized trust in a single entity?”. And you are right. But we all trust ourselves, don’t we? And we trust ourselves to decide whom to trust. So to realize the WoT, we define that each user has their own “trust-root” certificate, which is a single certificate that certifies “trusted introducers”. This is the start of the trust-path. In case of FooBank, Employee Albert might for example have a personal trust-root certificate that certifies FooBanks CA key, as well as that of Alberts wive Berta. Now Albert can securely message any FooBank employee, as well as his wive, since there are trust-paths available from his trust-root to those contacts.

Luckily, the problem of finding an algorithm to determine trust-paths is already solved by the Web-of-Trust specification. All that’s left to do is to understand and implement it. That cannot be that hard, can it?

To be continued…