Rick van Rein
Published

Mon 25 September 2017

←Home

Identity 10: OpenPGP without Web Of Trust

OpenPGP is a powerful technology for signing and encryption, because it does not imply a stiffling key infrastructure. Instead, it uses a Web Of Trust that is flexible... and complicating for new users. We now introduce an approach to securely use OpenPGP without even that.

When someone sends you a message with an OpenPGP signature, or if you want to send them an encrypted message, you will need their OpenPGP public key. There are several ways to find these keys, but the difficulty lies in validating the key.

Shared Key Servers and Web Of Trust

There are a few well-known public key servers, in use by many OpenPGP users. Based on an email address, they will present the PGP key(s) attached. None of these keys is validated however; one may have been submitted by anyone.

To this end, people meet in so-called PGP Key Signing Parties, where they pair up and validate a photo ID card against the key, and later sign the other person's key with theirs. As a potential user of a key, you are supposed to find a path from your key to theirs. This is the so-called Web Of Trust.

This system makes it difficult to change to a new key, because one's reputation is literally at stake. With no paths leading to a new key, it is difficult for others to start using your key. With five independent paths, it's easy to place a fair degree of trust in a key. But what about intermediate numbers of parallel paths? Or how about very long paths?

Everyone has their own policies where the Web Of Trust is concerned. This is difficult, because it means that no certainties can be derived from OpenPGP keys. The competing technology X.509 is not ideal either, as it demands inclusion of a certificate in one (and no more) hierarchies; as with the Web Of Trust, a shared root certificate is required before two parties can rely on each other's validity.

In practice, the level of validation of an email address is at best that the claimant has clicked once on a link in a confirmation email. Not a very strong foundation for a cryptographic framework. Even when repeated use of the same key can put us at ease, this is not the instant security that we should ideally have in a world of ever-changing contacts.

Global Directory and DANE

The LDAP Global Directory is a thoroughly defined mechanism for announcing well-structured data under a domain name. One of its uses is to publish OpenPGP keys directly under a domain name, and this is indeed supported in GnuPG, the most commonly used OpenPGP software.

Downloading data from LDAP is a matter of automation, which is indeed shown to work by GnuPG. To completely rely on it, one may additionall use STARTTLS within LDAP, and DANE/DNSSEC to validate the certificate used for it; a lot of technology, but completely automatic.

The one factor relied on here is the domain, and the integrity of its management. This is only fair; even a large and open provider such as GMail is good at avoiding that their users can act on behalf of each other, and any smaller domain would strive for the same. Given that this can be trusted on, the Global Directory is a good solution. But it does imply a need to setup (quite) some infrastructure.

DKIM as Key Validator

Under DKIM technology, an (originating) mail server adds a signature on the message content, thus fixating the message because any change to the message would invalidate the signature. So, by checking the signature, a recipient can assure that the email has not changed while in transit.

DKIM is a very useful technique for passing around OpenPGP keys. As long as the From: header of the email agrees with the UserID of the OpenPGP key, and the DKIM-Signature: header includes that same issuer or otherwise their domain, and signs at least the body and the From: header, it is safe to trust that the body has not been modified since it left the signing/originating mail server. In other words, if that content includes an OpenPGP key, it can be trusted for that email sender.

Wow, we just introduced a simple and elegant mechanism to exchange OpenPGP keys without even needing the Web Of Trust. Now we can really create a public key and use it without concerning anyone else!

So, is these really practical? Yes, as it turns out to be within everyone's reach:

  1. The sender creates an email account with DKIM, like with GMail
  2. The sender creates an OpenPGP key with UserID set to the email account
  3. The sender uses the email account to spread the OpenPGP public key
  4. The sender can now use (any) email address to send authenticated email
  5. Recipients can return encrypted email for the email owner's eyes only

To validate the submitted key, a simple piece of software like dkimpy already suffices. For now, this is commandline software, but it serves as a demo of what could be easily added to web and desktop mail tools.

DKIM to drive Bots

We explained before that we can see DKIM as a basis for automated interactions with email bots. No need for confirmation links (a really weak security model) but instead, validate an email including its contents when it is sent over normal pathways (that happen to do DKIM).

One service that we envision is a filter for outgoing mail to be used by government agencies and other large vendors, based on recipients that setup their OpenPGP keys.

Imagine the OpenPGP user with a suitable, DKIM-signing email account, as described above. And imagine a bot listening to +contact+pgp@example.com for emails holding an OpenPGP key. It would automatically perform the validations (perhaps also using dkimpy!) to extract the OpenPGP key, and install it in the outgoing mail server for outward encryption. And it may include it for incoming signature validation.

What we have now, is a model where we can (finally!) tell our government, bank, financial advisor to only send us email with encryption. And it does not even require those "professionals" to understand the privacy of their business and the corresponding use of OpenPGP for achieving it; it does not require them to remember that they should employ OpenPGP when talking to you; it is all taken care of by their outgoing mail server. A mail server to which they ought to have only access over an encrypted (MSA) connection.

So there we have it... OpenPGP can be omnipresent in a breeze. And nobody should be bothered when asked to apply it when communicating with you.

Go Top