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

[Andrew Gallagher]

On 15 Dec 2022, at 12:02, Dashamir Hoxha <dashohoxha at gmail.com> wrote:
> 
> On Thu, Dec 15, 2022 at 12:53 PM Andrew Gallagher <andrewg at andrewg.com <mailto:andrewg at andrewg.com>> wrote:
>> On 15 Dec 2022, at 11:44, Dashamir Hoxha via Gnupg-devel <gnupg-devel at gnupg.org <mailto:gnupg-devel at gnupg.org>> wrote:
>>> 
>>> When the user publishes a new public key on WKD, it is stored on the "/hu/" directory, same as before, but in addition it is also stored on the "/id/" directory. The same thing is done when another public key replaces the old one, and now on the "/hu/" directory there is only one (corresponding) key, but on the "/id/" directory there are two (corresponding) keys, the new one and the old one.
>> 
>> I’d suggest something along the lines of `archive` rather than `id`, since both directories are referenced by the hashed userid but one contains current info and the other secondary or historical info.
> 
> The name "/archive/" certainly makes sense and would be a good one. But the file names in this directory do not correspond to the hashed userid, but to the key ID. So, each file in this directory contains only one public key, and there are several files (public keys) that correspond to the same userid. This could make the management of this directory easier (compared to having several keys in one file).

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.

(With the keyservers this is not an issue because you can search by subkey-id)

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

A

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