Change Details

if i retrieve a key by fingerprint: FPR=0123456789012345678901234567890123456789 gpg --recv 0x$FPR then modern gpg automatically applies an import filter 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 input filter 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 filter 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 However: * 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.

if i retrieve a key by fingerprint: FPR=0123456789012345678901234567890123456789 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 However: * 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.

if i retrieve a key by fingerprint: FPR=0123456789012345678901234567890123456789 gpg --recv 0x$FPR then modern gpg automatically applies an import filterscreener 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 input filterimport 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 filterscreener 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 However: * 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.