Error with GPG Smartcard fetching public subkey

gnupgopenpgpsmartcard

I'm trying to setup an OpenPGP smartcard using a YubiKey.
It's a YubiKey 4, so in theory should accept a 4096 bit secret key, but I'm using 2048 bit subkeys.

I have a master key (set for cert only), and three subkeys (signing, encryption, auth) which I have copied to the YubiKey.

I have uploaded the public key to my website, and set the URL for the public key in the smartcard.

When I try to use fetch, I get an error as the card goes looking for the wrong public key. Example (using windows and GPGWin):

Keys: 
11111111 - Master Key
22222222 - Signing sub
33333333 - Encrypt sub
44444444 - Auth sub

C:\gpg> gpg2 --card-status
...
URL of public key: https://my.server/pgp.key
...
General key info:  pub 2048/22222222 2016-01-09 Me <me@my.server>
sec# 4096R/11111111  created: 2016-01-09
ssb> 2048R/22222222  created: 2016-01-09
                     card-no: 0006 12345678
ssb> 2048R/33333333  created: 2016-01-09
                     card-no  0006 12345678
ssb> 2048R/44444444  created: 2016-01-09
                     card-no  0006 12345678

Then trying to fetch from the smart-card gives:

 C:\gpg> gpg2 --card-edit
 gpg> admin
 Admin commands are allowed
 gpg> fetch
 gpg: requesting key 22222222 from https server my.server
 gpg: no valid OpenPGP data found.
 gpg: Total number processed: 0
 gpg: keyserver communications error: keyserver helper internal error
 gpg: keyserver communications error: General Error

When I run gpg -a --export 11111111 > pgp.key, the resulting pubkey is the same as if you --export 22222222 (I gather this is expected behavior for subkeys), so I'm not clear why it's looking for the other key.

I've tried exporting the key with and without armouring, have confirmed that the ownership for the file is set to www-data:www-data in my server's /var/web.

Any further suggestions would be appreciated.

Best Answer

I'm seeing something similar, perhaps related to https://lists.gnupg.org/pipermail/gnupg-users/2015-May/053558.html? The final post in that thread seems to suggest it's acknowledged as an issue, but apparently not changed.

It seems like the 'General key info' key, in our case the signing sub-key, is the one it wants to grab.

In my scenario the fetch appears to succeed, but it doesn't actually import anything in to my keyring. Easily overcome with a manual fetch of the real public key, but annoying none the less.

Related Question