Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one used for daily usage.
Thanks Gniibe San for explanation.
Fri, May 17
@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).
Thu, May 16
Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Apr 9 2019
We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.
Apr 8 2019
Apr 5 2019
I did lot of tests in the last weeks while working on gpg-card.
Mar 28 2019
Good that it works again for you.
I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.
This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...
Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.
Mar 27 2019
Mar 26 2019
There was indeed a problem. With a test card I could reproduce the issue and fix it.
Mar 6 2019
Thanks for fixing that.
That's my badness. In wait_child_thread, assuan_release may cause thread context switch to agent_reset_scd which accesses scd_local_list; This access should be serialized.
And... in start_scd, calling unlock_scd should be after unlocking start_scd_lock.
Feb 26 2019
Does not happen in 2.2. Additional requirement to test this bug in master: Another connection to the scdaemon must be open. For example running scute or, easier, call "gpg --card-edit" and keep it open.
Feb 19 2019
Gnuk implements the feature, and newer GnuPG shows a dialog to request pushing the ack button.
Jan 17 2019
Dec 13 2018
Oct 15 2018
Sep 27 2018
Interaction will be something like this:
Priority is high, because Gnuk Token requires this feature for testing its implementation.
Aug 24 2018
Thank you for the clarification. For now, I'll modify our implementation to use shorter length representation and close this bug as Invalid.
However, I'm still not convinced that using hard-coded arguments is the right way to handle requests. I'll do some more testing and if I discover a legitimate use-case that requires long APDUs, I'll reopen the issue.
Aug 17 2018
Thanks for the information.
Aug 16 2018
In our implementation, DO 0x6E contains:
I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?
Aug 14 2018
Jun 12 2018
Jun 6 2018
Here is a sequence of operations/commands that permits to setup or update KDF-DO and align PIN codes accordingly:
May 30 2018
Apr 27 2018
Now there it gets complicated. According to the card software author in 3.3 and even 2.2 there is a fix. BUT there was a small amount of cards already created in 3.3 without the fix. Nobody ever told my how to diferentiate them.
There is no Version 3.3.1 you can by - it is only 3.3. So you can buy one and hope you have a good one.
At least this is my understanding.
Apr 26 2018
Does v3.3.1 fix this? (The release notes for it seem to imply that's not the case.)
Apr 20 2018
@nitroalex Perhaps, creating new ticker is better for this topic.
In the current OpenPGP card specification, there is no way for an application (except having a list of card implementation information) to know wich algo and which curve is supported or not.
So, what an application does is try and error.
I don't like this situation, but I don't know how we can modify the specification.
Apr 19 2018
Well, I surely would agree (and this is only a proposal anyway), but my point here is, that OpenPGP Card does not support Curve 25519, so that one *have to* choose between those other two. Considering me a tinfoil hat person, I would rather not choose NIST, as many others wouldn't too.
Apr 17 2018
Apr 13 2018
Neither Brainpool nor NIST curves make any sense unless there is an organizational policy requirement. Thus the --expert requirement is the Right Thing (tm).
Apr 12 2018
works just fine, thx!
Apr 11 2018
For the situation where PINs are not factory setting, given the specification, I don't know how to achieve "to align all PWs and the KDF-DO with correct values"; It might depend on card's implementation.
You are right about the fact that multiple steps could result in unusable cards in case of power down before all commands have been issued. Nevertheless, in practice, these commands would involve very few treatments on the token (i.e. no cryptographic operation or heavy data transfer) and it should really not take long to complete the three steps (admin PIN update, user PIN update, KDF-DO update).
Workaround is implemented in 2.2.6.
Fixed in 2.2.6.
Apr 10 2018
My interpretation of the specification is different.
By requiring the condition of setting KDF-DO (it is only valid to setup KDF-DO when PINs are factory setting), Gnuk works well with current "kdf-setup".
If the procedure of setting KDF-DO includes multiple steps with KDF-DO update and PIN update, there is a risk of power down which results unusable card.
Apr 5 2018
Apr 3 2018
Yes, I meant the document. Please note that I am also one of users of the specification (for GnuPG, and for Gnuk Token). I am not defending, but try to explain the current situation.
Apr 2 2018
I was referring to this document:
You describe it as 'manual'. AFAIK, it's the specification for the functionality.
I have an experience implementing the functionality, following the specification.
And my own implementation does always return 512 bytes for RSA-4096. So, I could support your opinion.
Mar 30 2018
I realized that KDF support may be incompatible to Gnuk's feature of "admin-less" mode.
I'm going to implement compatible KDF support to Gnuk; That is, KDF data which only has a single salt.
In this case, all KDF calculation (user, reset-code, and admin) is done with the single salt.
With single salt, admin-less mode can work with no problem.
Furthermore, I changed to have an explicit command: key-attr
Mar 29 2018
I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.
Mar 28 2018
Mar 22 2018
2.2.6 will have this feature in --card-edit, as kdf-setup. Please test.
Mar 17 2018
Mar 16 2018
For factory-reset, rG2c85e202bc30: scd: Better user interaction for factory-reset. fixed the issue.
Mar 13 2018
I've contacted Yubico to review this ticket.
Hi, that works as advertised. If this is the best solution yubikey permits us I am ok with it.
I put an entry: https://wiki.gnupg.org/SmartCard#Known_problem_of_Yubikey
After resume, because resume is not detected, some user interaction is required to cause an error.
gpg --card-status (which will only show partial information) is enough. Or, ssh failure. After failure, scdaemon reconnects the token.
Then, you can use it again without plug-off/plug-in.
Thanks a lot for pointers and suggestion.
Well, the problem of Yubikey itself cannot be solved by others, we can put some workaround for the error recovery.
So, this is another try of mine to improve error recovery.
Mar 12 2018
- There was same problem in yubico-piv-tool and it was solved by detecting error state (0x80100068) and reconnecting to the smart card if necessary 
- There is also a thread in OpenSC discussing this issue  and relevant PRs 
- I also found a project that claims to fix SCARD_W_RESET_CARD by disabling exclusive access to the card before asking for PIN (and then they enable exclusive access again) 
New cards will come with a fix. I am not sure whether a production run has yet been done, though.
Part of the problem is Yubikey side, I suppose. (Because my implementation of Gnuk Token has no problem for suspend/resume if it's in-use.)
Again, thanks a lot for your testing. The log said: The code I added cannot detect the event of suspend/resume.
It seems that there is no way to recover from suspend/resume for Yubikey.