<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 10:43 AM Bernhard Reiter <<a href="mailto:bernhard@intevation.de">bernhard@intevation.de</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">Am Dienstag 13 Dezember 2022 13:17:53 schrieb Simon Josefsson via Gnupg-devel:<br>
> This thread was useful to me to understand that there really are two<br>
> conflicting desired features here:<br>
><br>
>   1) Use WDK to map ONE email address to ONE public key to use for<br>
>   email.<br>
><br>
>   2) Use WDK to find ALL public keys for an email address.<br>
><br>
> These are really two different use-cases, and as WDK looks now it seems<br>
> it was tailored towards 1) but many people (myself included) use it for<br>
> 2) since that is how you traditionally used OpenPGP keyservers, and<br>
> people (myself included) like that semantics and is not ready to switch<br>
> to the WDK approach of trusting the WDK mapping to produce the ONE key<br>
> to use. <br>
<br>
Thanks for the good summary.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">I would like to add that there are two basic use-cases of OpenPGP:</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">1) encryption</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">2) signature</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">These use-cases have different requirements.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">When we send an encrypted message to an email address, we need to know the most recent public key (only one).</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">For verifying a signature (of an email, package, document, etc) the most recent public key might not be enough, since the signature may be done with an old key.</div></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Another difference is that in the "encryption" use-case we only know the email address (user id), and most probably don't not know the key ID. But in the "signature" use-case we certainly know the key ID, and we may also know the user id (email address), if the signer has included it in the signature.</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">
> I have to admit that I had not understood this difference until <br>
> now, I thought WDK mainly was a key-server-replacement proposal.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">The same for me, but as explained in this thread, WKD was built to facilitate the "encryption" use-case. In this case you know only the mail address, and you need the public key that is the most qualified for sending encrypted messages to this email address. From the email address you (your mail client) can construct a well-known url and can (potentially) find the public key automatically.</div></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">
Given that we want a pubkey exchange even without email provider and email <br>
addresses, the next important thing I see is to improve the keyservers.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">This is certainly good, but not related to WKD.</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">
== Ways to deliver several pubkeys via WKD<br>
Again thanks for the technical ideas.<br>
<br>
Two more ideas:<br>
 a) Allow for several pubkeys to be returned, but indicate which one<br>
    is the "primary" one among the active ones. Could be the order,<br>
    could be something else. However should be easy to use from the client<br>
    side (and is potentially not backwards compatible :/ ).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">I suggested a proposal before (alternative to the Simons' proposals), but it was not described clearly, so let me summarize it again:</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">The idea is that the current WKD well-known url does not change at all, but in addition we add another type of well-known url like this:</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><a href="https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9">https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9</a><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">The public key is located in the directory "/id/", and the name of the file is the same as the ID of the key.</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">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.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Of course, since everything is under user's control, the user may decide to not publish keys on the "/id/" directory, or to make a symbolic link from "/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4" to "/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9", etc. (depending on his use-cases, whether he is using WKD for encryption, for signature verification, or for both).</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">This proposal seems to me easy to be implemented (to build a WKD), and completely backwards compatible with the current version of WKD (the mail clients don't need to change anything at all, and they will still be able to get the public key for encryption).</div></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">Regards,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Dashamir</div></div></div>