Incorrect general key info, for key on Yubikey NEO

terje at terje at
Mon May 4 23:05:03 CEST 2015

Hi list,

I've got what seems to be a not too uncommon setup, with a primary key 
used only for certifying, then separate signature, encryption and 
authentication keys as subkeys.  I wanted to make new ones, and have the 
subkeys on a Yubikey NEO.

All was going perfectly fine, I revoked the old subkeys, generated new 
ones, and everything seemed well.  After I moved the key to another 
machine though, I noticed that the "General key info" is somehow bound 
to the signature subkey, not to my primary key.

I'm not sure, but I'm wondering if what I did wrong could have been that 
I ran a gpg --card-edit and fetch, while the machine was offline, so it 
wasn't able to pull down the key from the set URL.  I'm wondering if 
this can be the source of the incorrect binding.

On the old (offline, airgapped etc) machine where I generated the key, 
the subkeys seem to be properly set up on the master key, but with the 
general key info being incorrect, I can't get the second (online, 
day-to-day work-laptop) machine to properly recognise and bind the 
subkeys to the master key.

Exporting/importing the public keys from the offline machine doesn't 
seem to change anything either.

Output from gpg --card-status is as follows:

Application ID ...: D276000[...]
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: 0350[...]
Name of cardholder: Terje Elde
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key :
Login data .......: tld
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 1
Signature key ....: F76C 2924 AA47 2F40 9B8D  3BCD 53C9 00F2 CD95 0E4F
       created ....: 2015-05-04 18:02:05
Encryption key....: D87C 6986 5C34 C778 A0CF  4208 4B31 3528 CA68 9462
       created ....: 2015-05-04 17:04:17
Authentication key: D5CC 5261 CA84 CFAC 0BBC  EB22 EEF9 5F70 1D85 0949
       created ....: 2015-05-04 18:03:08
General key info..: pub  2048R/0x53C900F2CD950E4F 2015-05-04 Terje Elde 
<terje at>

As you can see, the key mentioned in general key info:
matches the signature-key, ending in:

The key as a whole looks like this:
> gpg --list-key 0xAE05171EA277084B
pub   3072R/0xAE05171EA277084B 2015-04-22 [expires: 2016-10-13]
       Key fingerprint = 04F1 2CA5 E18B DE4F CF19  0A69 AE05 171E A277 
uid                 [ultimate] Terje Elde <terje at>
uid                 [ultimate] Terje Elde <terje at>
sub   2048R/0x4B313528CA689462 2015-05-04 [expires: 2016-10-25]
sub   2048R/0x53C900F2CD950E4F 2015-05-04 [expires: 2016-10-25]
sub   2048R/0xEEF95F701D850949 2015-05-04 [expires: 2016-10-25]

It's even aware of the subkeys being detached:
> gpg -K
sec#  3072R/0xAE05171EA277084B 2015-04-22 [expires: 2016-10-13]
       Key fingerprint = 04F1 2CA5 E18B DE4F CF19  0A69 AE05 171E A277 
uid                            Terje Elde <terje at>
uid                            Terje Elde <terje at>
ssb>  2048R/0xFC5D2BB7C48EB15C 2015-04-22
ssb>  2048R/0xE7A7BAFE92B298A2 2015-04-22
ssb>  2048R/0xDE0525B2E9641E2B 2015-04-22

Not possible to use the thing though:
> gpg --clearsign f.txt
gpg: no default secret key: Unusable secret key
gpg: f.txt: clearsign failed: Unusable secret key

I am able to confirm that I can actually use the keys, as using them 
with SSH seems to work fine.

My guest guess would be that GnuPG isn't connecting the dots.

For completeness, let me quickly mention that previous (now revoked) 
subkeys were also on smartcard, Yubikey NEO-n to be exact.

Would love a suggestion or a pointer, I'm a bit eager to release the 
revocation of the old subkeys.


More information about the Gnupg-users mailing list