Hosting a Web Key Directory (without dynamic WKS)

Ideally a Web Key Directory will be created and maintained through a Web Key Service but organisations or individuals may want to just host a Web Key Directory without a Web Key Service. Using a flat file-structure that needs re-creating if a pubkey changes:

Other howtos

• https://www.kuketz-blog.de/gnupg-web-key-directory-wkd-einrichten/ in German 2019-09-11

Requirements

• A web server that provides https with a trusted certificate.

Using gpg-wks-client from newer GnuPG (GnuPG v>=2.2.12)

GnuPG 2.2.12 has an improved gpg-wks-client tool which can be used to create a local file structure.

It takes the (public) keys from the GnuPG keyring, so the keys need to be known to GnuPG.

export PATTERN="@example.org"
gpg --list-options show-only-fpr-mbox  -k $PATTERN | gpg-wks-client -v --install-key

(Note for windows 10 - PowerShell: You may require path names to the binary, e.g. 'C:\Program Files(x86)\GnuPG\bin\gpg-wks-client.exe')

Details:

• The gnupg keyring is searched for all public keys (-k) matching the defined pattern, the output is generated as fingerprint user_id values (show-only-fpr-mbox).
• WKD will be only useful for keys of the domain serving the directory. If you specify other patterns (e.g. "jane.Doe@example.org"), all keys matching that pattern will be considered for the update (which will be useless in the case of domains you do not serve, but useful if you only want to update a subset of keys).
• This listing will then be piped to gpg-wks-client, which will create the appropiate folder structure and entries for each result.
• the output will be written to the openpgpkey folder (or any folder you specify with the -C option). See publishing for the final placements and additional adaptions.

Method with older GnuPG version

The script: generate-openpgpkey-hu (in the Mercurial repository "wkd-tools")

This implementation uses Python 2 with python-gpg or python-pyme.

There is an alternative implementation using Python 3 and python-gnupg available at https://gitlab.com/Martin_/generate-openpgpkey-hu-3/

Usage

You can either export all the keys in your keyring which belong to a domain or provide an explicit keyring containing the keys you want to publish.

The call:

    ./generate-openpgpkey-hu example.com hu

Will create a directory called hu containing all the keys with @example.com mail addresses.

If there are multiple valid keys for a user in your keyring this command will error out. In that case you can prepare a keyring with only the keys you want to publish.

e.g.:

    gpg --export 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1 | \
    gpg --no-default-keyring --keyring ./wkd-keyring.gpg --import

And then provide that keyring to generate-openpgpkey-hu:

    ./generate-openpgpkey-hu example.com hu wkd-keyring.gpg

Publishing

The hu directory has to be published on your server as https://openpgpkey.example.com/.well-known/openpgpkey/hu/ (or https://example.com/.well-known/openpgpkey/hu/ iff openpgpkey.example.com is not resolvable via DNS).

On your server create the according directory and set the permissions according to your system. Make sure that there is no automatic directory listing for .well-known/openpgpkey/hu/.

Starting with draft 05 the OpenPGP Web Key Directory specification requires that a policy file https://example.com/.well-known/openpgpkey/policy is available. It can be an empty file, which fits well here, because it is only relevant for the update protocol anyway.

A WKD Checker should be implemented to verify the functionality of the WKD.

This example Makefile automates the hu directory generation and publishing (using the python script for the older gnupg version method as documented above). Edit the variables at the top of the makefile to your RSYNC_TARGET The KEYRING variable is optional and can be empty.