GnuPG should always accept key updates even if the update does not contain UIDs
Open, NormalPublic

Description

I appreciate the new option "import-drop-uids", however, it always drops UIDs, even if the server has some.

I'd like to see GnuPG accept TPKs from the server that do not carry UIDs by default. "import-drop-uids" overshoots here, because it also drops UIDs if present, and can therefore not be made the default.

In https://lists.gnupg.org/pipermail/gnupg-devel/2018-October/033969.html Werner points out that updating a TPK for subkeys or revocations is useful on its own, even if the server has no UIDs to offer. In fact, if the server has valid new subkeys or revocations, I don't see any reason not to import them.

With this change, GnuPG would be able to make full use of hagrid, a new keyserver aiming to replace the SKS server, where people can opt-in to have their UIDs published.

As a Debian user, I'd love to see this feature backported to 2.2.

justus created this task.Wed, Mar 6, 12:16 PM
dkg added a subscriber: dkg.Wed, Mar 6, 4:37 PM

i don't understand why "import-drop-uids" is useful -- it sounds to me like the functionality you're looking for is something more accurately named "accept-certs-without-uids". is that right?

I'm happy to try to backport features into debian where i understand the utility, but i don't understand the utility here.

justus added a comment.Wed, Mar 6, 4:44 PM
In T4393#123047, @dkg wrote:

i don't understand why "import-drop-uids" is useful --

Me neither, modulo the happy fact that it does allow me to import TPKs without userids.

it sounds to me like the functionality you're looking for is something more accurately named "accept-certs-without-uids". is that right?

Yes.

I'm happy to try to backport features into debian where i understand the utility, but i don't understand the utility here.

We can distribute subkey updates, revocations, new TPS with Hagrid, and once we move the keyflags and co to direct key signatures, this is even more useful.

werner added a subscriber: werner.Wed, Mar 6, 6:04 PM

TPK ?
TPS ?

werner edited projects, added gnupg; removed gnupg (gpg22).Wed, Mar 6, 6:05 PM
dkg added a comment.EditedWed, Mar 6, 7:53 PM
  • TPK: transferable public key (an "OpenPGP certificate")
  • TPS: Third-party signature (any certification within a TPK that is not made by the primary key, and is not a cross-sig made by a subkey over the primary)
werner triaged this task as Normal priority.Thu, Mar 7, 7:50 AM

Thanks. [I wonder why the looong established terms public-keyblock and key-signature must be replace by arbitrary new terms.]

Useful feature request.

justus added a comment.Thu, Mar 7, 9:42 AM

Those terms are not arbitrary, they are in the RFC.

% pcregrep -iM 'public[\s-]*key[\s-]*block' ../draft-ietf-openpgp-rfc4880bis-06.txt
   BEGIN PGP PUBLIC KEY BLOCK  Used for armoring public keys.
% pcregrep -iM 'transferable[\s-]*public[\s-]*key' ../draft-ietf-openpgp-rfc4880bis-06.txt
     11.1.  Transferable Public Keys . . . . . . . . . . . . . . . .  84
11.1.  Transferable Public Keys
   transferable public key are as follows:
   Transferable public-key packet sequences may be concatenated to allow
   secret key is the same as a transferable public key except that
   especially if a transferable public key accompanies the transferable
werner added a comment.Fri, Mar 8, 8:26 AM

I meant the abbreviations. PGP is based on a code base dating back to 1992; for example we mostly used the term keyblock instead of certificate in the code.