GnuPG should always accept key updates even if the update does not contain UIDs
Closed, WontfixPublic


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.Aug 24 2019, 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?

paz added a subscriber: paz.Oct 19 2019, 8:21 PM

On July, 19th, @werner wrote:

You need to wait a bit more.

3 months passed since then. How long will we have to wait?

Please realise that this is a real-world problem for a lot of people.

dkg added a comment.Nov 18 2019, 4:03 AM

it's been almost a quarter year since my last nudge on this supplied patch. It's not clear to me why it hasn't been merged in master. I'm trying to not be a nag, but:

  • this is addressing a real-world problem, with security-related consequences
  • it has a proposed patch with wide, months-long deployment (both debian and gpg-tools) that we haven't heard any negative reports about

An update at least from upstream would be welcome.

georg added a comment.Dec 8 2019, 3:23 PM

@werner Could you please give an update on this? Is there any blocker? Is something missing, which prevents merging (and releasing) this?

werner added a comment.Dec 8 2019, 7:58 PM

I see no reason to move required computations from the server to the client.

dkg added a comment.Dec 9 2019, 6:07 PM

@werner, i don't understand your last remark. what "required computations" do you think the proposed patches are "moving" from the server to the client?

Figuring out the matching user id for a new key signature. Right, --import-options repair-key is the the default and does the same. However, it was also the major cause for the recent trouble with the keyservers because it tried to verify all signatures. repair-keys was made the default (T2236) because it seemed to be nearly for free - which was a false assumption. We should not use this option by default and only consider properly placed signathures as valid. This of course also means that a userid is required.

That sounds like you might have a different issue in mind?

Let's make sure we are all on the same page here:

  • P primary key
    • R revocation
    • U [ user id would be here ]
      • US [ user id signatures would be here ]
    • S subkey
      • SS subkey signatures

What repair-key affects, and what your concerns seem to be, are user id signatures in any other position than US, possibly even without any corresponding U. Since you referred to "the server doing work", I should point out that Hagrid in particular does not distribute user id bindings that don't have a corresponding user id in its correct position.

This issue, and the patch I submitted, are purely concerned with keys that carry no U and US at all. The point is that revocations in position R, as well as subkeys in position S and their binding signatures in position SS, can and should still be imported.

fwiw, I personally agree that having "repair-key" on by default is an anti-feature.

dkg added a comment.Dec 20 2019, 6:56 PM

It has now been over 6 months since the patches were available to fix this problem and they have not been adopted upstream.

The problem:

  • user's keyring has a local copy of OpenPGP certificate X, with primary key Z, and containing a valid user ID
  • user encounters a stripped-down certificate X', with primary key Z but no user IDs. X' contains a revocation signature as a direct key signature, indicating that Z is revoked.
  • does the user's local keyring merge the revocation from X' into X, and mark X as unusable?

It clearly should, as it has cryptographic evidence that Z has been revoked.

Without the patches, GnuPG does not merge.

Please consider applying these patches, at least to master.

kenyon added a subscriber: kenyon.Jan 26 2020, 6:40 AM
ilf added a subscriber: ilf.Mar 28 2020, 5:43 PM

Nine months have passed since the patches for this problem have been available.

This is a real-world-problem that many users have. Many developers have argued for these patches.

Upstreams answer has been shifting between "maybe", "later" and "no". The arguments for a rejection have been discussed in detail, the overwhelming majority was for merging this patch.

So: Can we please merge them? Or provide another avenue how to resolve this issue?

ilf awarded a token.Mar 28 2020, 5:43 PM
werner closed this task as Wontfix.Mar 29 2020, 11:25 AM
werner claimed this task.

With OpenPGP we made user ids mandatory to avoid problems we had with PGP2. I see no reason to revert this.

dkg added a subscriber: aheinecke.Mar 29 2020, 5:38 PM

To be clear: marking this ticket wontfix means (among other things) that it is the GnuPG project's upstream position that:

  • If GnuPG discovers cryptographic evidence that a public keyblock has been revoked by its own primary key, there are situations where GnuPG will deliberately ignore that evidence and continue to enable and encourage the use of that public keyblock.

Could someone from the GnuPG upstream (@werner or @aheinecke I guess) confirm that this is correct?

No, we always stated that the user id is a mandatory part of OpenPGP keyblocks and that non-compliant keyblocks are rejected. The only exception we made are for revocation signatures where we allow a standalone packet. That exception is done to allow typing in a printed out revocation signature.

If implementations do not produce compliant OpenPGP messages; they simply do not speak the OpenPGP protocol.

dkg added a comment.Mar 29 2020, 6:46 PM

Thanks for following up!

This response is disappointing, because I had assumed that GnuPG prioritized the safety of its users over strict adherence to a particular view of a cryptographic protocol. It sounds like that is not the case, but I am glad(?) to see it clearly stated.

I had assumed that GnuPG prioritized the safety of its users over strict adherence to a particular view of a cryptographic protocol

It doesn't sound to me like GnuPG necessarily adheres to the protocol here either. It rather seems to me that there's some other reason why UID-less updates are refused by GnuPG.

I fail to understand why "we allow standalone packets for revocation signatures" is incompatible with "accept key updates without UUIDs", especially if the concern here is primary key revocation. Could someone clarify to me what that distinction is and why it matters at all?

Shouldn't this be issued a CVE? It seems to me failure to take into account a revocation certificate is a serious security issue. Major keyservers (e.g. do, *right now*, distribute UID-less key updates for important reasons (e.g. DoS avoidance) and so there are actual, real, current such certifications being distributed in the wild, and GnuPG should take them into account.

And if the standards need to be updated to fix this problem, then let the standards be updated. They are not sacred, unchangeable documents and, in fact, are being changed constantly, including by the main author of GnuPG and (hopefully) other contributors which are allowed by editor of said standard (which also happens to be the main author of GnuPG). So it feels a little disingenuous to discard this based solely on adherence to standards.

just reading the issue in detail.

What I do not understand is: Why does the keyserver software hagrid (which I understand runs on does not deliver a UID and be compatible with the (current, old) OpenPGP keyserver protocol?

The argument from @dkg I've learned from this issue is that when asking for the pubkey, GnuPG already has the UID to be able to merge it. So why not send it again?

Okay, the next argument (to my understanding) is about a UID that has been "redacted", so I wonder for what reasons. My assumption is that when creating a valid OpenPGP keypair, I do create at least on UID. So now I could place illegal or false information in there, like a different person's email address. If the public keyserver assumes that this is the case, it could block the UID and could block the whole pubkey if there is no other UID. The person that created the public key with its UIDs (and published them) certainly intended for that information to be published (including the false and illegal information if there is) and in case there is evidence to the keyserver that indeed it was false and illegal info this evidence would come from other sources. It seems fair to block the pubkey in question and to not participate in distributing false and illegal information.

The other reason I can think of is to not send a UID is: privacy protection . To protect against someone else publishing personal information about user B. Here the question is whether there is another permission is needed before a name or an email address is published or a right exists to post-redact an illegal publishing by someone else. A pre-permission system would mean validating the information in the UID somehow, currently this means to reduce it to the email address and confirm ownership of the email address somehow. If this is done by each keyserver, it is not feasable, so the construct of pre-permission leans towards a central validating keyserver. However this has large drawbacks, so a post-right seems the better approach allowing better for decentral keyservers.

Maybe this is an important point (so far not explicitely written out here):
Accepting pubkeys from a server (like hagrid and current that does not send UIDs leans towards a central validating keyserver. Because otherwise it would just send a UID (and adhere to the old OpenPGP protocol).
It seems Werner, Andre and others to not want this.

What am I missing?