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.

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.

TPK ?
TPS ?

• 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)

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

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.

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.

@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.

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 https://bugs.debian.org/930665

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

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?

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.

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. posteo.de for example requires this for years and the WKD drafts has a feature to support this.

This is not just about keys.openpgp.org. 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 keys.openpgp.org, 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: https://keys.openpgp.org/debug?q=80615870F5BAD690333686D0F2AD85AC1E42B367. See also the related FAQ entry Why are revoked identities not distributed as such?

We as GPGTools would also like to see this addition being integrated into GnuPG, since we do plan to switch to keys.openpgp.org 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.

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.

@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.

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?

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.

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.

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

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

@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.

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.

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?

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.

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. keys.openpgp.org) 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.

Hello,
just reading the issue in detail.

What I do not understand is: Why does the keyserver software hagrid (which I understand runs on keys.openpgp.org) 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 keys.gnupg.org) 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?

It is now over 10 months that the proponents of these additions have not followed up on the discussion.

I share your concerns about centralization of keyserver infrastructure. Rejecting this security fix doesn't help keep keyservers decentralized, though.

@bernhard, i don't think that accepting a revocation from a keystore that strips user IDs "leans toward" a centralized validating keyserver. There are multiple reasons why non-centralized mechanisms might *also* want to distribute a revocation without a User ID.

For example, GnuPG encourages transmission of a revocation signature *only*, without a user ID or even without a primary key. For another example, I can imagine publishing a UID-less primary-key+revocation pseudo-certificate inside my WKD distribution, so that folks who have my old certificate can learn that it should be revoked, but without offering the general public the constitutent elements that would let someone assemble a revocation-less copy of my older cert. (that is, if i publish primary-key+revocation+uid+selfsig, then anyone malicious could take that, strip the revocation, and try to convince someone else that this re-assembled certificate is still valid; publishing just primary-key+revocation doesn't permit that kind of mischief)

Your question "when asking for the pubkey, GnuPG already has the UID to be able to merge it. So why not send it again?" doesn't make sense to me. If any OpenPGP client is requesting a specific certificate, the client knows some set of UIDs that it thinks belong to that certificate. The responding keystore *does not know* what that set is, or whether it corresponds to the set that the keystore might know about, let alone the set of UIDs that the keystore is comfortable sharing for whatever other policy reasons. In just one example, consider a certificate that the local client has with one UID that is bound with a non-exportable self-sig. Surely you're not suggesting that the querying client needs to send its own copy of the certificate to the keystore to get the update?

A keystore like hagrid that doesn't want to send any known User IDs could also send a bogus User ID (e.g. the empty string) with no selfsig to be nominally compliant with RFC 4880's grammar, but this is essentially pointless traffic (and would also be rejected by the current GnuPG implementation, aiui, so it doesn't solve the problem).

I have not followed up for months because i don't understand what additional information is needed to help GnuPG users incorporate revocation information that is available.

This bug has been closed as Wontfix more than a year ago. I see no reason to continue the discussion in the bugtracker.

bug has been closed as Wontfix [..] I see no reason to continue the discussion in the bugtracker.

This ticket is still linked from places, e.g. https://keys.openpgp.org/about/faq#older-gnupg , so it is helpful to explain the reasons from here or at least link to a better explanation.

@dkg , you wrote

I share your concerns about centralization of keyserver infrastructure.

and later

i don't think that accepting a revocation from a keystore that strips user IDs "leans toward" a centralized validating keyserver.

My perception is different: The proposed patch seems to allow using keys.openpgp.org as replacement keyserver and this is where the strong wish to integrate the patch comes from. But keys.openpgp.org is a validating, centralized keyserver. It may have useful information (and not accepting this can be considered a potential security problem), but if accepting the patch gives a boost to a central, validating keyserver, this is also a potential security problem itself.

So before accepting such a patch and thus a server-infrastructure, and a deviation from the current RFC4880 standard, the question needs to be asked: Isn't there another way without some of the drawbacks. (And I believe there is, which I have pointed out in more detail on gnupg-devel@ and within the GnuPG e.V. before. This may not the right place to go into details.) As long as there is a good chance to avoid a central validating keyserver, we should do so, and this would also mean to get the revocation certificates distributed elsewhere and it would mean it is a good decision to not merge the patch.

Werner also pointed out that later (after the 2018 posting in the original issue report), the experiments have shown that

• There is computational power needed for GnuPG for inserting keyblocks without properly signed user ids. Which can be a drawback in denial of service attacks.
• There were reasons a uid and signature were introduced, learning from previous experiences with PGP.

I'm interested to learn more about both arguments(, but I see the wisdom of not having this argument here in the tracker.)

Looking up the beginning of the issue (again), I see that this issue was originally about backporting experimental features of GnuPG from 2018 as those features are experimental and the patch does something else, I think it is good in the sense of clarity to let this issue rest as won't fix.

The way forward, I see is:

• Get a discussion going on gnupg-devel@ (or elsewhere) with the aim of a rough consensus how to solve the pubkey- and revocation discovery with the least drawbacks.
• If there is a rough consensus and the patch or parts of the patch are still useful towards it, open a new issue to get it merged or the functionality implemented.

@bernhard Following up on discussion elsewhere:

In hockeypuck, we wish to distribute UID-less revoked TPKs, for the following reasons:

1. A key owner has the legal right to delete their UIDs, since they are personal data.
2. A key owner's revocation certificate should always be distributed, so that RTBF does not open a security hole.
3. A revocation certificate cannot be verified without its primary key.

This means that keyservers must be able to store and distribute UID-less revoked TPKs. Further, in order to serve key material over HKP it must be in the form of a TPK, not a bare revocation certificate. While it may be possible to update the HKP spec, and require clients to implement support for bare revocations in their HKP handlers, this is complex on both the server and client side because it requires changes to parsing and request handling routines. On the other hand, relaxing the structural constraints involves less intrusive code changes, and has been implemented in many clients already.

Hockeypuck is a distributed keyserver on the same model as sks-keyserver, but addressing most of its design flaws. The proposed change is not specific to a centralised keyserver model, it just so happens that at the time it was proposed, keys.openpgp.org was the only example available.

I agree that primary keys without any signature on them at all are a potential abuse vector, but equally so are revocation certificates with no primary key. If the concern is that keys without certification signatures are easy to fake, surely a direct revocation signature provides a similar level of abuse protection? It is in some ways less resource-intensive to handle a revocation sig together with its primary key, as the sig can be verified and potentially discarded without looking up the local copy.

Perhaps we need to open a new issue for this, to keep the discussion more focused?

In T4393#180500, @andrewgdotcom wrote:

Perhaps we need to open a new issue for this, to keep the discussion more focused?

Oh most definitely. :-) I took the liberty of creating T6900: GnuPG: Accept revocation certificates without UserID for you. Please do not respond in this ticket.