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

[Bernhard Reiter]

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

Some history: When WKD was designed in 2016 [1], the old (aka SKS) keyservers
where not yet in big trouble if I remember correctly, so there was less need
for case 2).

Another design goal was simplicity (often called "lean" in process speak) to 
allow for an easier uptake. So further uses are were not ruled out, but the 
most important design goal(s) for the main user experience should be reached 
quickly.

> 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?

So far I am still makeing up my mind. A few thoughts:

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.
(To allow carrying third party signatures again.)

Being forced to use different channels for other pubkeys, except the current
active one, has its merits: it may potentially help to detect malice done to 
the email provider's web server infrastructure. 

In addition the calculation of trust for several pubkeys has to become better
in implementations, if not just for cases of key rollover. Also for detecting
attacks and to cater for different levels of security needs. If there is
a good calculation of trust, you could get the currently active pubkey and
then sign others with it, which could be fetched elsewhere (keyserver, 
homepage, etc.). If so, one current pubkey via WKD could be enough to 
jumpstart 2).


== 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 :/ ).
 b) Add an URL somehow (maybe as pubkey user attribute) for the other pubkeys
    to be fetched.

Best,
Bernhard


[1] https://wiki.gnupg.org/EasyGpg2016 has details, I was part of the team.

-- 
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221215/415c0237/attachment.sig>