And... as long as I read the PCT patches, it is not needed to export those API to users.
It is only needed internally for PCT tests (at most).

I am considering API enhancement, for this task.

This rwlock guarantees access with ctrl->card_ctx is always valid.

Last week:

• libgcrypt and its FIPS mode support
• learn FIPS 140-3
  • confirmed that modern ECC (25519, 448) will be not yet: It's in the draft of FIPS 186-5, though

This week:

• Gnuk maintenance release
• Add more curves to OpenPGP card tests: 25519, secp256k1 for Yubikey and Gnuk

(OpenSSL for FIPS support is a bit tricky, which is described in README-FIPS.md in their distribution. It offers OpenSSL FIPS provider as shared library fips.so.)

Just FYI, NSS offers following API:

With `/etc/gcrypt/fips_enabled/', make check fails by:

If I understand correctly, to conform FIPS, we need to ensure Key/IV pair uniqueness (See "Implementation Guidance for FIPS 140-3", Annex C. "C.H Key/IV Pair Uniqueness Requirements from SP 800-38D").
Use of the API to set IV by any value may be considered bad.

Update: still ./basic --fips fails (for me), because of GCM (18 errors).
Need to fix T4873: Enable AES GCM in FIPS mode.

I applied rC297d31294333: tests: Fix messages to STDERR when FIPS mode is enabled.. Please note that your intention to change check_digests is right, but your patch actually didn't; When a MD algo is not supported, gcry_md_test_algo returns != 0 (an error code), and it "continues" to next entry (before the change).

Thank you for your report.

In agent_write_private_key of agent/findkey.c, when file is available, it returns GPG_ERR_EEXIST error. Thus, private (stub) key will be kept.

Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program:
https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

Last week:

• OpenPGP card tests (finished for Zeitcontrol)

This week:

• FSIJ AGM (on Saturday)
• Check libgcrypt patches around (SUSE, Fedora, etc.)
• Learn about FIPS 140-3

Last week:

• Mostly finished OpenPGPcard test suite (in Gnuk)
  • Tests for ECC curves (NIST, brainpool) are supported
  • ... collecting interop issues of Yubikey/Zeitcontrol/Gnuk
  • Found that failure of test may screw up card reader
    • On failure, it may just do global exit, with no PowerOff of the card
    • Interrupt transfer (notification of card status) goes somehow wrong
    • Next time, when it is used by scdaemon, it causes fatal error of interrupt transfer
• T5495

This week:

• Add test for secp256k1 for OpenPGPcard test
• Dynamically test curves by examining 0x00FA data object

There are multiple issues here.

For KDF setup (00F9), setting it to '' (null, to reset the DO) doesn't work, but it raises 6a80.
Once KDF is enabled, only factory-reset can reset the feature.

I think that a patch like following is needed:

diff --git a/common/ttyio.c b/common/ttyio.c
index c385700de..55468bdf0 100644
--- a/common/ttyio.c
+++ b/common/ttyio.c
@@ -236,7 +236,21 @@ w32_write_console (const char *string)
   n = wcslen (wstring);

Regression with no-unicode font on Windows: T5491

When console font is not a Unicode font, it seems that the WriteConsoleW function may return ERROR_GEN_FAILURE.

Last week:

• T5484
  • support detection of app change to recover from such a situation
• OpenPGP card tests

This week:

• T5495: libgpg-error: build failure without threads
• Finish OpenPGP card test suite for Gnuk/Zeitcontrol/Yubikey
  • Also support other algo than RSA/Curve25519: NIST and Brainpool
    • basically for Zeitcontrol

Thank you for your explanation.

Thank you for your report.
I pushed the fix.

If your token/card is not Yubikey and when it is possible to improve your token/card implementation, I would suggest not follow what Yubikey does for multiple applications; No multiple applications, but each feature with independent access (card+CCID, another card+different CCID, FIDO+HID, ...).

For the problem of external application switch, please test this:

diff --git a/scd/app-common.h b/scd/app-common.h
index dffe1200d..d6e6f4c0a 100644
--- a/scd/app-common.h
+++ b/scd/app-common.h
@@ -194,6 +194,8 @@ struct app_ctx_s {
                       void *pincb_arg);
     gpg_error_t (*with_keygrip) (app_t app, ctrl_t ctrl, int action,
                                  const char *keygrip_str, int capability);
+    gpg_error_t (*check_aid) (app_t app, ctrl_t ctrl,
+                              const unsigned char *aid, size_t aidlen);
   } fnc;
 };

Here is the reference to GID specification:
https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn642100(v=vs.85)?redirectedfrom=MSDN

Let me add the tag "yubikey".
I think that it could be solved in different level, if I were the device manufacturer; And it would give users the best solution.

If something more user friendly is required, it could be possible for higher layer (SCDaemon's command handling) to check verification status beforehand, and do error recovery there.

I don't think we should do automatic error recovery from 6982 to retry decryption/signing, inside CMD_PSO (0x2A) operation.

Thank you.

Thank you.
I apply Diff1487 then Diff1488.

OK. I think that the patch at SUSE is updated one which works.
As I understand correctly, this is a kind of very old patch, which intended to work around old libgcrypt limitation of RSA PSS.

Possible way would be: (for newer card/token of OpenPGPcard 3.4 or later) before crypto operations, we can ask card/token if authentication state is consistent to the one of scdaemon and if not reselect AID.

I'd like to support your use case. Could you please tell me about: How can we distinguish normal failure of 6982 and unusual failure of other application interference which results 6982?

I think that {D1476} is still a sketch (not real code which works). I would guess an intended use, but it's good to have concrete example program which uses the feature being added.

Does the patch really work, or is it a sketch to describe the intended use?

I set the priority 'High' as Yubikey NEO is the last one with source code available, IIUC.

@kianga
Thanks for your log.

Regression Yubikey NEO: T5487

Thank you. Here are my comments.

Today's topic:

• Behavior with PCSC-SHARED: T5484: SCDaemon Not reselect applet and reauthenticate when the card send Security Not Sastisfied
  • I am not confident if I can support this correctly (I have no environment/experience with this use case (too questionable for me)).
  • Any ideas/suggestions/opinions?

Last week:

• OpenPGP card tests in Gnuk/tests
  • Now, it works with Yubikey (somehow), as well as Gnuk and Zeitcontrol
  • And then,
• Created: T5483: Yubikey OpenPGP app
  • I realized that data objects C1/C2/C3 are only available with keys for Zeitcontrol/Yubkey, while those are available on Gnuk always.
• Small bug fixes in 2.2
  • support build with --disable-ldap
  • clean up LDAPWRAPPER
• Possibly major bug fix in 2.2: Yubikey NEO: T5487
• Small bug fixes in 2.3
  • T5122: Importing secret key with wrong passphrase may result GPG_ERR_MISSING_VALUE (should be able to be tried 3 times)
  • T5442: Serial number detection of Yubikey 5 (Yubikey 5 doesn't work after updating to GnuPG 2.3.1)

This week:

• More on OpenPGP card tests
  • Add tests for other types of keys (as well as RSA and 25519).

I think that Yubikey NEO is older than Yubikey 4.

Fixed in rG01a413d5235f: scd: Error code map fix for older Yubikey..
New code for Yubikey 4 or later causes wrong interaction for Yubikey NEO in 2.2.28.

Thank you for your report.

Thank you for your suggestion and making a patch.

For Reset Code (00D3), setting it to '' (null, to reset the DO) doesn't work, but it raises 6a80.
Once it sets by something, only factory-reset can remove the value.

While scd/app-openpgp.c assumes access of 006E composite data object to get its children objects like AID (004F), Card Capabilities (0047), etc., yubikey raises 6e82 error for the DO.

Pushed the change.