WKD: returns only one pubkey (and why)

Simon Josefsson simon at josefsson.org
Thu Dec 15 09:11:24 CET 2022


Erich Eckner via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> On Tue, 13 Dec 2022, Simon Josefsson via Gnupg-devel wrote:
>
>> 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.
>>
>
> [ ... snip ... ]
>
>> However maybe what we can achieve is that WDK could ALSO cater to the
>> use-case of 2).  What do you think?
>
> just a quick comment: your proposal looks ok to me for WKD - but what
> about WKS? One would need a protocol to remove "old" keys from the
> "all keys" bundle. Does WKS already come with a mechanism for that? Or
> does it currently rely on replacing the old key with a new one?

I'm not familiar with WKS so I don't have an opinion -- it looks like
WKS was tailored towards the use-case 1) above, and I'm not sure a
WKS-like protocol is useful for the use-case of 2) at all.  It is not
important for me at least: I just want to self-publish all trusted keys
for my email address and have a protocol to specify that people should
trust them, if they trust the DNS hierarchy and the HTTPS retrieval
mechanism.  I'm not using WKS.  I'm hoping WDK could be this, but
otherwise a separate protocol is needed with that semantics.  Complexity
is a always a security risk, so I could see the argument to declare this
out of scope for WDK, but I could also easily see some small changes
made to support this scenario.

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


More information about the Gnupg-devel mailing list