You are right, the new 3.4 cards support brainpool curves in addition to the nist curves.

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

If you mean OpenPGP Card v3 standard, no it did not support cv25519 ed25519, but some other curves up until v3.4. So if there is a specific specification bringing this feature, can you might refer to the specific version? Otherwise, I think this task is still valid.
I remember the problem being the card manufacturers that are not interesting in cv25519 (yet).

Support was added in version 3 card.

Applied and push the change above in rG920154370834: scd,nks: Fix caching keygrip..

For the first issue, I pushed the change in rGc3a20c88fb30: scd: Fix an error return for READKEY..

Fixed in rG006944b856ee: scd,nks: Fix SEGV for learn for older card..

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.

Stable now and works as expected. Thank you!

This was fixed in 2.2.24 with commit rG7f765a98fd662

The above workaround may not be necessary because another code path sets the algorithm string as seen in

$ gpg-connect-agent "SCD READKEY --info -- NKS-NKS3.4531" /bye
S KEYPAIRINFO 39400430E38BB96F105B740A7119FE113578B59D NKS-NKS3.4531 - - rsa2048

The following patch fixes the crash:

diff --git a/scd/app-nks.c b/scd/app-nks.c
index 47be7cd85..4d925dccd 100644
--- a/scd/app-nks.c
+++ b/scd/app-nks.c
@@ -871,7 +871,7 @@ do_learn_status_core (app_t app, ctrl_t ctrl, unsigned int flags,
                                 id_buf, strlen (id_buf),
                                 usagebuf, strlen (usagebuf),
                                 "-", (size_t)1,
-                                algostr, strlen (algostr),
+                                algostr, algostr ? strlen (algostr) : (size_t)0,
                                 NULL, (size_t)0);
             }
           xfree (algostr);

How about distinguishing CARDNO and application specific SERIALNO?

Thanks again for your report.

I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.

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 ....:

For SPR532, we need following.

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

I forgot that we have LOCK and UNLOCK commands in scdaemon. This was implemented around 2005 but there are no more users in gpg meanwhile.

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

Pushed the change.

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.)

This doesn't help. I think that's because after

flush_cached_data (app, dobj->tag);

do_writecert does

do_readkey (...)

which fills the cache again.

Caching issue. do_writecert in app-piv flushes the cache but may be the wrong DO. Can you try to

I have added a workaround to Kleopatra: rKLEOPATRA57cf71b043d198f85270eb3b8782de6277b8b889

I observed that the card reader's going erroneous state when I removed a card during its communication.
In this state, it never reports the card removal by the interrupt transfer.
I applied rG920f258eb601: scd: Internal CCID driver: More fix for SPR532. for this problem.

The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.

This is also what I found out with my tests with the libvirt usb: removing and redirecting back the device got it working again.

Testing more, I managed to encounter failure with physical usb.
Once in this failure mode, I need to remove the card reader from USB and reinsert again.
I need to figure out a sequence to avoid this situation and to reset the card reader correctly.

I tested with physical usb, did multiple operations with external events (insert/remove/etc. for card). I haven't seen any problem (if so, I were doing more fixes), so far.

Ok. Tried to test this with master, but failed. I got it compiled and installed, and it actually detected the first removal after reboot/suspend/reader attach/whatever reason, but after that when I inserted the card back, it didn't function anymore. I suppose you also tried that? I mean that's the use case, I suppose: to be able to remove/insert the card reliably all day long.

Currently, yes. After some testing, I'll backport it to 2.2.

Nice, thanks! If I want to try this fix, should I just compile the master tree?

This is everything lsusb knows about the device:

And please report the output of lsusb -d 04e6:e003 for the information of the card reader.

@turkja Thanks for your information.
May I ask you one thing?
Please show me the usb VID:PID of your card reader.
Is it 04e6:e003?
You can examine a line of the output by lsusb.

Just wanted to add to my initial findings:

• I was not using proprietary drivers (libscmccid.so.5.0.35), because the installer script fails to install on default CentOS 8 pcsc-lite. So the distribution pcsc-lite also doesn't have this issue.
• Fastest way to test this condition is to just detach/attach the reader device.
• Proprietary drivers doesn't support secure pin entry!

Thanks for sending.

Here is the output for an SCM SPR532

Bus 001 Device 123: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader

Is it an alias of SPR532? Please show me the USB vendor ID and product ID.

Okay, I have the same problem at my office and thus I should be able to figure out the reason. I have ignored the problem until now because the wokraround is easy enough and in most cases I authenticate with my token anyway. But yes, this needs to be fixed.

Thanks for prompt answer!

Thanks for the detailed report. Does the green LED blink fast when it does not work?

The data object 0x00FA is now supported. And other changes are not needed.

I am the worst. I totally forgot about this.

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

We won't do such a interface now.