Mailing List Archive

On Thu, Dec 15, 2022 at 10:43 AM Bernhard Reiter <bernhard@intevation.de>
wrote:

> Am Dienstag 13 Dezember 2022 13:17:53 schrieb Simon Josefsson via
> Gnupg-devel:
> > This thread was useful to me to understand that there really are two
> > conflicting desired features here:
> >
> > 1) Use WDK to map ONE email address to ONE public key to use for
> > email.
> >
> > 2) Use WDK to find ALL public keys for an email address.
> >
> > These are really two different use-cases, and as WDK looks now it seems
> > it was tailored towards 1) but many people (myself included) use it for
> > 2) since that is how you traditionally used OpenPGP keyservers, and
> > people (myself included) like that semantics and is not ready to switch
> > to the WDK approach of trusting the WDK mapping to produce the ONE key
> > to use.
>
> Thanks for the good summary.
>

I would like to add that there are two basic use-cases of OpenPGP:
1) encryption
2) signature

These use-cases have different requirements.
When we send an encrypted message to an email address, we need to know the
most recent public key (only one).
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.
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.

> I have to admit that I had not understood this difference until
> > now, I thought WDK mainly was a key-server-replacement proposal.
>

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.

Given that we want a pubkey exchange even without email provider and email
> addresses, the next important thing I see is to improve the keyservers.
>

This is certainly good, but not related to WKD.

== Ways to deliver several pubkeys via WKD
> Again thanks for the technical ideas.
>
> Two more ideas:
> a) Allow for several pubkeys to be returned, but indicate which one
> is the "primary" one among the active ones. Could be the order,
> could be something else. However should be easy to use from the client
> side (and is potentially not backwards compatible :/ ).
>

I suggested a proposal before (alternative to the Simons' proposals), but
it was not described clearly, so let me summarize it again:

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:
https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9
The public key is located in the directory "/id/", and the name of the file
is the same as the ID of the key.

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

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

Regards,
Dashamir

Bernhard Reiter <bernhard@intevation.de> writes:

>> I have to admit that I had not understood this difference until
>> now, I thought WDK mainly was a key-server-replacement proposal.
>
> Some history: When WKD was designed in 2016 [1], the old (aka SKS) keyservers
> where not yet in big trouble if I remember correctly, so there was less need
> for case 2).
>
> Another design goal was simplicity (often called "lean" in process speak) to
> allow for an easier uptake. So further uses are were not ruled out, but the
> most important design goal(s) for the main user experience should be reached
> quickly.

Thanks, this helps to understand the driving forces behind things.

>> I have argued before that WDK should be modified to allow returning more
>> than one key. I can see now why that request has not been honored: it
>> breaks the use-case 1) above. I don't think we can or should convince
>> people that the semantics with 1) is bad and should't be specified or
>> implemented. To the contrary: it seems very important to allow the
>> functionality of 1) for simple bootstrapping of encrypted email.
>>
>> However maybe what we can achieve is that WDK could ALSO cater to the
>> use-case of 2). What do you think?
>
> So far I am still makeing up my mind. A few thoughts:
>
> Given that we want a pubkey exchange even without email provider and email
> addresses, the next important thing I see is to improve the keyservers.
> (To allow carrying third party signatures again.)
>
> Being forced to use different channels for other pubkeys, except the current
> active one, has its merits: it may potentially help to detect malice done to
> the email provider's web server infrastructure.
>
> In addition the calculation of trust for several pubkeys has to become better
> in implementations, if not just for cases of key rollover. Also for detecting
> attacks and to cater for different levels of security needs. If there is
> a good calculation of trust, you could get the currently active pubkey and
> then sign others with it, which could be fetched elsewhere (keyserver,
> homepage, etc.). If so, one current pubkey via WKD could be enough to
> jumpstart 2).

I think keyservers are useful, but to me being able to self-publish PGP
keys from your own domain is important: it avoids relying on centralized
key servers. In the old days, centralized key servers worked well
enough so that this wasn't really an issue, but today I think being able
to self-host PGP key discovery is important so we have options.

> == Ways to deliver several pubkeys via WKD
> Again thanks for the technical ideas.
>
> Two more ideas:
> a) Allow for several pubkeys to be returned, but indicate which one
> is the "primary" one among the active ones. Could be the order,
> could be something else. However should be easy to use from the client
> side (and is potentially not backwards compatible :/ ).

Yes -- that seems like a really simple solution. Specify that the FIRST
key is the ONE key to use when the application just wants one key to use
directly. Say that if more than one key is available, the client MAY
import the others too, saving them for future use. This requires
OpenPGP packet parsing in the client, but I'm not sure that is a
problem?

> b) Add an URL somehow (maybe as pubkey user attribute) for the other pubkeys
> to be fetched.

I would like to avoid adding more things to my pubkey's just for this
use-case. My OpenPGP keys cross-certify each other, so that could be
sufficient reason for cross-trust between them, but I can see some
environments where cross-cerifying keys is difficult (say for role-based
keys like security@gnu.org if multiple independent keys for that adress
is valid and used).

/Simon

On 15 Dec 2022, at 11:44, Dashamir Hoxha via Gnupg-devel <gnupg-devel@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.

A

On Thu, Dec 15, 2022 at 12:53 PM Andrew Gallagher <andrewg@andrewg.com>
wrote:

> On 15 Dec 2022, at 11:44, Dashamir Hoxha via Gnupg-devel <
> gnupg-devel@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).

Dashamir

On 15 Dec 2022, at 12:02, Dashamir Hoxha <dashohoxha@gmail.com> wrote:
>
> On Thu, Dec 15, 2022 at 12:53 PM Andrew Gallagher <andrewg@andrewg.com <mailto:andrewg@andrewg.com>> wrote:
>> On 15 Dec 2022, at 11:44, Dashamir Hoxha via Gnupg-devel <gnupg-devel@gnupg.org <mailto:gnupg-devel@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

On Thu, Dec 15, 2022 at 1:24 PM Andrew Gallagher <andrewg@andrewg.com>
wrote:

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

Maybe you are right, I don't know enough internal details.
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.

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

We should also consider the client that is downloading a key, and try to
make it as easy as possible to use this key.
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?

Dashamir

On Donnerstag, 15. Dezember 2022 10:43:06 CET Bernhard Reiter wrote:
> == Ways to deliver several pubkeys via WKD
> Again thanks for the technical ideas.
>
> Two more ideas:
> a) Allow for several pubkeys to be returned, but indicate which one
> is the "primary" one among the active ones. Could be the order,
> could be something else. However should be easy to use from the client
> side (and is potentially not backwards compatible :/ ).
> b) Add an URL somehow (maybe as pubkey user attribute) for the other
> pubkeys to be fetched.

Sounds like you want to use the "Preferred Key Server" signature subpacket for
this.
https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.18

Regards,
Ingo

On Donnerstag, 15. Dezember 2022 12:44:26 CET Dashamir Hoxha via Gnupg-devel
wrote:
> 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:
> https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967
> FD258D6414F9 The public key is located in the directory "/id/", and the name
> of the file is the same as the ID of the key.

You still haven't answered this crucial question:
How do you know that you have to ask intevation.de for the key with the
fingerprint (or key ID) 847FC5C4337D9CDBD473B7A60967FD258D6414F9 if all you
know is the fingerprint (or key ID)?

Regards,
Ingo

On Thu, Dec 15, 2022 at 1:47 PM Ingo Klöcker <kloecker@kde.org> wrote:

>
> You still haven't answered this crucial question:
> How do you know that you have to ask intevation.de for the key with the
> fingerprint (or key ID) 847FC5C4337D9CDBD473B7A60967FD258D6414F9 if all
> you
> know is the fingerprint (or key ID)?
>

I had doubts about this as well, but it was clarified that it is possible
to include the signer's userid in the signature:
https://lists.gnupg.org/pipermail/gnupg-devel/2022-December/035200.html
If you ask me, this should be the default option, because a signature
without a name does not make much sense. The problem might be that a key
may have several userid-s attached to it, and you don't know which one to
use, unless the user tells you.

Basically, the signer should use the option "--sender", like this:
`gpg --sign -a --sender alice@intevation.de file-to-be-signed`
Then the verifier will know both the key ID and the userid (email address
of the signer). From the userid you can derive that the domain of WKD
well-known url is "intevation.de".

This depends on the signer using the option "--sender" when he makes a
signature, but he has to use it if he wants his signature to be verified
automatically through the WKD well-known url (as well as publish his public
keys on the WKD).

Regards,
Dashamir

On 15 Dec 2022, at 12:38, Dashamir Hoxha <dashohoxha@gmail.com> wrote:
>
> On Thu, Dec 15, 2022 at 1:24 PM Andrew Gallagher <andrewg@andrewg.com <mailto:andrewg@andrewg.com>> wrote:
>> 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.
>
> Maybe you are right, I don't know enough internal details.
> 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.

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?

>> 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. :-)
>
> We should also consider the client that is downloading a key, and try to make it as easy as possible to use this key.
> 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?

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.

A