'Re: WKD: returns only one pubkey (and why)'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-devel
Subject:    Re: WKD: returns only one pubkey (and why)
From:       Andrew Gallagher via Gnupg-devel <gnupg-devel () gnupg ! org>
Date:       2022-12-14 12:42:57
Message-ID: 7E5B8E93-D7A0-4178-BFC6-EF6F6BD7A3D3 () andrewg ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On 14 Dec 2022, at 11:20, Dashamir Hoxha <dashohoxha@gmail.com> wrote:
> 
> If the signer wants the people to be able to verify his signature, then he can \
> certainly include his ID on the signature. We can rely on this. The client that is \
> trying to verify the signature can find both the key id and the user id, so he can \
> construct a valid well-known url for retrieving the public key.

That's not what I meant by "rely upon". The sender subpacket is not mandatory, \
therefore we must still handle cases where it doesn't exist.

> > > However, if we have such a directory service, then we can just list the url \
> > > where the public key is located, so maybe we don't need a "well-known url" \
> > > format.
> > 
> > 
> > Or we could just serve the key directly from the directory… ;-)
> 
> It is not the same, in my opinion, because you cannot delete the key from a \
> keyserver, but you can delete the key from a web directory (which is under your \
> control).

That depends on the keyserver. You can't delete a key from sks-keysever, but almost \
nobody runs that any more. Other keyservers do implement some form of deletion \
(although the UX currently isn't great).

A hypothetical "indirect" keyserver could send you to the authoritative source; or it \
could just cache the contents of the authoritative source and serve it directly (no \
less trustworthy, and slightly more robust).

A

[Attachment #5 (unknown)]

<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 14 Dec 2022, at 11:20, Dashamir Hoxha \
&lt;dashohoxha@gmail.com&gt; wrote:<br><div><blockquote type="cite"><br><div><div \
dir="ltr"><div class="gmail_quote"><div class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small">If the signer wants the people \
to be able to verify his signature, then he can certainly include his ID on the \
signature. We can rely on this. The client that is trying to verify the signature can \
find both the key id and the user id, so he can construct a valid well-known url for \
retrieving the public \
key.</div></div></div></div></blockquote><div><br></div><div>That's not what I meant \
by "rely upon". The sender subpacket is not mandatory, therefore we must still handle \
cases where it doesn't exist.</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><div><blockquote type="cite"><div><div \
style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:norma \
l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:arial,sans-serif;font-size:small">However, \
if we have such a directory service, then we can just list the url where the public \
key is located, so maybe we don't need a "well-known url" \
format.</div></div></blockquote></div><div><br></div><div>Or we could just serve the \
key directly from the directory… \
;-)</div></div></blockquote><div><br></div><div><div class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small">It is not the same, in my \
opinion, because you cannot delete the key from a keyserver, but you can delete the \
key from a web directory (which is under your \
control).</div></div></div></div></div></blockquote><br></div>That depends on the \
keyserver. You can't delete a key from sks-keysever, but almost nobody runs that any \
more. Other keyservers do implement some form of deletion (although the UX currently \
isn't great).<div><br></div><div>A hypothetical "indirect" keyserver could send you \
to the authoritative source; or it could just cache the contents of the authoritative \
source and serve it directly (no less trustworthy, and slightly more \
robust).<div><br><div>A</div><div><br></div></div></div></body></html>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

[prev in list] [next in list] [prev in thread] [next in thread] 