Page MenuHome GnuPG

GnuPG should reject keys that are subkeys of itself
Closed, WontfixPublic


Discovered at is a
bizarre construct, where a key is its own subkey.

gnupg should notice this misconfiguration and reject the key.

Event Timeline

uploaded the offending key for reference:

this was also reported in hopenpgp-tools

werner triaged this task as Normal priority.Jan 31 2018, 6:03 PM
werner edited projects, added Feature Request, gnupg (gpg22); removed Bug Report.
werner added a subscriber: werner.

I can't see why this should be out-of-spec. In fact I did this my self several times to create keys from other keys.

I agree that a warning might be justified.

a key that is signed as its own subkey, in a construct where the key and subkey have the same fingerprint? what ever could be a valid use case for such a scenario?

You have a token with one spare key which you want to use for encryption and certification. And being able to replace the encryption subkey eventually.

Sorry, I don't understand. Can you describe your use case in more detail?

\\ edit

Ah, scratch that, I think I got it.

The use case as I understand it occurs due to gnupg's way of binding token keys to specific keys in the keyring, which is an implementation detail. I suspect that any user that attempts to do something like this who is not a developer of openpgp software will only get burnt, and I don't see how that is worth losing the identity property of fingerprints in a keyring.

werner claimed this task.