Page MenuHome GnuPG

card-edit/fetch assumes signing key is master key and fails if not
Closed, ResolvedPublic


I currently have a master key with three subkeys, one for signing, one for
encryption and one for authentication. I loaded the three subkeys on a
Yubikey NEO and everything works fine except the command fetch on a new
machine. (The master key is intended to live offline and only used to
occasionally re-issue or re-certify subkeys).

If I do a gpg --card-edit followed by a 'fetch', I get the error

gpg: requesting key AEB99527 from https server
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

Where AEB99527 is the signing subkey identifier not the master key
identifier which is what it should be "fetching".

It appears to be pulling the key from the https server and comparing the key
identity with what it expects which appears to be the subkey instead of just
accepting the key data that is there which is the master public key which
includes the public keys of the subkeys. (There is no easy or supported way
that I am aware of to separate out the public key of a single subkey)

If I manually load the public key of the master (the one at the URL I
configured) and then run gpg --card-status everything works properly
(the resulting --list-secret shows as follows):
sec# 4096R/757C0180 2015-02-03 [expires: 2015-11-30]
uid John Tennyson
uid Elvish Wanderer
uid Elvish Wanderer
uid John Tennyson
uid John Tennyson
uid John Tennyson
uid John Tennyson
uid John Tennyson
uid Elvish Wanderer
ssb> 2048R/AEB99527 2015-02-03
ssb> 2048R/CADC0F35 2015-02-03
ssb> 2048R/C40CA003 2015-02-03



Event Timeline

What did you put into the URL field of your card and what is the first

gpg --card-status | grep ^URL
gpg --card-status | grep '^Signature key'

Here is the latter half of the output of --card-status in it's entirety...

The URL is listed, as for the signature key, that is the crux of the
problem... it shouldn't care about what the fingerprint of the signature key
when retrieving the public key when the signature key is a subkey as you
can't retrieve just the public key of the subkey, you need to retrieve the
public key of the master key that contains that subkey.

Note below how key 757C0180 is the master key and in the error message in
the op it is looking for AEB99527 which is the signing subkey.

Name of cardholder: John Tennyson
Language prefs ...: en
Sex ..............: male
URL of public key :
Login data .......: elfindreams
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: 85D5 A0DA 4EC2 B038 128F 9D88 4791 2162 AEB9 9527

created ....: 2015-02-03 21:18:19

Encryption key....: 3AD4 1BA6 47B9 1AA3 89CD C29E A6CF 5D5D CADC 0F35

created ....: 2015-02-03 21:18:48

Authentication key: D61E 29B6 9784 15A9 CEFE 08F4 6AD2 1E6C C40C A003

created ....: 2015-02-03 21:19:08

General key info..: pub 2048R/AEB99527 2015-02-03 Elvish Wanderer
sec# 4096R/757C0180 created: 2015-02-03 expires: 2015-11-30
ssb> 2048R/AEB99527 created: 2015-02-03 expires: 2015-11-30

card-no: 0006 03362156

ssb> 2048R/CADC0F35 created: 2015-02-03 expires: 2015-11-30

card-no: 0006 03362156

ssb> 2048R/C40CA003 created: 2015-02-03 expires: 2015-11-30

card-no: 0006 03362156

Thank you for your report. There is no logic to check fingerprint. So, I think
that the key retrieval itself might fail somewhere.

Assuming your gpg2keys_curl is installed at /usr/lib/gnupg2, could you please run
following command, and input lines?

$ /usr/lib/gnupg2/gpg2keys_curl -o public-key.asc
SCHEME https



Finally, I confirmed the problem. Sorry for taking long time. My understanding
was bad. I'm going to fix this.

It would be different issue, but we have similar problem for 'fetch' failure
with an error message like:

gpg: key B00DC692: rejected by import filter" followed by "gpg: Total number
processed: 1

See also T2895 (nimbius on Dec 27 2016, 04:49 AM / Roundup)

I think that this issue is fixed in 2.1, which use KS_FETCH instead of KS_GET with fingerprint.
Please test with 2.1.
We don't change 2.0.