WKD: returns only one pubkey (and why)

[Simon Josefsson]

Bernhard Reiter <bernhard at intevation.de> writes:

> Hi Dashamir,
>
> Am Montag 12 Dezember 2022 14:01:28 schrieb Dashamir Hoxha via Gnupg-devel:
>> The way that I understand WKD (and how I explain it in my presentations) is
>> that it is a way to publish your public keys (share them with your
>> contacts). It is an alternative (and replacement) to the keyserver
>> infrastructure.
>
> then it is good that we have this discussion as a reminder:
> The current WKD draft-15 (and all previous drafts as far as I remember)
> allow only one active pubkey to be returned. 
>
> Whatever WDK Can be in the future (which is to be discussed),
> as long as it is one pubkey, I hope we explain and implement it like this.
> (Otherwise we risk other problems.)

This thread was useful to me to understand that there really are two
conflicting desired features here:

  1) Use WDK to map ONE email address to ONE public key to use for
  email.

  2) Use WDK to find ALL public keys for an email address.

These are really two different use-cases, and as WDK looks now it seems
it was tailored towards 1) but many people (myself included) use it for
2) since that is how you traditionally used OpenPGP keyservers, and
people (myself included) like that semantics and is not ready to switch
to the WDK approach of trusting the WDK mapping to produce the ONE key
to use.  I have to admit that I had not understood this difference until
now, I thought WDK mainly was a key-server-replacement proposal.

I have argued before that WDK should be modified to allow returning more
than one key.  I can see now why that request has not been honored: it
breaks the use-case 1) above.  I don't think we can or should convince
people that the semantics with 1) is bad and should't be specified or
implemented.  To the contrary: it seems very important to allow the
functionality of 1) for simple bootstrapping of encrypted email.

However maybe what we can achieve is that WDK could ALSO cater to the
use-case of 2).  What do you think?

If people who work on WDK find it acceptable to cater to people wanting
the semantics of 2) while still supporting the use-case of 1) how about
specifying that a plural-version of the URL returns all keys?  So let's
assume we have this URL to return one public key only:

 https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4

Then we could standardize the following (note plural 's') to return ALL
keys for the given email address:

 https://intevation.de/.well-known/openpgpkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4

Alternatively, we could use URL parameters on the first URL like this:

 https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4?allkeys

Or perhaps a compromise -- based on the observation that registering
multiple 'well-known' protocols has a cost, and that URL parameters like
'?allkeys' works badly with HTTPS servers serving static content, how
about a URL like this:

 https://intevation.de/.well-known/openpgpkey/allkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4

This would signal that the server should return all known keys
associated with a particular email-address.

While migrating to new keys is a complicated matter, at least this
allows WDK to play a part of this by serving multiple keys for the same
email address.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221213/f20d7c25/attachment.sig>