Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334

Thanks a lot.
Let me explain the situation.

Hi, I changed the PIN, killed the gpg-agent and scdaemon, edited the scdaemon.conf to include your instruction, after, I run the following commands:

Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.

In T5167#139880, @gniibe wrote:

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

Argh. The following patch replaces the previous patch. It fixes the calculation of the display serial number.

I think the calculation of the OpenPGP s/n is not correct. As you write, "Yubico seems to use the decimalized version of their S/N as the OpenPGP card S/N." This matches my observation for my Yubikey:
s/n printed on Yubikey: 9074582
Yubikey s/n (with our prefix): FF020001008A7796
OpenPGP AID: D2760001240102010006090745820000

Great. Please apply the patch.

Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

How about distinguishing CARDNO and application specific SERIALNO?

BTW, the idea is to fade out support for gpg --card-status and --card-edit. Thus no new features there. New features shall only go into gpg-card.

Fixing --card-status is definitely a good idea. gpg-card shows almost the same information as gpg --card-status except that it shows the correct "Version" and "Serial number". It would probably make sense to unify the code of --card-status and gpg-card's list command.

Let me describe current situation.

I just noticed that gpg --card-status now prints a bogus OpenPGP version number for my Yubikey. And it prints an empty serial number.

# gpg --card-status
Reader ...........: 1050:0407:X:0
Application ID ...: FF020001008A7796
Application type .: OpenPGP
Version ..........: 77.96
Manufacturer .....: Yubico
Serial number ....:

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

I have tested this with Kleopatra. The good news is that SCD GETATTR $DISPSERIALNO now works for the piv app even if the openpgp app is enabled.

SCD commands:

• DEVINFO
  • returns app apecific serialno
• SERIALNO
  • returns app specific serialno
• LEARN
  • returns canonical serialno

I created this patch D509: Yubikey supports two (or more) apps, serial number problem.

But changing just the displayed S/N should not disturb anything.

No, the above patch makes OpenPGP app stop working.

(I don't know well about Yubikey specific serial number.)

I have added a workaround to Kleopatra: rKLEOPATRA57cf71b043d198f85270eb3b8782de6277b8b889

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

Okay, I recall that I have seen these Yubikeys. Can you tell me which GPG app you intended to use? I am not aware of any GnuPG ports to the iPhone.

The new Yubikey 5Ci does NOT work with NFC, this is wrong. This Yubikey is delivered with two connectors: A lightning and an USB-C, see: https://www.mtrix.de/shop/yubikey-5ci/. The key can be connected to a laptop and an iPhone by plug-in. So the new Yubikey 5Ci does not require NFC at all. You refer to the Yubikey 5 NFC. This technology is not supported by developers because they do not have experiences there. With the plug and play functionality of a lightning connector it is easier and few application already exist (e.g. Yubico authenticator and several password manager in the professional edition). Hope this information will be useful for you.

Seems that the public key needed to be exported from the Linux side and imported on the Windows side. Once this was done, the rest of the key information is displayed under Windows for the gpg --card-status.

Caching of the OpenPGP PIN while switching to and from PIV does now work in master

And also this is excellent point.

Thank you. I was waiting your feedback.

I can confirm this has the desired effect for me on master (f97dc55ff1b041071bc3cbe98aa761bf77bb7ac8). Should we mark this issue as 'resolved' or do you have another process for that?

Thanks a lot for your logs. I see what's going on here.
For some reason, Yubikey keeps running after failure by suspend/resume (perhaps, because it serves for multiple functionalities of USB HID for OTP, as well as CCID for OpenPGPcard).
This failure mode is not expected by the current implementation of scdaemon, under in-stock CCID driver.

Attached the wireshark log

The workaround in T3825 is for PC/SC driver. So, it is not the case for internal stock CCID driver.
'scd reset /bye' does not let the scdaemon do reset process of the card itself. It resets the transaction of scdaemon.

Workaround is implemented in 2.2.6.

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.

• 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 [1]
• There is also a thread in OpenSC discussing this issue [2] and relevant PRs [3]
• 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) [4]

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.

Yeah, this is better, we got apdu_get_status => sw=0x0 status=7 and I can auth with this version as usual. After sleep-wake cycle it would however fail with pcsc_transmit failed: reset card (0x80100068). Logs attached.

Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)

Thanks, this version of scdaemon executes.

Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).

@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.

If possible, please try with this (patched version of scdaemon):

I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:

It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.

@werner there had to be some mix up, as the log snippet is not mine.

This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed