2

Why isn't there a defined protocol to retrieve PGP keys from a destination mail server? Or am I just not searching with the right parameters?

I imagine a quite simple process like other established processes (AutoDiscovery, etc.):

  1. Sender enters recipients e-mail into the mail client (thunderbird/outlook/whatever)
  2. Mail client resolves the PGP discovery service of that domain via a defined SRV record
  3. If the intended recipient has added a pubkey to his profile the service will answer the request accordingly (otherwise nothing really happens)
  4. The mail client uses the pub key and intransparent to the sender encrypts the message before sending
  5. End

I mean a database and a very simple web service that takes an e-mail address as a parameter and eventually replies with the corresponding database entry isn't that sophisticated.

Why hasn't this been done? Or am I missing a crucial point (except politics)?

Edit:

This protocol actually already exists and is part of GnuPG since v2.1.12: WKD. The protocol was submitted to the IETF in 2016 by [Werner Koch][2] of the GnuPG e.V..

Hupfauer
  • 212
  • 1
  • 9
  • 3
    There are [PGP key servers](https://www.google.com/search?q=pgp+key+server), which are independent from specific mail providers. What you instead propose is a service a mail *each* provider must somehow implement and *"recipient has added a pubkey to his profile"* seems to have specific kind of public mail providers in mind, like Gmail etc. But many mail domains don't work like this, i.e. they don't have a concept of "profile" for a user. – Steffen Ullrich Sep 03 '21 at 19:20
  • In a company environment there may be a LDAP server or a private PGP key server. For S/MIME LDAP servers are quite common as you can verify the received keys/certificates by their CA signature. – Robert Sep 05 '21 at 04:23

2 Answers2

3

PGP was designed to use a decentralized web of trust:

As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.

There are non-authoritative key servers like the MIT PGP Key Server (and plenty more), but all they do is document the web of trust. The PGP Global Directory is a little atypical: it verifies email addresses listed in keys belong to the key owner.

The web of trust is … not great; it only works when it has a critical mass of users, and PGP never got anywhere close to that.

Keybase offers an alternative to web of trust that is centralized but based on a system of proofs (everything Keybase does is fully provable using PGP) so it cannot be abused. Keybase has received its share of criticisms (they're creating their own methods, some of which pre-date newer standards that implement similar concepts). See also How does Keybase.io work? and Keybase.io (which highlights the plethora of other things the service does in addition to PGP key management).

Web Key Directory (WKD) is a system designed to allow a domain to host its keys on a web server, but online documentation is a bit sparse (I can't find the specification, just some drafts). This was mentioned in a comment to this answer and I can't say I know anything about it, but it does look promising.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
  • Isn't [WKD](https://wiki.gnupg.org/WKD) almost exactly what I am describing? – Hupfauer Sep 15 '21 at 23:33
  • 1
    @Hupfauer – WKD is interesting! I've never heard of it and documentation is quite hard to find, but I think you're right: it's what you're describing. Like the web of trust model, it may have an adoption hurdle. – Adam Katz Sep 16 '21 at 18:29
  • To add some context: [Werner Koch](https://datatracker.ietf.org/person/wk@gnupg.org) of the GnuPG e.V. introduced a proposal for this protocol to the [IETF](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/00/) back in 2016. It currently is in its 13th [revision](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/12/). – Hupfauer Sep 17 '21 at 14:27
  • I updated my original question with a write-up of WKD, if you are interested. – Hupfauer Sep 17 '21 at 15:09
  • 1
    @Hupfauer – Is that still a question? It looks like your update is actually an answer. (There's nothing wrong with answering your own question.) – Adam Katz Sep 17 '21 at 15:36
  • No, it isn't - WKD was the seeked after answer. – Hupfauer Sep 17 '21 at 19:23
  • 1
    @Hupfauer – You should remove the WKD part of your question and make it an answer. If it fully answers your question, you should accept your answer. – Adam Katz Sep 17 '21 at 20:57
2

WKD (how it works)

WKD can be implemented in two ways. However as per draft-koch-openpgp-webkey-service-12 the advanced implementation is the preferred modus operandi.

Advanced implementation

A E-Mail Domain provides a https webservice on the its subdomain openpgpkey. The URI to retrieve a key for a specific user is constructed as follows:

https://openpgpkey.[domainpart]/.well-known/openpgpkey/[domainpart]/hu/[localpart => SHA1 => Z-Base-32]?l=[localpart]

domainpart == what comes after the @ sign

localpart == what comes before the @ sign

Fallback standard implementation

https://[domainpart]/.well-known/openpgpkey/hu/[localpart => SHA1 => Z-Base-32]?l=[localpart]

Domains that only rely on the fallback implementation may not use wildcard dns for subdomains or must ensure with with an empty TXT RR that the subdomain openpgpkey does not resolve.

Web Key Directory Update Protocol

The process of updating this information is called Web Key Directory Update Protocol that specifies several methods for users to update the stored key information. This is done by sending your pub-key to a designated e-mail address that can be retrieved by looking up:

https://openpgpkey.[domainpart]/.well-known/openpgpkey/[domainpart]/submission-address

or

https://[domainpart]/.well-known/openpgpkey/submission-address

The provider will in turn reply with a message containing a nonce, encrypted by the users pub-key.

The user will then in turn decrypt the nonce, proofing he or she is in control of the private key and send it back to the provider.

The provider will verify this nonce against its database and accordingly accept the update or submission and inform the user thereof via e-mail.

tl;dr

  1. Send pub-key to provider specific address (lookup via https://[domainpart]/.well-known/openpgpkey/submission-address)
  2. Receive nonce encrypted with pub-key
  3. Decrypt nonce with priv-key to prove you control the key
  4. Reply decrypted nonce to challenge message
  5. Receive E-Mail confirming the update (or informing of errors)

How to deploy WKD

There is a script creating a WKD based of your keyring.

There is an entire blog post on gnupg.org about this topic.

Hupfauer
  • 212
  • 1
  • 9