Apparently only one of the secret keys is actually imported: the decryption key, but not the signing key.

The PKCS#15 support has meanwhile received a major update. Thus we need to test with the other cards again. If there is something special for to do for a certain task, a new subtask should be created.

Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.

@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.

The show error is due a missing translation. What happened was that the translation was marked fuzzy and this marker was removed not realizing that the string really changed. The change was "...in the GnuPG system" -> "...in the %s system" which had been done to allow for different gpg names.

Start from scratch on a german system, even when you do a gpg --version it shows it is in german. Then import a PKCS#12 container and the dialog is in english.

A wild guess is that the different envvar systems we have in use are the culprit. It is anyway time to get this straight.

thanks, @werner!

Okay, okay, I had in mind that we print them because we used to put such certificates into the ephemeral certificate storage because it is not possible to check the signature. But I reliazed that this changed quite some time ago and we can view these error messages as informative only. They are now not anymore printed int quiet mode. Well, for 2.3 - not sure whether I should backport this to 2.2.

Thanks for the fixes, @werner!

Done in 2.2 and 2.3. The issuer certificate thing is a real error message and thus it should be printed.

Other ways that gpgsm --quiet is not quiet:

Reopening this as I have seen such hangs multiple times during testing. When importing multiple keys with Kleopatra at once this can be reproduced sometimes.

This has been resolved with rOb05416e7bc41

The CRL states how long it is valid and we cache it for about that time.
OCSP responses are by definition not cachable but we allow for a clock skew of 10 minutes.

Its a year since I worked on the mentioned wait code change (wk/new-wait branch) and I more or less forgot about it. it will to risky to release that as 1.14 so this change and the fix to this bug needs to be postponed to 1.15. Sorry.

This appears to still be a problem, despite upgrading to libksba 1.4.0:

GnuTLS seems to have some CMS support; see https://gitlab.com/gnutls/gnutls/-/issues/227 .

Seems to be fixed now.

Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.

Finished if an existing key is used. See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples.

See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples on how to create a cert

Signing using ECDSA does now also work. Tested with 3 in disk keys: nistp256, nistp384 and RSA and verified using gpgsm and Governikus Signer.

Basic en- and decryption test against Governikus_Signer has now been done. Beware: I had to add a debug option to gpgsm to workaround non-compliance in algorithm support of Governikus; see the rG68b857df13c8a4e6cae5e3a29fd065bf90764547 for details.

It works for me(tm).

Done for master

I am working on the Telesec Signature Card v2. I will add encryption support to gpgsm.

We do this now always if --auto-issuer-key-retrieve is set. Also backported to 2.2

Data (ie.e CMS) signatures do now also work.

Okay certificate and CRL checking does now work with rsaPSS. Need to work on data signatures and check the compliance modes.

I started to work on it so that I can actually use the certificates on my new D-Trust card. This will be a verify-only implementation.

genkey for Ed25519 works now with libksba in master.

For public key, it's done.

Thanks.

The problem was the comment field which was not expected in an rsa key. However ist makes sense to allow additional fields and thus I pushed a change to Libksba.

NIST P-256 key generation looks good.

OK, i've asked on gnupg-devel.

Please use the mailing list for help on generating keys. I would also suggest to use GnuPG master for such experiments.

There are two code paths to generate key: gpgsm_genkey and gpgsm_gencertreq_tty. Latter is partially supported with card key.
Firstly, I'm going to work for T4888.

This should work well with libksba master and gnupg/sm master.

The commits in 2019 (for libksba and gnupg/sm) handles the problem (of key generation using card).

In T4883#133467, @werner wrote:

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks

@werner wrote:

The return value that was mapped to invalid value was "SW_WRONG_LENGTH" so I tested using the codepath for the SW_EXACT_LENGTH sw return value, too and it worked for readcert.