fingerprint-based import screener is no defense against malice
Open, NormalPublic


if i retrieve a key by fingerprint:

gpg --recv 0x$FPR

then modern gpg automatically applies an import screener that only accepts OpenPGP certificates that have the given fingerprint (either in the primary key or in an associate subkey). Presumably, the intent is to make it possible to refresh keys in a curated keyring, to resist the keyserver (or other operator) who offers the user a malicious key.

However, it's possible for someone else to make a new OpenPGP certificate that includes the key in question without knowledge of the secret key (e.g. as a non-cross-signed subkey).

As a result, an attacker can bypass the import screener and inject new primary keys into the keyring. I consider this a security concern for anyone who is trying to use GnuPG to manage a curated keyring.

Proposed solution

By default, when doing --receive-keys with a fingerprint, the screener should only admit OpenPGP certificates that include a key matching the fingerprint which has a valid signature in the certificate itself. This means, for example, that either this is the fingerprint of the primary key itself, or it is the fingerprint of a signing-capable subkey that has a well-formed (and cryptographically valid) public key binding cross-signature.

This would mean that:

  • refreshes of a curated keyring would still work
  • you could still fetch a key based on the "Issuer Fingerprint" (or "Issuer Key ID") of a signature (in order to validate the signature) even if it was a subkey, because signing keys need cross-sigs


  • you could not necessarily use --receive-keys for retreiving a key based on the embedded key ID in a PKESK (e.g. "let's see who else this message appears to have been encrypted to"). I think this is a minor use case by comparison with the above two use cases, and it is less security-sensitive. Perhaps we could add an additional option (--keyserver-options no-require-signature-when-fetching-by-fpr?) that would re-enable this use case, if we want to support it.


2.2.0 and all previous versions since the import filters were put into place.
dkg created this task.Sep 8 2017, 5:34 PM
werner added a subscriber: werner.

I still consider the import screener (the term filter is used in a different way now) a big mess. Using the import feature to maintain the idea of a curated keyring is a bad idea because gpg has not been designed with this in mind. We spent so much time on this screener already and problems pop up again and again.

Looking at the other keys a message has been encrypted is a valid use case and thus such additional screening should only be done with --refresh-key.

Please allow me to degrade this to a feature request for 2.3

werner triaged this task as Normal priority.Sep 12 2017, 9:49 AM
dkg renamed this task from fingerprint-based import filters are no defense against malice to fingerprint-based import screener is no defense against malice.Sep 12 2017, 2:13 PM
dkg updated the task description. (Show Details)
dkg added a comment.Sep 12 2017, 2:16 PM

I've changed the text of this report from "filter" to "screener" to match the preferred terminology. thanks for the clarification.

I first raised this issue over a year ago privately. The fact that we haven't gotten import screeners right yet isn't a great argument for not fixing their bugs.

Does GnuPG have a recommended way to support the curated keyring use case? or do you not consider curated keyrings a valid use case with security implications if the import screeners are not effective?

Should applications that are structured around the idea of a curated OpenPGP keyring use GnuPG or do we have a different set of OpenPGP tooling to recommend to them?

georg added a subscriber: georg.Jan 31 2018, 11:35 PM
dkg added a comment.Sep 28 2018, 5:45 PM

This was additionally reported as -- it would be great to get a clear statement from the GnuPG project about handling the curated keyring use case.

jwilk added a subscriber: jwilk.Sep 28 2018, 6:44 PM
werner added a comment.Oct 1 2018, 8:39 AM

I have this use case: A card based encryption key is used as a subkey on one of my keys but also on another key of mine. The reason for this can be that I want to have separate keys (with different fingerprints) for two user ids but still use the same card for decryption. Sure it is possible to figure out that the user ids belong together but it is not obvious on first sight. Another use case is a role account with a shared subkey with only one administering the primary key.

I can't see how these use cases differ from what is called an attack here. The problem at hand is to let a keyserver update a curated keyring. I can't see a general solution here. What is possible are import options to inhibit the import of new subkeys or just subkeys without a binding signature. But that would not allow to make use of encryption subkey rollover.