WKD: returns only one pubkey (and why)

[David Runge]

Hi Bernhard,

On 2022-12-09 09:59:59 (+0100), Bernhard Reiter wrote:
> saw that you had a question about WKD in your blog:
> https://sleepmap.de/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168/
> 
> The reason is that WKD only allows for returning one active public
> key.

I believe that to be a problematic assumption. More on that below.

> a server may return revoked keys in addition to a new key.

And there would be a lot of reasons as to why that is good:
If I cycle out an old key I want to establish the chain of trust between
two keys using cross-signatures. Both (revoked and active) keys need to
be returned for someone else to be able to check the chain of trust
between a revoked and an active key.

We currently use this mechanism in Arch Linux's WKD [1], as we must
provide the signatures and revocation of signatures of main signing keys
on packager keys not only for active but also for inactive keys
(otherwise systems would be able to trust and install packages signed by
distrusted keys).

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.

It is also possible to have circumstances in which it is desirable to be
able to provide two (or more) active keys for a given UID, apart from
not being able to revoke an old key.
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.
Only after establishing a new key and rebuilding all packages with that
key (or another verifiable key), the old key can be revoked/ signatures
on that key can be revoked.
In the meantime, two active keys *must* exist at the same time and the
old key, once revoked, must still be available via WKD, as that is the
only place where we have full control over the data ourselves.

> This makes sense because the idea is that a client can directly use
> the key for encryption without asking the user for choice.

The client using a pubkey (e.g. a mail program) should have the user
choose which key to use once retrieved, if there are multiple active
ones, else choose the one that is active.
However, the tooling retrieving the key material should not choose for
the user which key to grab, but grab all of the available ones for a
given UID.

Conflating both the retrieval of PGP public keys and the decision making
process of which public key to use, without allowing configuration does
not only sound unflexible, but also does not allow for the above
mentioned use-cases to be covered. This is a problem.

> It seems that the version of sequoia-pgp you were using in April does
> not implement the WKD draft correctly by providing and downloading
> more than one pubkey.
> This may have added to your confusion.

If the client implementing WKD retrieval already makes implicit choices
about which key to retrieve, then that is not correct IMHO, as it also
makes assumptions about how the retrieved keys are to be used further.

In your described scenario, we would not be able to use WKD in a
validation scenario for Arch Linux at all and additional keys besides
the currently active (of which there could be several at a given time
and from your notes above it would be unclear to me which exact key
would be returned) would not be supported.

If what you describe above is indeed intended behavior, then I am
wondering what the purpose of WKD is, if it can not be fully used for
key discovery. It would sound as if PGP + WKD would not be a desirable
scenario for Linux distributions to rely on.

> Nontheless the intentions could be written more explicit in the WKD
> draft, which I have meanwhile suggested to the author.

As stated above, I believe that retrieving *all* active keys is what
should be done instead.

> Regards,
> Bernhard
> ps.: BTW there is a new group of synchronised pubkey servers, since a while, 
> e.g. see https://social.tchncs.de/@ber/107008659842900171

Thanks for pointing them out.

At least for the Arch Linux infrastructure we have completely migrated
away from relying on external keyservers and maintain a curated keyring.
The amount of issues we had with them (some don't provide signatures,
some don't provide specific key types, others don't provide the pubkeys
unless someone acknowledged them, some are only sparsely available, keys
are prone to signature poisoning attacks, etc.) did not justify their
use.

Personally I only publish to keys.openpgp.org and keyserver.ubuntu.com
apart from WKD by now, as they seem reasonably large, publicly known and
available.

Best,
David

[1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221209/fee51492/attachment.sig>