[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: Dashamir Hoxha via Gnupg-devel <gnupg-devel () gnupg ! org>
Date: 2022-12-14 11:20:40
Message-ID: CAMucfLwozinVhLq+EP0th7qKMafJcd4XLeO1W70+PaKg=NHYDQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Dec 14, 2022 at 11:31 AM Andrew Gallagher <andrewg@andrewg.com>
wrote:
> However I am not sure, can we find out the userids of the key that is used
> to sign? If not, then we cannot infer the domain of the well-known url.
>
>
> See Neal's earlier comment. We can in principle, but only if the signer
> has added that subpacket to their signature, which cannot be relied upon.
>
Thanks for pointing this out. I did see the Neal's message but did not
grasp its meaning.
https://lists.gnupg.org/pipermail/gnupg-devel/2022-December/035177.html
Indeed, when we sign something, we can also include the user's id with the
option "--sender":
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Key-related-Options.html
For example: `gpg --sign -a --sender alice@example.com file-to-be-signed`
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.
In this case we might need a directory service to lookup the userid(s) that
> are associated with a certain key id (think of it like a phone book -- you
> know the phone number and you can find the name of its owner). This
> directory service might be based on blockchains, or it might be a modified
> (simplified?) version of the current keyservers.
>
>
> If you think keyservers are prone to abuse and spam, you *do not* want a
> blockchain.
>
You are right. A blockchain may not be able to ensure even the uniqueness
of the published key (several records for the same key id, and you don't
know which one is valid). Probably other problems as well.
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).
Dashamir
[Attachment #5 (text/html)]
<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 Wed, Dec 14, 2022 at 11:31 AM \
Andrew Gallagher <<a href="mailto:andrewg@andrewg.com">andrewg@andrewg.com</a>> \
wrote:</span></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><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 \
I am not sure, can we find out the userids of the key that is used to sign? If not, \
then we cannot infer the domain of the well-known \
url.</div></div></blockquote><div><br></div><div>See Neal's earlier comment. We can \
in principle, but only if the signer has added that subpacket to their signature, \
which cannot be relied upon.</div></div></div></blockquote><div><br></div><div \
class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Thanks for \
pointing this out. I did see the Neal's message but did not grasp its \
meaning.</div><div class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small"><a \
href="https://lists.gnupg.org/pipermail/gnupg-devel/2022-December/035177.html">https:/ \
/lists.gnupg.org/pipermail/gnupg-devel/2022-December/035177.html</a><br></div><div \
class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small"><br></div><div \
class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Indeed, \
when we sign something, we can also include the user's id with the option \
"--sender":</div><div class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small"><a \
href="https://www.gnupg.org/documentation/manuals/gnupg/GPG-Key-related-Options.html"> \
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Key-related-Options.html</a><br></div><div \
class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small"><br></div><div \
class="gmail_default" style="font-family:arial,sans-serif;font-size:small">For \
example: `gpg --sign -a --sender <a \
href="mailto:alice@example.com">alice@example.com</a> file-to-be-signed`</div><div \
class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small"><br></div><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 class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small"><br></div><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">In \
this case we might need a directory service to lookup the userid(s) that are \
associated with a certain key id (think of it like a phone book -- you know the phone \
number and you can find the name of its owner). This directory service might be based \
on blockchains, or it might be a modified (simplified?) version of the current \
keyservers.</div></div></blockquote><div><br></div>If you think keyservers are prone \
to abuse and spam, you *do not* want a \
blockchain.<br></div></div></blockquote><div><br></div><div><div \
class="gmail_default" style="font-family:arial,sans-serif;font-size:small">You are \
right. A blockchain may not be able to ensure even the uniqueness of the published \
key (several records for the same key id, and you don't know which one is valid). \
Probably other problems as well.</div></div><div><br></div><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 \
class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small"><br></div><div \
class="gmail_default" \
style="font-family:arial,sans-serif;font-size:small">Dashamir</div></div></div></div>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic