Control: tags 1009311 + wontfix Hi Vincent--
On Mon 2022-04-11 16:18:45 +0200, Vincent Lefevre wrote: > The default https://keys.openpgp.org:443 key server is no longer working: > > $ gpg -v --recv-keys 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4 > gpg: data source: https://keys.openpgp.org:443 > gpg: pub rsa2048/ACF8146CAE8CBBC4 2019-01-02 > gpg: key ACF8146CAE8CBBC4: new key but contains no user ID - skipped > gpg: Total number processed: 1 > gpg: w/o user IDs: 1 > > https://superuser.com/questions/1485213/gpg-cant-import-key-new-key-but-contains-no-user-id-skipped > says: "You are probably using the keys.openpgp.org keyserver, which > has an owner approval system – it will strip all user IDs unless > the owner of the corresponding email address has allowed them to be > published. Try to download the key from elsewhere [...]" > > The consequence is that when I want to check a signature made with > this key, I get: > > gpg: Signature made 2022-04-09T21:49:20 CEST > gpg: using RSA key 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4 > gpg: Can't check signature: No public key Upstream's preferred default keyserver, hkps://keyserver.ubuntu.com runs a hockeypuck installation, which distributes arbitrarily large OpenPGP certificates. That keyserver is vulnerable to flooding attacks (see https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/ for more detail) For example, consider trying to fetch GnuPG upstream (Werner Koch)'s old OpenPGP certificate from the upstream-preferred default keyserver: 0x80615870F5BAD690333686D0F2AD85AC1E42B367 (or try fetching my own expired key 0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6 for that matter). The upstream preferred keyserver will push tens of megabytes to you of flooded key material. Recent versions of GnuPG will discard almost all of that data (gpg's dirmngr defaults to importing self-sigs only so that a flooded certificate doesn't make your local keyring unusable as well), but the transmission alone will still cost the user in terms of bandwidth, latency, and battery life. Anyone who wants to can flood any key on the upstream-preferred default keyserver, just by pushing additional third-party certifications. keys.openpgp.org is significantly more conservative: public key material will show up there, as will revocations and subkey material. but user id information is only distributed if the user has responded to an e-mail feedback request from the operators of keys.openpgp.org confirming their intent to publish the User ID that contains that e-mail address. So we have two choices to compare between: a) a default keyserver that is willing to publish any user ID information, but also permits arbitrarily flooded certificates. b) a default keyserver that only publishes self-signed material, but won't distribute User IDs unless the e-mail account holder has explicitly signalled their intent to publish to that keyserver. Given the bandwidth costs and potential for severe DoS on any user associated with (a), (b) appears to be a more stable and responsible default. If another keyserver operator offers a different value proposition that is better than either (a) or (b), i'm willing to consider it as a default for debian. Or, if someone else wants to take over the packaging of GnuPG in debian, and they see the comparative advantage differently, i'd be happy to let them make the decision. --dkg
signature.asc
Description: PGP signature