WKD: returns only one pubkey (and why)

[Andrew Gallagher]

On 9 Dec 2022, at 12:38, David Runge <dave at sleepmap.de> wrote:
> 
> In regards to returning multiple active keys and looking at the
> following text from the draft, I believe that the assumption is
> problematic:
> 
>> The HTTP GET method MUST return the binary representation of the
>> OpenPGP key for the given mail address.
> 
> If someone loses access to their private key material and can no longer
> revoke their key, then we must provide both that key and any newer key.
> In this case there may be two (or more) keys active for a UID at the
> same time (for a while or indefinitely) and the old one should remain
> available.

If you have lost the private key material for a key, you probably should not publish it on WKD, as doing so would only encourage people to encrypt to it. WKD is a key-discovery protocol for email encryption, it is not a general-purpose keyserver replacement.

> Again using the example of Arch Linux here: If someone loses access to
> their private key material (e.g. key only available on hardware token)
> or plainly wants to switch from one key to another, they can not revoke
> that key right away, as there are still (hundreds of) software packages
> available in the repositories, signed with that key.

WKD is not useful for verifying signatures, as it does not support key discovery by fingerprint, only by email. In order to verify an arbitrary signature you must either look up the key by fingerprint on a keyserver that supports it, or distribute a trusted-signers keyring in advance, e.g. by installing a keyring package.

A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221209/b08d2df8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221209/b08d2df8/attachment-0001.sig>