WKD: returns only one pubkey (and why)

[Bernhard Reiter]

Hi David,

Am Freitag 09 Dezember 2022 13:38:01 schrieb David Runge:
> > WKD only allows for returning one active public key.
>
> I believe that to be a problematic assumption. More on that below.

thanks for sharing your crypto use cases from Arch Linux
and your feedback how the current WKD contributes to solve them.
WKD and other aspects of OpenPGP can be improved, my first step
is understanding of the alternatives and discussing them.

In this email I respond to what WKD aims for:

The design goal of WKD as it is (please see the question in my other email):
Establish some minimal trust so that I can encrypt at the first message
exchange, and hereby improve the usability of the end to end crypto
functionality. The old user experience has been criticised rightfully
for making it too hard for users to profit from some basic security 
attributes. You can read up quite a few of the considerations and arguments 
at
  https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept
  https://wiki.gnupg.org/AutomatedEncryption

In the regular cases, user should not have to think about crypto and key 
pairs. And if they have, the only for important cases (e.g. an attack).

So yes, the server and client both have to make some assumptions
about how the pubkey distributed via WKD is to be used.
A published pubkey via WKD simplified means:
 * Please use the following pubkey to encrypt a message to me.
 * You can use this pubkey to check a signature.
(but I may have other pubkeys and you may decide otherwise
 with a good reason.)


Regards,
Bernhard

-- 
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/20221212/d7c91dd4/attachment.sig>