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

[Simon Josefsson]

Bernhard Reiter <bernhard at intevation.de> writes:

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

Thanks, this helps to understand the driving forces behind things.

>> 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).

I think keyservers are useful, but to me being able to self-publish PGP
keys from your own domain is important: it avoids relying on centralized
key servers.  In the old days, centralized key servers worked well
enough so that this wasn't really an issue, but today I think being able
to self-host PGP key discovery is important so we have options.

> == 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 :/ ).

Yes -- that seems like a really simple solution.  Specify that the FIRST
key is the ONE key to use when the application just wants one key to use
directly.  Say that if more than one key is available, the client MAY
import the others too, saving them for future use.  This requires
OpenPGP packet parsing in the client, but I'm not sure that is a
problem?

>  b) Add an URL somehow (maybe as pubkey user attribute) for the other pubkeys
>     to be fetched.

I would like to avoid adding more things to my pubkey's just for this
use-case.  My OpenPGP keys cross-certify each other, so that could be
sufficient reason for cross-trust between them, but I can see some
environments where cross-cerifying keys is difficult (say for role-based
keys like security at gnu.org if multiple independent keys for that adress
is valid and used).

/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/20221215/eb1c35d9/attachment.sig>