WKD shall we add distributing multible pubkeys? (Re: WKD: returns only one pubkey (and why))

[Dashamir Hoxha]

On Thu, Dec 15, 2022 at 10:43 AM Bernhard Reiter <bernhard at intevation.de>
wrote:

> Am Dienstag 13 Dezember 2022 13:17:53 schrieb Simon Josefsson via
> Gnupg-devel:
> > 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.
>
> Thanks for the good summary.
>

I would like to add that there are two basic use-cases of OpenPGP:
1) encryption
2) signature

These use-cases have different requirements.
When we send an encrypted message to an email address, we need to know the
most recent public key (only one).
For verifying a signature (of an email, package, document, etc) the most
recent public key might not be enough, since the signature may be done with
an old key.
Another difference is that in the "encryption" use-case we only know the
email address (user id), and most probably don't not know the key ID. But
in the "signature" use-case we certainly know the key ID, and we may also
know the user id (email address), if the signer has included it in the
signature.

> I have to admit that I had not understood this difference until
> > now, I thought WDK mainly was a key-server-replacement proposal.
>

The same for me, but as explained in this thread, WKD was built to
facilitate the "encryption" use-case. In this case you know only the mail
address, and you need the public key that is the most qualified for sending
encrypted messages to this email address. From the email address you (your
mail client) can construct a well-known url and can (potentially) find the
public key automatically.

Given that we want a pubkey exchange even without email provider and email
> addresses, the next important thing I see is to improve the keyservers.
>

This is certainly good, but not related to WKD.

== Ways to deliver several pubkeys via WKD
> Again thanks for the technical ideas.
>
> Two more ideas:
>  a) Allow for several pubkeys to be returned, but indicate which one
>     is the "primary" one among the active ones. Could be the order,
>     could be something else. However should be easy to use from the client
>     side (and is potentially not backwards compatible :/ ).
>

I suggested a proposal before (alternative to the Simons' proposals), but
it was not described clearly, so let me summarize it again:

The idea is that the current WKD well-known url does not change at all, but
in addition we add another type of well-known url like this:
https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9
The public key is located in the directory "/id/", and the name of the file
is the same as the ID of the key.

When the user publishes a new public key on WKD, it is stored on the "/hu/"
directory, same as before, but in addition it is also stored on the "/id/"
directory. The same thing is done when another public key replaces the old
one, and now on the "/hu/" directory there is only one (corresponding) key,
but on the "/id/" directory there are two (corresponding) keys, the new one
and the old one.
Of course, since everything is under user's control, the user may decide to
not publish keys on the "/id/" directory, or to make a symbolic link from
"/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4" to
"/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9", etc. (depending on his
use-cases, whether he is using WKD for encryption, for signature
verification, or for both).

This proposal seems to me easy to be implemented (to build a WKD), and
completely backwards compatible with the current version of WKD (the mail
clients don't need to change anything at all, and they will still be able
to get the public key for encryption).

Regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221215/8e8484bb/attachment.html>