<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On 15 Dec 2022, at 12:38, Dashamir Hoxha <dashohoxha@gmail.com> wrote:<br><div><blockquote type="cite"><br class="Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="font-family:Arial,Helvetica,sans-serif">On Thu, Dec 15, 2022 at 1:24 PM Andrew Gallagher <<a href="mailto:andrewg@andrewg.com">andrewg@andrewg.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>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.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Maybe you are right, I don't know enough internal details.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">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.</div></div></div></div></div></blockquote><div><br></div><div>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?</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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. :-)</div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">We should also consider the client that is downloading a key, and try to make it as easy as possible to use this key.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">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?</div></div></div></div></blockquote><br></div>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.<div><br></div><div>A</div><div><br></div></body></html>