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

[Andrew Gallagher]

On 15 Dec 2022, at 12:38, Dashamir Hoxha <dashohoxha at gmail.com> wrote:
> 
> On Thu, Dec 15, 2022 at 1:24 PM Andrew Gallagher <andrewg at andrewg.com <mailto:andrewg at andrewg.com>> wrote:
>> I misread your spec - sorry. But this complicates the lookup process. Signatures are often made by subkeys rather than the primary key. Even if the user ID is included as a signature subpacket, you still don’t necessarily know the primary key fingerprint/id. On the other hand, if you’re using WKD for discovery you must already know the user ID - so indexing the archive by hashed-userid requires no extra information.
> 
> Maybe you are right, I don't know enough internal details.
> If it is possible/easy to split a public key into its subkeys, I would still prefer to use a single file for storing each subkey.

But a subkey is meaningless without its primary and userid. An arbitrary key may have both a signing-capable primary and a signing-capable subkey. Does this mean the same material gets stored twice, under the two (sub)key ids? Surely this makes the management more complex, not less?

>> Several keys in one file is how all OpenPGP keyrings work, and concatenation is not a particularly complex operation, so I’m not convinced this is a problem worth solving. :-)
> 
> We should also consider the client that is downloading a key, and try to make it as easy as possible to use this key.
> After all, why should a client download several keys, when it needs only one, and the client already knows the ID of the key that it needs?

We’re not exactly talking gigabytes of data here. We can safely assume that any client capable of verifying OpenPGP signatures also understands keyrings. IMO this is a non-problem.

A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221215/c9aa541c/attachment.html>