Support Web Key Directory

[micahflee]

Instead of just supporting fetching keys from key servers, GPG Sync should also support fetching keys from an OpenPGP Web Key Directory (WKD).

Idea from this twitter thread: https://twitter.com/monsieuricon/status/1095430039905148928

[mricon]

My other suggestion is perhaps including an optional "key hash" that can be something as simple as gpg --with-colons --list-sigs KEYID | sha1sum. This way the consumer can compare if the key hash changes between gpgsync runs and only refresh the key from the WKD if there are actual key changes.

[micahflee]

The Keylist RFC format allows for adding arbitrary fields to keys in the keylist file, so it would be completely valid for a key to look like:

{
  "fingerprint": "927F419D7EC82C2F149C1BD1403C2657CD994F73",
  "name": "Micah Lee",
  "email: "micah.lee@theintercept.com",
  "key_hash": "37007cdfce4ae67527abb02db1a0e7a9c13b1d70"
}

But you're suggesting behavior where GPG Sync would, when refreshing a keylist calculate key_hash for each key that exists in the local keychain, and only fetch the key from WKD if the key_hash has changed? How would GPG Sync know whether the key stored on the WKD has a different hash than the one in the local keyring without fetching the key?

[mricon]

There are 2 ways to go about it:

1. preserve the keylist from the previous run and compare key_hash values between runs, or
2. calculate key_hash on its own, since running the command should generate the same hash locally (however, this is fragile in case local signatures are added or other variations in output)

I prefer the first way, just so we don't depend on the output of gpg --with-colons --list-sigs not changing between various clients.

[mricon]

(This is similar to how grokmirror works -- it preserves the manifest between runs and performs comparison based on similarly-generated git repository "fingerprints". Another upside of preserving the keylist from the previous run is relying on HTTP's "If-Modified-Since" header to get a quick "nothing changed" if the remote copy of the keylist has the same timestamp as the local one.)

[wiktor-k]

Instead of just supporting fetching keys from key servers, GPG Sync should also support fetching keys from an OpenPGP Web Key Directory (WKD).

Excellent idea, especially that gpgsync would frequently be used within one organization that usually controls one "company" domain that can be used to store keys (just like kernel.org).

I'll drop some WKD info that may (or may not) be relevant in this context:

From the v0.3 announcement:

So you can’t use GPG Sync to subscribe to keylists if you use non-GPG encrypted email software like ProtonMail, Mailvelope, Canary Mail, or OpenKeychain.

Yes, they don't support keylists but they have a varying level of support for WKD already.

Enigmail automatically downloads people's keys via WKD when composing an e-mail, since version 2.0. Mailvelope supports WKD lookup since version 3.0, OpenKeychain since version 5.1, ProtonMail offers their users' keys via WKD since 2018-11, it seems they will also discover foreign keys via WKD in the future. It's also supported by some other software (e.g. Mailpile).

If a key was fetched using WKD using GnuPG (gpg --locate-key $EMAIL) then it will be automatically re-fetched if it expired.

WKD can also be used for fetching signing keys when verifying signatures with --auto-key-retrieve if the signature has appropriate packet.

[eloquence]

While gpgsync does a good job hiding the fragility of the keyserver ecosystem, if this change would enable an org like ours to deprecate use of keyservers entirely, I think it would be hugely welcome. I don't see how that ecosystem is sustainable in its current form, and WKD seems like a very plausible alternative.