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


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 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.Mar 6 2019, 12:16 PM
dkg added a subscriber: dkg.Mar 6 2019, 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.Mar 6 2019, 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?


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.Mar 6 2019, 6:04 PM


werner edited projects, added gnupg; removed gnupg (gpg22).Mar 6 2019, 6:05 PM
dkg added a comment.EditedMar 6 2019, 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.Mar 7 2019, 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.Mar 7 2019, 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.Mar 8 2019, 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.

dkg added a comment.Jun 14 2019, 6:08 PM

I've pushed @Valodim's proposed patches to the fix-4393 branch in our git repo. they look good to me, and i think they should be merged to master.

Please use a private branch as usual. There has been no agreement or a discussion over this change nor do we have a DCO from him.

dkg added a comment.Jun 16 2019, 5:40 PM

@werner, My usual approach for private branches is to prefix with dkg/, but (a) playfair rejects branch names with a /, and (b) i'm not the author of these patches, and i didn't want to claim credit that doesn't belong to me.

feel free to change the branch name to whatever you think is appropriate, and i'll follow suit in future situations like this.

dkg added a comment.Jun 18 2019, 2:05 PM

we now have a DCO from @Valodim

I think his patches address some of the concerns you raised on gnupg-devel back in october, @werner.

If they're not mergeable as-is, can you explain what changes you think need to be made? These changes have a positive security impact, as i've explained over at

It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?

dkg added a comment.Jun 28 2019, 10:05 AM

sorry to keep pinging this, but given the ongoing flooding attacks (e.g. T4591) and how SKS and similar keyservers are unable to safely transmit flooded certificates, i think this kind of fix is urgent if we expect gpg to be able to retrieve revocations safely. What's the status here?

georg added a subscriber: georg.Jun 28 2019, 3:33 PM
pert added a subscriber: pert.Jul 2 2019, 2:05 AM
Angel added a subscriber: Angel.Jul 3 2019, 2:49 AM
tianon added a subscriber: tianon.Jul 3 2019, 9:34 PM
jaymzh added a subscriber: jaymzh.Jul 4 2019, 10:33 PM

Just want to weigh in here to say this would be incredibly useful given the shift to the new keyserver model. See T4604 for more context.

werner added a comment.Jul 5 2019, 7:58 AM

Not sending the user id packet, is just a bad idea because that user id exists and from my understanding they are sending the self-signatures anyway. They should not try to argue with the GDPR here, that is privacy theater. The key itself is a personal data and due to technical reasons this data is required. What they can do is to accept only user ids which carry just only mail address and no comments or name. for example requires this for years and the WKD drafts has a feature to support this.

werner lowered the priority of this task from Normal to Low.Jul 5 2019, 8:02 AM
werner edited projects, added gnupg (gpg23); removed gnupg.
dkg added a comment.Jul 5 2019, 3:07 PM

This is not just about It's about any keystore that implements user id redaction, for whatever reason. When you say "what they can do is accept only user ids which…" i think you mean "the userid-redacting keystores can instead redistribute user ids which …". Is that right?

Resdistributing user IDs with only an e-mail address and no name or other data is not a sufficient step, for several reasons:

  • Some existing certificates do not have such a user ID (for whatever reason), and we want keystore tooling to work with those certificates as well
  • The e-mail address itself is a potential concern -- not for privacy reasons, but for accuracy reasons. Some keystores may not want to be seen as publishing data associated with an e-mail address that they are not confident is correct. However, those keystores *can* be confident that (for example) a subkey has been added, or revoked, or expired, or that the primary key has revoked the entire certificate (they can be confident that this is true because it is cryptographically verifiable)

So, whether we like it or not, some keystores are going to publish data like this.

Furthermore, GnuPG has sufficient information on encountering this kind of information to be able to make sense of it. If it has a local copy of a certificate with a user ID already, and it receives a certificate with additional information associated with the same primary key, but without any User ID, GnuPG is capable of merging that data correctly.

The question that remains is whether GnuPG is *willing* to merge the data.

If GnuPG can see that a certificate has a new or updated subkey, but it refuses to store or acknowledge it, it is doing both users a disservice. ("both" meaning: the certificate owner and the local user whose keyring is failing to receive the update). The result may be a DoS on the local user (e.g. they can't find a subkey with the appropriate usage flags, even though one exists), or it may be a security vulnerability (e.g. the local user continues to use a subkey that has been revoked).

If GnuPG can see that the entire certificate has been revoked, but it refuses to store or acknowledge the revocation, it is *also* doing both users a disservice. This is clearly a security vulnerability, since it means that the local user is likely to use a certificate that it should have known is no longer valid.

It would be irresponsible for GnuPG to deliberately ignore this information, even if it thinks there is some "better" way to publish it.

@Valodim's patch here adds not only a fix, but also tests to ensure that the fix does what it says it does. And it does not break any of the other existing tests, so I do not see any justification here for why it is wrong to take these steps. If there is some preferable technical way to do this, please describe it or implement it. It doesn't need to be @Valodim's patch specifically, but GnuPG needs to do the right thing automatically here. It currently does not.

@werner, unless you can offer some stronger justification for why accepting this information is bad or broken, i'll be shipping this change in GnuPG in Debian, probably in the next security update i manage to put together, and advocating for its inclusion in other distributions of GnuPG. It would be a shame to have to carry such a difference from upstream, but protecting Debian users of GnuPG is more important than avoiding divergence from upstream.

Please merge this patch.

and from my understanding they are sending the self-signatures anyway.

If by "they" you mean, then this is incorrect. For keys where we don't have user consent to ship their user ids, we distribute exactly subkey updates and revocations: See also the related FAQ entry Why are revoked identities not distributed as such?

steve added a subscriber: steve.Jul 10 2019, 2:05 PM

We as GPGTools would also like to see this addition being integrated into GnuPG, since we do plan to switch to in the near future, as we have long been hoping for a key server with better performance and among other things email verification. Without this change, revocations would not work as expected in combination with hagrid however. Preferably of course in the 2.2.X branch.

steve awarded a token.Jul 10 2019, 2:05 PM
physkets added a subscriber: physkets.

So, what about this? If I recall correctly, we had agreed in the call to merge this patch, at least into master?

Other tasks in master are right now more important. You need to wait a bit more.

dkg added a comment.Jul 20 2019, 1:39 AM

@werner wrote:

Other tasks in master are right now more important.

I'm disappointed and frustrated by this response, especially given that
we had agreed during earlier discussion to merge these changes. While
other tasks in master are certainly important, the amount of work to
actually merge is minimal. I could even merge it for you if you don't
want to do the work. Just say the word if that's what you want.

You need to wait a bit more.

I'm sure you didn't intend it this way, but this sentence reads as some
sort of arbitrarily-imposed punishment, though it's unclear to me what
anyone involved in this ticket has done wrong.

Or, is there actual labor-intensive review happening? Or does the
series need more work? If so, a brief explanation of the necessary
review or revisions would make this back-and-forth look more like a
collaboration and less like some sort of unnecessary power struggle. I
would appreciate clearer communication.

Everyone contributing here wants to help GnuPG and its userbase.

dkg added a comment.Sat, Aug 24, 12:55 AM

It has now been more than a month since:

You need to wait a bit more.

Do we still need to wait a bit more?