Update keys.gnupg.net?

[Phil Pennock]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210729/5bf6e14e/attachment.sig>