Mailing List Archive

Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
Am Sonntag 04 Juli 2021 17:43:46 schrieb Werner Koch via Gnupg-devel:
>   * Change the default keyserver to keyserver.ubuntu.com.  This is a
>     temporary change due to the shutdown of the SKS keyserver pools.

Does it make sense to change the list of servers behind
keys.gnupg.net as well?

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html
"The keyserver hkp://keys.gnupg.net uses round robin DNS to give a different
keyserver each time you use it."

Bernhard

--
www.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, Dr. Jan-Oliver Wagner
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
On Dienstag, 13. Juli 2021 10:15:17 CEST Bernhard Reiter wrote:
> Am Sonntag 04 Juli 2021 17:43:46 schrieb Werner Koch via Gnupg-devel:
> > * Change the default keyserver to keyserver.ubuntu.com. This is a
> > temporary change due to the shutdown of the SKS keyserver pools.
>
> Does it make sense to change the list of servers behind
> keys.gnupg.net as well?

Already changed (in the 2.2 branch):
https://dev.gnupg.org/source/gnupg/change/STABLE-BRANCH-2-2/dirmngr/server.c;47c4e3e00a7ef55f954c14b3c237496e54a853c1

> https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.
> html "The keyserver hkp://keys.gnupg.net uses round robin DNS to give a
> different keyserver each time you use it."

This needs to be updated. DNS isn't used anymore. See comment in code:
https://dev.gnupg.org/source/gnupg/browse/STABLE-BRANCH-2-2/dirmngr/server.c$2127

Regards,
Ingo
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
On 2021-07-13 at 18:26 +0200, Ingo Klöcker wrote:
> On Dienstag, 13. Juli 2021 10:15:17 CEST Bernhard Reiter wrote:
> > Does it make sense to change the list of servers behind
> > keys.gnupg.net as well?

> > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.
> > html "The keyserver hkp://keys.gnupg.net uses round robin DNS to give a
> > different keyserver each time you use it."
>
> This needs to be updated. DNS isn't used anymore. See comment in code:
> https://dev.gnupg.org/source/gnupg/browse/STABLE-BRANCH-2-2/dirmngr/server.c$2127

GnuPG has many released versions, which various distributions are using,
which will still be using the public hostname.

Updating what the DNS points at will benefit many people just using the
defaults, with their old distribution. Not updating is not likely to
encourage them to update, it will just reinforce the perception that PGP
is broken and a different ecosystem should be used.

It's the classic dilemma, "product" or "service". The hostname is part
of a long-term service which needs to cater to more than the current
product. It's probably unfunded, but it's also just some DNS.

What it probably needs is a decent stable pool to point to, or something
else which keeps it from being a weekly task of asking the software
maintainers to update DNS yet again.


In case it helps: a decade ago, I wrote an SKS spider for building a
graph of all the available servers, after a while, I rewrote from Python
to Go, and that can be found at
<https://github.com/philpennock/sks_spider>; it was a weekend rewrite
and is not clean Go and is not a good example of the language, but if
anyone wants a basis for getting started with building a graph for
publishing DNS records, this one works.

I had DNS zone-building running via cron which pulled from the API
exposed by this code. I was first to implement a few features which led
Kristian to add/improve the "official" sks-keyservers DNS logic, but I
never tried to get anyone to use my hostnames and kept them on
deliberately annoying hostnames, so as to not split people: it was
friendly feature competition, not service usage competition.

So if anyone wants to start up a DNS pool which spiders and
auto-filters, etc, then the above might be a reasonable starting point;
and even if it's not, seeing the filtering logic might at least help you
figure out what to do differently.

-Phil

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
On Dienstag, 13. Juli 2021 22:09:25 CEST Phil Pennock wrote:
> On 2021-07-13 at 18:26 +0200, Ingo Kl?cker wrote:
> > On Dienstag, 13. Juli 2021 10:15:17 CEST Bernhard Reiter wrote:
> > > Does it make sense to change the list of servers behind
> > > keys.gnupg.net as well?
> > >
> > > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Opti
> > > ons. html "The keyserver hkp://keys.gnupg.net uses round robin DNS to
> > > give a different keyserver each time you use it."
> >
> > This needs to be updated. DNS isn't used anymore. See comment in code:
> > https://dev.gnupg.org/source/gnupg/browse/STABLE-BRANCH-2-2/dirmngr/server
> > .c$2127
>
> GnuPG has many released versions, which various distributions are using,
> which will still be using the public hostname.
>
> Updating what the DNS points at will benefit many people just using the
> defaults, with their old distribution. Not updating is not likely to
> encourage them to update, it will just reinforce the perception that PGP
> is broken and a different ecosystem should be used.

Well, `dig keys.gnupg.net`, `nslookup keys.gnupg.net`, and `ping
keys.gnupg.net` all agree that there is no DNS entry for keys.gnupg.net.
Consequently, *updating* what the DNS points at makes no sense because there
is nothing to update.

Of course, you could argue that the DNS pointers should be re-established to
support those old distributions. But then again, nobody seems to have noticed
that keys.gnupg.net is gone since I don't know when.

Regards,
Ingo
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
Am Mittwoch 14 Juli 2021 09:47:35 schrieb Ingo Klöcker:
> But then again, nobody seems to have noticed
> that keys.gnupg.net is gone since I don't know when.

I've noticed and it isn't that long gone.
(I guess several months, the problem with this is, that keys.gnupg.net
always was not sure to get you to a working server, so you didn't know if it
was a bad server you were getting or keys.gnupg.net not working at all.)

If it wasn't a DNS entry, maybe can can create a round robin one.

Regards,
Bernhard

--
www.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, Dr. Jan-Oliver Wagner
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
On 19/07/2021 09:21, Bernhard Reiter wrote:
> Am Mittwoch 14 Juli 2021 09:47:35 schrieb Ingo Kl?cker:
>> But then again, nobody seems to have noticed
>> that keys.gnupg.net is gone since I don't know when.
>
> I've noticed and it isn't that long gone.
> (I guess several months, the problem with this is, that keys.gnupg.net
> always was not sure to get you to a working server, so you didn't know if it
> was a bad server you were getting or keys.gnupg.net not working at all.)

Indeed. Even with regular spidering of the graph, the sks-keyservers
pools were slow to react to unresponsive servers - and there were
seemingly infinite forms of vague unreliability that didn't trigger
removal from the pool. DNS is too clunky for load balancing. And that's
before considering the (legal and other) issues arising from using your
own domain name to front a service that you have no control over.

> If it wasn't a DNS entry, maybe can can create a round robin one.

I'd strongly caution against DNS round robin for the aforementioned
reasons. Much better to pick a trustworthy, reliable, single (or
properly load-balanced) keyserver and point directly to it.

(If you want to run an actual keyserver that syncs with the rest of the
graph, I'd be happy to help.)

--
Andrew Gallagher
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
On Wed, 14 Jul 2021 09:47, Ingo Klöcker said:

> Well, `dig keys.gnupg.net`, `nslookup keys.gnupg.net`, and `ping
> keys.gnupg.net` all agree that there is no DNS entry for keys.gnupg.net.

I removed the CNAMES along with the last 2.2. release and added a TXT
record:

host -t txt keys.gnupg.net
keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this name, see dirmngr/server.c."

This internal mapping was a consequence of CNAME and pool problems since 2.1.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
Werner Koch via Gnupg-devel <gnupg-devel@gnupg.org> writes:

> On Wed, 14 Jul 2021 09:47, Ingo Kl?cker said:
>
>> Well, `dig keys.gnupg.net`, `nslookup keys.gnupg.net`, and `ping
>> keys.gnupg.net` all agree that there is no DNS entry for keys.gnupg.net.
>
> I removed the CNAMES along with the last 2.2. release and added a TXT
> record:
>
> host -t txt keys.gnupg.net
> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this name, see dirmngr/server.c."
>
> This internal mapping was a consequence of CNAME and pool problems since 2.1.

Should keys.gnupg.net continue to be used or not? What is the best
generic recommendation these days? The announce-gen script in gnulib
[1] still uses '--keyserver keys.gnupg.net', and its output ends up in
many release announcements of GNU projects. Is there anything better
than that? Of course, how to locate PGP keys for a single individual
will differ, but it would be nice if there were a best recommended
approach, which is what keys.gnupg.net has been (is?) as far as I can
tell.

/Simon

https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/announce-gen#n550
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
>>>>> "WK" == Werner Koch <wk@gnupg.org> writes:

WK> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this name, see dirmngr/server.c."

WK> This internal mapping was a consequence of CNAME and pool problems since 2.1.

afaict, that (ie make_keyserver_item()) still points to names under
pool.sks-keyservers.net.

which is gone from dns.

(sks-keyservers.net. still has soa, ns and a, but pool is gone.)

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
On Samstag, 24. Juli 2021 20:32:53 CEST James Cloos via Gnupg-devel wrote:
> >>>>> "WK" == Werner Koch <wk@gnupg.org> writes:
> WK> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this
> name, see dirmngr/server.c."
>
> WK> This internal mapping was a consequence of CNAME and pool problems since
> 2.1.
>
> afaict, that (ie make_keyserver_item()) still points to names under
> pool.sks-keyservers.net.
>
> which is gone from dns.

Yes and no. In master it still points to those names, but in the 2.2 branch,
which the original message in this thread refers to, it has been changed.

Regards,
Ingo
Re: Update keys.gnupg.net? [ In reply to ]
On Fri, 23 Jul 2021 19:45, Simon Josefsson said:

> many release announcements of GNU projects. Is there anything better
> than that? Of course, how to locate PGP keys for a single individual

The new default is the Ubuntu keyserver which seems to be the best
maintained one. There is also the mayfirst server which I use regularly.

keys.gnupg.net was introduced even before the sks pools and allowed to
update the default keyserver for gnupg by changing the zone. However
with the introduction of the sks pools and with TLS a CNAME did not
worked anymore and thus GnuPG was changed to use a hardwired mapping of
keys.gnuypg.net to the SKS pool

Web Key Directory seems to be the best fit but it does not allow to make
use of the Web of Trust. But that is the same for keyservers also
(since some time).


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Update keys.gnupg.net? [ In reply to ]
Werner Koch <wk@gnupg.org> writes:

> On Fri, 23 Jul 2021 19:45, Simon Josefsson said:
>
>> many release announcements of GNU projects. Is there anything better
>> than that? Of course, how to locate PGP keys for a single individual
>
> The new default is the Ubuntu keyserver which seems to be the best
> maintained one. There is also the mayfirst server which I use regularly.
>
> keys.gnupg.net was introduced even before the sks pools and allowed to
> update the default keyserver for gnupg by changing the zone. However
> with the introduction of the sks pools and with TLS a CNAME did not
> worked anymore and thus GnuPG was changed to use a hardwired mapping of
> keys.gnuypg.net to the SKS pool
>
> Web Key Directory seems to be the best fit but it does not allow to make
> use of the Web of Trust. But that is the same for keyservers also
> (since some time).

Yeah, I also came to the conclusion of WKS:

https://gitlab.com/libidn/libidn2/-/issues/98#note_635780242

However --locate-external-keys is a new command, and not even present in
Debian buster. To solve the use-case of refreshing any expired local
keys, the following appears to work:

gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon@josefsson.org

How does GnuPG select which key is shown when running that command?

It used to look like this:

jas@latte:~$ gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon@josefsson.org
gpg: key EDA21E94B565716F: "Simon Josefsson <simon@josefsson.org>" not changed
gpg: key 0664A76954265E8C: "Simon Josefsson <simon@josefsson.org>" not changed
gpg: key D73CF638C53C06BE: "Simon Josefsson <simon@josefsson.org>" not changed
gpg: Total number processed: 3
gpg: unchanged: 3
pub rsa1280 2002-05-05 [SC] [expired: 2014-11-10]
0424D4EE81A0E3D119C6F835EDA21E94B565716F
uid [ expired] Simon Josefsson <simon@josefsson.org>

jas@latte:~$

So it picked my oldest key...

I reordered the keys in my exported file on the server, and now it looks
like this:

jas@latte:~$ gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon@josefsson.org
gpg: key 0664A76954265E8C: "Simon Josefsson <simon@josefsson.org>" not changed
gpg: key D73CF638C53C06BE: "Simon Josefsson <simon@josefsson.org>" not changed
gpg: key EDA21E94B565716F: "Simon Josefsson <simon@josefsson.org>" not changed
gpg: Total number processed: 3
gpg: unchanged: 3
pub rsa3744 2014-06-22 [SC] [expires: 2022-05-17]
9AA9BDB11BB1B99A21285A330664A76954265E8C
uid [ultimate] Simon Josefsson <simon@josefsson.org>
sub rsa2048 2014-06-22 [S] [expires: 2022-05-17]
sub rsa2048 2014-06-22 [E] [expires: 2022-05-17]
sub rsa2048 2014-06-22 [A] [expires: 2022-05-17]

jas@latte:~$

The server has my Ed25519 key first, but still GnuPG is showing my RSA
key anyway.

Could the logic be to show the newest non-expired key?

Alternatively, show short summary output of all retrieved keys. That is
probably the best?

/Simon
Re: Update keys.gnupg.net? [ In reply to ]
On Tue, 27 Jul 2021 11:15, Simon Josefsson said:

> However --locate-external-keys is a new command, and not even present in
> Debian buster. To solve the use-case of refreshing any expired local

Its Debian and they anyway had lots of changes on their own in it.
FWIW: The command is available since 2.2.17 (2019-07-09)

> gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon@josefsson.org

Yep.

> How does GnuPG select which key is shown when running that command?

gpg merges the received key into a possible existing key. You may use
some "--import-options show-only" to avoid that. --locate-key does in
principle the same as if you woould do

gpg -er foo@example.org

and the key for foo@example.org does not exist.

> I reordered the keys in my exported file on the server, and now it looks
> like this:

Ah well, there should be only one key on the server. More are allowed
for key rollover, but we don't have useful maintanence tools for that.

> The server has my Ed25519 key first, but still GnuPG is showing my RSA
> key anyway.

The logic on how gpg considers what the best key to use is a bit
complicated. In case you want to look at it, start at
get_best_pubkey_byname. Note that logic kicks in only if you provide a
mail address.

> Could the logic be to show the newest non-expired key?

That should be the case with --locate-key but not with
--locate-external-key becuase the latter does not look into the local
keystore.

> Alternatively, show short summary output of all retrieved keys. That is
> probably the best?

Well, the idea was to have just one key and use that. What shall one do
if several keys for the same mail address are available and valid?
Encrypt to all these keys?


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Update keys.gnupg.net? [ In reply to ]
Werner Koch via Gnupg-devel <gnupg-devel@gnupg.org> writes:

>> I reordered the keys in my exported file on the server, and now it looks
>> like this:
>
> Ah well, there should be only one key on the server. More are allowed
> for key rollover, but we don't have useful maintanence tools for that.

My key rollover from RSA to Ed25519 seems to take years, due to problems
getting Debian and ftp-upload@gnu to accept my new key. It seems like a
neat thing to have all my keys in there, in case someone wants to verify
old signatures. Is this forbidden? As far as I can tell from wks draft
-12 it is permitted: 'Note that the key may be revoked or expired - it
is up to the client to handle such conditions.'.

Having the order of keys on the server matter for the client was a bit
strange though.

/Simon
Re: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released [ In reply to ]
Am Dienstag 20 Juli 2021 18:07:18 schrieb Werner Koch via Gnupg-devel:
> I removed the CNAMES along with the last 2.2. release and added a TXT
> record:
>
> host -t txt keys.gnupg.net
> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this
> name, see dirmngr/server.c."

But what is with the elder stable releases of GnuPG that are out there on
various platforms and still have keys.gnupg.net configured?

> This internal mapping was a consequence of CNAME and pool problems since
> 2.1.

Best Regards,
Bernhard
--
www.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, Dr. Jan-Oliver Wagner
Re: Update keys.gnupg.net? [ In reply to ]
On Wed, 28 Jul 2021 12:28, Simon Josefsson said:

> My key rollover from RSA to Ed25519 seems to take years, due to problems

Ed25519 is supported since 2.1.0 from 2014 so I wonder why you have a
problem with the key? Still someone using 2.0 or - shudder - 1.4 ?


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Update keys.gnupg.net? [ In reply to ]
ons 2021-07-28 klockan 17:24 +0200 skrev Werner Koch:
> On Wed, 28 Jul 2021 12:28, Simon Josefsson said:
>
> > My key rollover from RSA to Ed25519 seems to take years, due to
> > problems
>
> Ed25519 is supported since 2.1.0 from 2014 so I wonder why you have a
> problem with the key?  Still someone using 2.0 or - shudder - 1.4 ?

Yeah, ftp-upload@gnu and/or Savannah uses GnuPG 1.x and don't support
Ed25519. I think Savannah has been upgraded since last autumn when I
heard this (upload a Ed25519 to Savannah now works), but ftp-upload@gnu
still haven't upgraded as far as I know (I asked them last during
spring). Debian requires signatures for my new key, and I haven't been
travelling lately, and I haven't found two Debian developers locally to
sign it... :-(

/Simon



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Update keys.gnupg.net? [ In reply to ]
On Wed, 28 Jul 2021 17:50, Simon Josefsson said:

> spring). Debian requires signatures for my new key, and I haven't been
> travelling lately, and I haven't found two Debian developers locally to

That's pretty obvious for most of us :-(. Shall we do a video call with
Gniibe and I can vouch for you?


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Update keys.gnupg.net? [ In reply to ]
On 2021-07-28 at 17:24 +0200, Werner Koch via Gnupg-devel wrote:
> Ed25519 is supported since 2.1.0 from 2014 so I wonder why you have a
> problem with the key? Still someone using 2.0 or - shudder - 1.4 ?

Is WKD being designed to only be useful for the next five years, or
should it also be useful when people are trying to migrate to an
algorithm not yet implemented in GnuPG, years from now when WKD is the
ubiquitous infrastructure for pulling keys?

I have both an RSA key and an Ed25519 key. Every time I think I can
just use the Ed25519 key, I encounter a new system where that assumption
fails, so even for $work I ended up having to create an RSA key too.

I've been publishing both. My assumption is "these are the sets of keys
for talking with me; any which is not revoked is fit for use, use
whichever one you can" and that clients will filter out those they can't
use and end up picking one. For `gpg --locate-external-keys` it would
import them all.

The demarcation of responsibility in making choices is that I get to say
"any of these are fit for use, from my point-of-view" and others get to
decide which of those are fit for them.

One day, I expect to have an OpenPGP key where the signature is some
quantum-and-magic-resistant signing system, and to then spend the next
15 years waiting while support for that spreads through various
ecosystems. Client implementations will end up having tiered preference
systems, with quantum-resistant first tier, Ed25519 second tier, etc.

Can we please not restrict WKD to be more inflexible than it has to be?

-Phil
Re: Update keys.gnupg.net? [ In reply to ]
On Thu, 29 Jul 2021 12:52, Phil Pennock said:

> I have both an RSA key and an Ed25519 key. Every time I think I can
> just use the Ed25519 key, I encounter a new system where that assumption
> fails, so even for $work I ended up having to create an RSA key too.

So what you are saying is that there are implementations with Web Key
Directory support but no support for Ed25519?

> ecosystems. Client implementations will end up having tiered preference
> systems, with quantum-resistant first tier, Ed25519 second tier, etc.

I don't think so. This would soon get two complicated. My current idea
for PQC is to have a single algorrithm id describing the first and
second tier with just one identifier (e.g. NTRU, RSA).


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Update keys.gnupg.net? [ In reply to ]
On Sat, Jul 31, 2021 at 6:05 AM Werner Koch via Gnupg-devel
<gnupg-devel@gnupg.org> wrote:
>
> On Thu, 29 Jul 2021 12:52, Phil Pennock said:
>
> > I have both an RSA key and an Ed25519 key. Every time I think I can
> > just use the Ed25519 key, I encounter a new system where that assumption
> > fails, so even for $work I ended up having to create an RSA key too.
>
> So what you are saying is that there are implementations with Web Key
> Directory support but no support for Ed25519?
>
> > ecosystems. Client implementations will end up having tiered preference
> > systems, with quantum-resistant first tier, Ed25519 second tier, etc.
>
> I don't think so. This would soon get two complicated. My current idea
> for PQC is to have a single algorithm id describing the first and
> second tier with just one identifier (e.g. NTRU, RSA).

How about something like X.509 basic constraints?

You would have a structure with a blob in it. The blob could be a RSA
key, Ed25519 key, etc. However, the blob would also have a bit that
could be set as critical. A client can ignore a blob not marked as
critical. A client must fail if a blob is marked as critical but the
client does not understand it.

X.509's basic constraints have the benefit of being forward
compatible. You can keep adding stuff without worry about breaking
down-level clients. The client can skip things it does not understand
that are non-critical. The client will fail if it encounters something
it does not understand that is marked critical.

The client is also free to implement its own set of client side
policies, like rejecting a RSA key and requiring an Ed25519 signing
key. Or a client can choose to ignore something marked as critical
(probably a bad idea, but that's choice for you). I would not worry
too much about client side policies. That's up to the user/client to
choose.

Jeff

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Update keys.gnupg.net? [ In reply to ]
On 2021-07-31 at 12:01 +0200, Werner Koch via Gnupg-devel wrote:
> On Thu, 29 Jul 2021 12:52, Phil Pennock said:
>
> > I have both an RSA key and an Ed25519 key. Every time I think I can
> > just use the Ed25519 key, I encounter a new system where that assumption
> > fails, so even for $work I ended up having to create an RSA key too.
>
> So what you are saying is that there are implementations with Web Key
> Directory support but no support for Ed25519?

No. This was the point of the lead-in paragraph in what I wrote:

} or
} should it also be useful when people are trying to migrate to an
} algorithm not yet implemented in GnuPG, years from now when WKD is the
} ubiquitous infrastructure for pulling keys?

If WKD is assuming that "new enough to support WKD" means "new enough to
support the latest key algorithm which people want to use", then that
assumption will age poorly.

-Phil

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Update keys.gnupg.net? [ In reply to ]
On Tue, 3 Aug 2021 16:53, Phil Pennock said:

> If WKD is assuming that "new enough to support WKD" means "new enough to
> support the latest key algorithm which people want to use", then that
> assumption will age poorly.

Right, however for ed25519 it helds true. We had the same situation
back when we introduced the MDC - we could assume that support for AES
also meant that MDC is supported. In fact MDC was born at the second
AES conference.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.