Mailing List Archive

WKD: returns only one pubkey (and why)
Hi David,

saw that you had a question about WKD in your blog:
https://sleepmap.de/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168/

You write:
gpg --locate-keys dave@sleepmap.de
The above only returns the new key [..], but not the old [..].
It is entirely opaque to the user as to why.

The reason is that WKD only allows
for returning one active public key.

https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-15#name-key-discovery
has
The HTTP GET method MUST return the binary representation of the OpenPGP
key for the given mail address.
[..]
a server may return revoked keys in addition to a new key.

The use of _the_ and _a_ key shows that only one public key is to be returned.
This makes sense because the idea is that a client can directly use the key
for encryption without asking the user for choice.
It seems that the version of sequoia-pgp you were using in April does not
implement the WKD draft correctly
by providing and downloading more than one pubkey.
This may have added to your confusion.

Nontheless the intentions could be written more explicit in the WKD draft,
which I have meanwhile suggested to the author.

Regards,
Bernhard
ps.: BTW there is a new group of synchronised pubkey servers, since a while,
e.g. see https://social.tchncs.de/@ber/107008659842900171

--
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Hi Bernhard,

On 2022-12-09 09:59:59 (+0100), Bernhard Reiter wrote:
> saw that you had a question about WKD in your blog:
> https://sleepmap.de/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168/
>
> The reason is that WKD only allows for returning one active public
> key.

I believe that to be a problematic assumption. More on that below.

> a server may return revoked keys in addition to a new key.

And there would be a lot of reasons as to why that is good:
If I cycle out an old key I want to establish the chain of trust between
two keys using cross-signatures. Both (revoked and active) keys need to
be returned for someone else to be able to check the chain of trust
between a revoked and an active key.

We currently use this mechanism in Arch Linux's WKD [1], as we must
provide the signatures and revocation of signatures of main signing keys
on packager keys not only for active but also for inactive keys
(otherwise systems would be able to trust and install packages signed by
distrusted keys).

In regards to returning multiple active keys and looking at the
following text from the draft, I believe that the assumption is
problematic:

> The HTTP GET method MUST return the binary representation of the
> OpenPGP key for the given mail address.

If someone loses access to their private key material and can no longer
revoke their key, then we must provide both that key and any newer key.
In this case there may be two (or more) keys active for a UID at the
same time (for a while or indefinitely) and the old one should remain
available.

It is also possible to have circumstances in which it is desirable to be
able to provide two (or more) active keys for a given UID, apart from
not being able to revoke an old key.
Again using the example of Arch Linux here: If someone loses access to
their private key material (e.g. key only available on hardware token)
or plainly wants to switch from one key to another, they can not revoke
that key right away, as there are still (hundreds of) software packages
available in the repositories, signed with that key.
Only after establishing a new key and rebuilding all packages with that
key (or another verifiable key), the old key can be revoked/ signatures
on that key can be revoked.
In the meantime, two active keys *must* exist at the same time and the
old key, once revoked, must still be available via WKD, as that is the
only place where we have full control over the data ourselves.

> This makes sense because the idea is that a client can directly use
> the key for encryption without asking the user for choice.

The client using a pubkey (e.g. a mail program) should have the user
choose which key to use once retrieved, if there are multiple active
ones, else choose the one that is active.
However, the tooling retrieving the key material should not choose for
the user which key to grab, but grab all of the available ones for a
given UID.

Conflating both the retrieval of PGP public keys and the decision making
process of which public key to use, without allowing configuration does
not only sound unflexible, but also does not allow for the above
mentioned use-cases to be covered. This is a problem.

> It seems that the version of sequoia-pgp you were using in April does
> not implement the WKD draft correctly by providing and downloading
> more than one pubkey.
> This may have added to your confusion.

If the client implementing WKD retrieval already makes implicit choices
about which key to retrieve, then that is not correct IMHO, as it also
makes assumptions about how the retrieved keys are to be used further.

In your described scenario, we would not be able to use WKD in a
validation scenario for Arch Linux at all and additional keys besides
the currently active (of which there could be several at a given time
and from your notes above it would be unclear to me which exact key
would be returned) would not be supported.

If what you describe above is indeed intended behavior, then I am
wondering what the purpose of WKD is, if it can not be fully used for
key discovery. It would sound as if PGP + WKD would not be a desirable
scenario for Linux distributions to rely on.

> Nontheless the intentions could be written more explicit in the WKD
> draft, which I have meanwhile suggested to the author.

As stated above, I believe that retrieving *all* active keys is what
should be done instead.

> Regards,
> Bernhard
> ps.: BTW there is a new group of synchronised pubkey servers, since a while,
> e.g. see https://social.tchncs.de/@ber/107008659842900171

Thanks for pointing them out.

At least for the Arch Linux infrastructure we have completely migrated
away from relying on external keyservers and maintain a curated keyring.
The amount of issues we had with them (some don't provide signatures,
some don't provide specific key types, others don't provide the pubkeys
unless someone acknowledged them, some are only sparsely available, keys
are prone to signature poisoning attacks, etc.) did not justify their
use.

Personally I only publish to keys.openpgp.org and keyserver.ubuntu.com
apart from WKD by now, as they seem reasonably large, publicly known and
available.

Best,
David

[1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/

--
https://sleepmap.de
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Hi David,

Am Freitag 09 Dezember 2022 13:38:01 schrieb David Runge:
> > The reason is that WKD only allows for returning one active public
> > key.
>
> I believe that to be a problematic assumption.

it can be discussed of course if WKD can be improved.
But do we agree that the current version-15 only allows
one non-revoked key to be delivered?

(I'll probably read and respond to the rest of your email next week.)

Regards,
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On 9 Dec 2022, at 12:38, David Runge <dave@sleepmap.de> wrote:
>
> In regards to returning multiple active keys and looking at the
> following text from the draft, I believe that the assumption is
> problematic:
>
>> The HTTP GET method MUST return the binary representation of the
>> OpenPGP key for the given mail address.
>
> If someone loses access to their private key material and can no longer
> revoke their key, then we must provide both that key and any newer key.
> In this case there may be two (or more) keys active for a UID at the
> same time (for a while or indefinitely) and the old one should remain
> available.

If you have lost the private key material for a key, you probably should not publish it on WKD, as doing so would only encourage people to encrypt to it. WKD is a key-discovery protocol for email encryption, it is not a general-purpose keyserver replacement.

> Again using the example of Arch Linux here: If someone loses access to
> their private key material (e.g. key only available on hardware token)
> or plainly wants to switch from one key to another, they can not revoke
> that key right away, as there are still (hundreds of) software packages
> available in the repositories, signed with that key.

WKD is not useful for verifying signatures, as it does not support key discovery by fingerprint, only by email. In order to verify an arbitrary signature you must either look up the key by fingerprint on a keyserver that supports it, or distribute a trusted-signers keyring in advance, e.g. by installing a keyring package.

A
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On Fri, 09 Dec 2022 17:39:24 +0100,
Andrew Gallagher via Gnupg-devel wrote:
> WKD is not useful for verifying signatures, as it does not support key discovery by fingerprint, only by email. In order to verify an arbitrary signature you must either look up the key by
> fingerprint on a keyserver that supports it, or distribute a trusted-signers keyring in advance, e.g. by installing a keyring package.

A signature can include the 'Signer's User ID' subpacket. If that is
included in the signature, then it is possible to use WKD to lookup
the certificate.

https://www.rfc-editor.org/rfc/rfc4880#section-5.2.3.22

Further, it makes sense to follow up a key server lookup with other
lookups like WKD to make it harder for an attacker to withhold some of
the certificate (e.g., a revocation).

Neal

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
WKD: returns only one pubkey (and why) [ In reply to ]
Hi David,

Am Freitag 09 Dezember 2022 13:38:01 schrieb David Runge:
> > WKD only allows for returning one active public key.
>
> I believe that to be a problematic assumption. More on that below.

thanks for sharing your crypto use cases from Arch Linux
and your feedback how the current WKD contributes to solve them.
WKD and other aspects of OpenPGP can be improved, my first step
is understanding of the alternatives and discussing them.

In this email I respond to what WKD aims for:

The design goal of WKD as it is (please see the question in my other email):
Establish some minimal trust so that I can encrypt at the first message
exchange, and hereby improve the usability of the end to end crypto
functionality. The old user experience has been criticised rightfully
for making it too hard for users to profit from some basic security
attributes. You can read up quite a few of the considerations and arguments
at
https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept
https://wiki.gnupg.org/AutomatedEncryption

In the regular cases, user should not have to think about crypto and key
pairs. And if they have, the only for important cases (e.g. an attack).

So yes, the server and client both have to make some assumptions
about how the pubkey distributed via WKD is to be used.
A published pubkey via WKD simplified means:
* Please use the following pubkey to encrypt a message to me.
* You can use this pubkey to check a signature.
(but I may have other pubkeys and you may decide otherwise
with a good reason.)


Regards,
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On Mon, Dec 12, 2022 at 11:48 AM Bernhard Reiter <bernhard@intevation.de>
wrote:

>
> In this email I respond to what WKD aims for:
>
> The design goal of WKD as it is (please see the question in my other
> email):
> Establish some minimal trust so that I can encrypt at the first message
> exchange, and hereby improve the usability of the end to end crypto
> functionality.


The way that I understand WKD (and how I explain it in my presentations) is
that it is a way to publish your public keys (share them with your
contacts). It is an alternative (and replacement) to the keyserver
infrastructure. It is preferred and recommended over the keyservers, since
those have some well-known problems. Also it is better than public key
exchange by email attachments, since you publish only once and it can be
discovered by the clients automatically.

Maybe your definition is the same as this one, but formulated differently.

On the other hand, if "being a replacement for keyservers" is not one of
the aims of WKD, I think that it should become. My opinion is that it *can*
be a replacement for keyservers.

Regards,
Dashamir
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On 12 Dec 2022, at 13:01, Dashamir Hoxha via Gnupg-devel <gnupg-devel@gnupg.org> wrote:
>
> On the other hand, if "being a replacement for keyservers" is not one of the aims of WKD, I think that it should become. My opinion is that it *can* be a replacement for keyservers.
>

WKD is a *partial* replacement for *some* keyserver use cases. It does not cover the following:

* Search by fingerprint
* Non-email User IDs

In addition, only the email domain owner can set up a WKD server, so it will likely never be useful for e.g. GMail addresses.

A
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Hey Bernhard and list,

On 09.12.22 09:59, Bernhard Reiter wrote:
> The use of _the_ and _a_ key shows that only one public key is to be returned.
> This makes sense because the idea is that a client can directly use the key
> for encryption without asking the user for choice.

I generally agree with this goal. Allowing one address to bind to
multiple certificates places a burden on client implementations to make
a choice, and folks who work more on the backend side tend to
underestimate this in my experience. That is the reason why for
keys.openpgp.org we decided to follow WKD and return exactly zero or one
certificates per address.

However, relatedly we have a new OpenPGP version (probably v6?) on the
horizon, and will soon face the issue of migrating users and keys. And
that will likely mean supporting at least two certificates (v4+v6)
side-by-side for the same address.

It's not yet clear to me what the best way is to do that, but one way or
another certificate discovery mechanisms such as WKD will have to deal
with it.

Cheers

 - V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On Mon, Dec 12, 2022 at 3:59 PM Andrew Gallagher <andrewg@andrewg.com>
wrote:

>
> WKD is a *partial* replacement for *some* keyserver use cases.
>

True. But email communication is the most important use case, in my
opinion.

In addition, only the email domain owner can set up a WKD server, so it
> will likely never be useful for e.g. GMail addresses.
>

If WKD becomes popular and users need it, GMail can implement it, I believe.

Dashamir
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Hi Vincent,

Am Montag 12 Dezember 2022 17:37:16 schrieb Vincent Breitmoser via
Gnupg-devel:
> However, relatedly we have a new OpenPGP version (probably v6?) on the
> horizon,

will this be incompatible to old package versions and why?
(Sorry could not resist, see my other email).

> and will soon face the issue of migrating users and keys. And
> that will likely mean supporting at least two certificates (v4+v6)
> side-by-side for the same address.

Another solution for WKD could be to wait with the migration until a large
majority of implementations can deal with the new format and then still
deliver one active pubkey.

Best,
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Hi Dashamir,

Am Montag 12 Dezember 2022 14:01:28 schrieb Dashamir Hoxha via Gnupg-devel:
> The way that I understand WKD (and how I explain it in my presentations) is
> that it is a way to publish your public keys (share them with your
> contacts). It is an alternative (and replacement) to the keyserver
> infrastructure.

then it is good that we have this discussion as a reminder:
The current WKD draft-15 (and all previous drafts as far as I remember)
allow only one active pubkey to be returned.

Whatever WDK Can be in the future (which is to be discussed),
as long as it is one pubkey, I hope we explain and implement it like this.
(Otherwise we risk other problems.)

Regards
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Bernhard Reiter <bernhard@intevation.de> writes:

> Hi Dashamir,
>
> Am Montag 12 Dezember 2022 14:01:28 schrieb Dashamir Hoxha via Gnupg-devel:
>> The way that I understand WKD (and how I explain it in my presentations) is
>> that it is a way to publish your public keys (share them with your
>> contacts). It is an alternative (and replacement) to the keyserver
>> infrastructure.
>
> then it is good that we have this discussion as a reminder:
> The current WKD draft-15 (and all previous drafts as far as I remember)
> allow only one active pubkey to be returned.
>
> Whatever WDK Can be in the future (which is to be discussed),
> as long as it is one pubkey, I hope we explain and implement it like this.
> (Otherwise we risk other problems.)

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

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?

If people who work on WDK find it acceptable to cater to people wanting
the semantics of 2) while still supporting the use-case of 1) how about
specifying that a plural-version of the URL returns all keys? So let's
assume we have this URL to return one public key only:

https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4

Then we could standardize the following (note plural 's') to return ALL
keys for the given email address:

https://intevation.de/.well-known/openpgpkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4

Alternatively, we could use URL parameters on the first URL like this:

https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4?allkeys

Or perhaps a compromise -- based on the observation that registering
multiple 'well-known' protocols has a cost, and that URL parameters like
'?allkeys' works badly with HTTPS servers serving static content, how
about a URL like this:

https://intevation.de/.well-known/openpgpkey/allkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4

This would signal that the server should return all known keys
associated with a particular email-address.

While migrating to new keys is a complicated matter, at least this
allows WDK to play a part of this by serving multiple keys for the same
email address.

/Simon
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On Tue, 13 Dec 2022, Simon Josefsson via Gnupg-devel wrote:

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

[ ... snip ... ]

> However maybe what we can achieve is that WDK could ALSO cater to the
> use-case of 2). What do you think?

just a quick comment: your proposal looks ok to me for WKD - but what
about WKS? One would need a protocol to remove "old" keys from the "all
keys" bundle. Does WKS already come with a mechanism for that? Or does it
currently rely on replacing the old key with a new one?

[ ... snip ... ]

>
> /Simon
>

regards,
Erich


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On Tue, Dec 13, 2022 at 1:59 PM Simon Josefsson via Gnupg-devel <
gnupg-devel@gnupg.org> wrote:

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

The second case, as you describe it, seems to be orthogonal to the first
one, in the sense that they are independent of each-other. So, it can be
implemented as a separate protocol. But probably it makes more sense to
implement it as an extension of the current WKD protocol.

specifying that a plural-version of the URL returns all keys? So let's
> assume we have this URL to return one public key only:
>
>
> https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4
>
> Then we could standardize the following (note plural 's') to return ALL
> keys for the given email address:
>
>
> https://intevation.de/.well-known/openpgpkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4
>
> Alternatively, we could use URL parameters on the first URL like this:
>
>
> https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4?allkeys
>
> Or perhaps a compromise -- based on the observation that registering
> multiple 'well-known' protocols has a cost, and that URL parameters like
> '?allkeys' works badly with HTTPS servers serving static content, how
> about a URL like this:
>
>
> https://intevation.de/.well-known/openpgpkey/allkeys/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4


Does it make sense to look for a public key by its id? I mean something
like this:

https://intevation.de/.well-known/openpgpkey/id/847FC5C4337D9CDBD473B7A60967FD258D6414F9

There are two differences with the current well-known url:
1. Instead of "/hu/" (which means hashed-userid), there is "/id/" (which
means the key id).
2. Instead of "it5sewh54rxz33fwmr8u6dy4bbz8itz4" which is the hash of
"alice" (in case that the userid is "alice@intevation.de"), there is
"847FC5C4337D9CDBD473B7A60967FD258D6414F9" which is the id of the key.

In this case a client can easily ask for the public key that is needed to
verify a certain signature.
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.

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.

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.

Dashamir
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On Tue, Dec 13, 2022 at 5:54 PM Erich Eckner via Gnupg-devel <
gnupg-devel@gnupg.org> wrote:

>
> > However maybe what we can achieve is that WDK could ALSO cater to the
> > use-case of 2). What do you think?
>
> just a quick comment: your proposal looks ok to me for WKD - but what
> about WKS? One would need a protocol to remove "old" keys from the "all
> keys" bundle. Does WKS already come with a mechanism for that? Or does it
> currently rely on replacing the old key with a new one?
>

As far as I understand, WKS is optional. It is one of the ways to build and
manage a WKD. But you can also build a WKD manually, or use a web form
(with authentication) where users can submit their key, etc.
So, despite the way that WKS works, it cannot be an obstacle for the second
use case.
Can WKS be extended to cover the second use case? Maybe not; but it doesn't
have to.

Dashamir
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On Dienstag, 13. Dezember 2022 22:32:59 CET Dashamir Hoxha via Gnupg-devel
wrote:
> Does it make sense to look for a public key by its id?

For WKD? No, it doesn't. For (at least) two reasons:
a) A major idea of WKD is that the owner of a domain is trustworthy and
therefore you can put initial trust in the keys retrieved for email addresses
for this domain.
b) How would you know which of the thousands (millions?) of domains to ask for
the key by id?

WKD is not a replacement for keyservers. It's an addition which eases the
lookup of encryption keys by email address.

Regards,
Ingo
Re: WKD: returns only one pubkey (and why) [ In reply to ]
On 13 Dec 2022, at 21:32, Dashamir Hoxha via Gnupg-devel <gnupg-devel@gnupg.org> 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.

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

> 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… ;-)

A
Re: WKD: returns only one pubkey (and why) [ In reply to ]
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
Re: WKD: returns only one pubkey (and why) [ In reply to ]
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
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Erich Eckner via Gnupg-devel <gnupg-devel@gnupg.org> writes:

> On Tue, 13 Dec 2022, Simon Josefsson via Gnupg-devel wrote:
>
>> 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.
>>
>
> [ ... snip ... ]
>
>> However maybe what we can achieve is that WDK could ALSO cater to the
>> use-case of 2). What do you think?
>
> just a quick comment: your proposal looks ok to me for WKD - but what
> about WKS? One would need a protocol to remove "old" keys from the
> "all keys" bundle. Does WKS already come with a mechanism for that? Or
> does it currently rely on replacing the old key with a new one?

I'm not familiar with WKS so I don't have an opinion -- it looks like
WKS was tailored towards the use-case 1) above, and I'm not sure a
WKS-like protocol is useful for the use-case of 2) at all. It is not
important for me at least: I just want to self-publish all trusted keys
for my email address and have a protocol to specify that people should
trust them, if they trust the DNS hierarchy and the HTTPS retrieval
mechanism. I'm not using WKS. I'm hoping WDK could be this, but
otherwise a separate protocol is needed with that semantics. Complexity
is a always a security risk, so I could see the argument to declare this
out of scope for WDK, but I could also easily see some small changes
made to support this scenario.

/Simon
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Hi Simon,

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

> I'm not familiar with WKS so I don't have an opinion -- it looks like
> WKS was tailored towards the use-case 1) above, and I'm not sure a

Right. I think that it is in general not a good idea to have several
keys for the same mail address. How should a user know which key use
for a given mail address to use. A use case would be to help migrating
to a new public key algorithm, like we did with ed25519 in the past. In
that case having two entirely separate keys for the same mail address
makes sense.

> WKS-like protocol is useful for the use-case of 2) at all. It is not
> important for me at least: I just want to self-publish all trusted keys
> for my email address and have a protocol to specify that people should

Actually you can do this, but we don't have the tooling to upload such a
ket without manual intervention. Here is a test case:

I created an rsa1024 test key for dewey@test.gnupg.org, exported it in
binary format and then added it to the already existing key for
dewey@test.gnupg.org on the server:

$ gpg-wks-client --print-wkd-hash dewey@test.gnupg.org
1g8totoxbt4zf6na1sukczp5fiewr1oe dewey@test.gnupg.org

$ cat newtestkey.gpg >> \
/var/www/all/test.gnupg.org/htdocs/.well-known/openpgpkey/hu/1g8totoxbt4zf6na1sukczp5fiewr1oe

Then on the client you can test this:

$ gpg --locate-external-key -v dewey@test.gnupg.org
gpg: connection to the dirmngr established
gpg: pub ed25519/D19D22B06EE78668 2016-06-28 dewey@test.gnupg.org
gpg: key D19D22B06EE78668: public key "dewey@test.gnupg.org" imported
gpg: pub rsa1024/5CEC38D7F995FB4E 2023-01-26 dewey@test.gnupg.org
gpg: key 5CEC38D7F995FB4E: public key "dewey@test.gnupg.org" imported
gpg: Total number processed: 2
gpg: imported: 2
gpg: auto-key-locate found fingerprint 64944BC035493D929EF2A2B9D[..]
gpg: automatically retrieved 'dewey@test.gnupg.org' via WKD
pub ed25519 2016-06-28 [SC] [expires: 2030-01-01]
64944BC035493D929EF2A2B9D19D22B06EE78668
uid [ unknown] dewey@test.gnupg.org
sub cv25519 2016-06-28 [E] [expired: 2018-11-26]
sub cv25519 2018-08-28 [E] [expired: 2021-08-27]

$ gpg -k dewey@test.gnupg.org
pub ed25519 2016-06-28 [SC] [expires: 2030-01-01]
64944BC035493D929EF2A2B9D19D22B06EE78668
uid [ unknown] dewey@test.gnupg.org

pub rsa1024 2023-01-26 [SC] [expires: 2025-01-25]
382C8F84FB9FE0F89E61B3045CEC38D7F995FB4E
uid [ unknown] dewey@test.gnupg.org
sub rsa1024 2023-01-26 [E]


Both keys have been retrieved (filtered to have only the requested user
id) and the best matching key has been listed. With an implementation
w/o support for ed25519 the RSA key would have been listed.

So far with the theory and here comes the bug: There is no valid encryption
subkey and thus --locate-external-key should indeed list the rsa key.
See https://dev.gnupg.org/T6358 .



Shalom-Salam,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Hi Werner,

Am Donnerstag 26 Januar 2023 09:42:24 schrieb Werner Koch via Gnupg-devel:
> > I just want to self-publish all trusted keys
> > for my email address and have a protocol to specify that people should
>
> Actually you can do this, but we don't have the tooling to upload such a
> ket without manual intervention. Here is a test case:

> Then on the client you can test this:

> Both keys have been retrieved

for my understanding, this technical test case
tests something that is outside the specification of
https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-15#name-key-discovery
?
(the current specification, as cited in the start of the discussion)

> (filtered to have only the requested user
> id) and the best matching key has been listed. With an implementation
> w/o support for ed25519 the RSA key would have been listed.
>
> So far with the theory and here comes the bug: There is no valid
> encryption subkey and thus --locate-external-key should indeed list the rsa
> key. See https://dev.gnupg.org/T6358 .

Looks like an example how distributing two active keys via WKD
make it more complicated to implement use case 1).
And a for a rollover, just the new public key could be distributed,
so I'd say multiple pubkeys are not necessary for the rollover.

Regards
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Werner Koch via Gnupg-devel <gnupg-devel@gnupg.org> writes:

> Hi Simon,
>
>>>> 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.
>
>> I'm not familiar with WKS so I don't have an opinion -- it looks like
>> WKS was tailored towards the use-case 1) above, and I'm not sure a
>
> Right. I think that it is in general not a good idea to have several
> keys for the same mail address. How should a user know which key use
> for a given mail address to use. A use case would be to help migrating
> to a new public key algorithm, like we did with ed25519 in the past. In
> that case having two entirely separate keys for the same mail address
> makes sense.

I think we can separate the use-cases even further like this:

1) Use WKD to map ONE email address to ONE public key to use for
sending email to that address (i.e., encrypt).

2) Use WKD to find ALL public keys for an email address for verifying
emails from that address (i.e., verify).

These are distinct use-cases and for 1) it is harmful to have more than
one key per e-mail address (which one to use?) but for 2) it is
important to be able to store more than one key per e-mail address.

I don't think we should recommend against doing key rollovers -- forever
keys are bad. I don't think changing e-mail address when you change key
is realistic either. So we have to live with key rollovers for the same
e-mail address.

While we could recommend doing hard-stop key rollovers where you revoke
the earlier key at the same time you migrate to the new key, I don't
think that is a common habit nor am I sure this is even a good idea.
Does anyone think we should recommend that? It does have some
advantages (clear one-to-one mapping between e-mail address and key),
but comes with a high price (flag day). During a key rollover, I think
it makes sense to have both the old and new key be valid, for verifying
signatures, for some time.

Personally, the reason I still have one valid RSA key and one valid
Ed25519 key is that I haven't been able to get my Ed25519 into some
environments, with reasons ranging from use of really old GnuPG
(savannah, now fixed) to key signature requirements (debian), and simple
inertia and time to replace trust settings in various systems.

When I migrate to some post-quantum-safe algorithm, I expect to do a
multi-year key rollover where my current Ed25519 key is still valid as
well. It would be good if the WKD supported both use-cases 1) and 2) or
that we come up with some other solution for use-case 2) if WKD is
intended purely for use-case 1).

In fact, I would be happy to migrate to a post-quantum-safe algorithm
early if I could keep having my Ed25519 fall-back available in case
there is a problem with the new post-quantum-safe algorithm. If it
doesn't work well to have two parallel keys, I would delay switching to
the new algorithm until use of it has become stable. I didn't switch to
Ed25519 until 2019 for this reason, but it would be nice to be able to
experiment with new algorithms more easily.

/Simon
Re: WKD: returns only one pubkey (and why) [ In reply to ]
Simon Josefsson via Gnupg-devel <gnupg-devel@gnupg.org> writes:

> I think we can separate the use-cases even further like this:
>
> 1) Use WKD to map ONE email address to ONE public key to use for
> sending email to that address (i.e., encrypt).
>
> 2) Use WKD to find ALL public keys for an email address for verifying
> emails from that address (i.e., verify).

Let me modify that again, since my main use-cases really isn't e-mail
(where you have the Key ID to search for) but verifying signatures on
free software release tarballs, and using the e-mail adress of the
publisher as the search field, hence I see these use-cases:

1) Use WKD to map ONE email address to ONE public key to use for
sending email to that address (i.e., encrypt).

2) Use WKD to find ALL public keys for an email address for verifying
signatures signed by keys owned by that address (i.e., verify).

To expand even more to get feedback and suggestions on improving this:
my goal is to come up with the best/safest text to write in a software
release on how to verify OpenPGP signatures for the tarball.

Currently I'm using the text below, which recommends 'gpg
--locate-external-key' as the preferred mechanism and normally that uses
WKD and will try to refresh the key from the server (otherwise people
get old cached keys from local key storage). I like the simplicity and
UX of this approach. This mechanism must be able to retrieve all
currently valid keys for a particular e-mail address, otherwise people
will complain not finding the right key.

Second to using the e-mail, maybe retrieving by key id should be
preferred because that is more stable. However there aren't really any
stable working keyid-based OpenPGP key search engines left, are there?
So this method is not reliable. There also were issues with it using
only the first 64-bit of the key id, and I'm not sure this is fixed
(hence the text below uses only that to not give false sense of
security). The --recv-keys parameter behaves different for different
GnuPG versions wrt default keyserver and has been somewhat unreliable in
the last 5 years or so. It also requires additional configuration, most
GnuPG installation doesn't come with a default keyserver URL.

Downloading the key from a given https URL is safe. This is likely to
be the most reliable method right now, but it feels unsatisfying to me.

/Simon

Here are the SHA1 and SHA256 checksums:

52908bfc6e0bb6bbb54de4414e92c29fd13906d7 inetutils-2.4.tar.gz
dq7gwvCVRyhgDVEJVdaXpOwpMkMY54SEjbYG7jwJ42U inetutils-2.4.tar.gz
df64dd4ea0e752a839dd51dd8a6a001c9c7d1e96 inetutils-2.4.tar.xz
F4nWsbGlff4qere1M+6fXf2cv1tZuxuzwmEu0I0PaLI inetutils-2.4.tar.xz

The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify inetutils-2.4.tar.gz.sig

The signature should match the fingerprint of the following key:

pub ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE
uid Simon Josefsson <simon@josefsson.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

gpg --locate-external-key simon@josefsson.org

gpg --recv-keys 51722B08FE4745A2

wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify inetutils-2.4.tar.gz.sig

1 2  View All