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.

Sample how GpgOL handles this: https://dev.gnupg.org/source/gpgol/browse/master/src/keycache.cpp;6f5f48c3d60e0af52f1a9f0e51f60ee653eeeb31$269

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

After disabling the CRL check again in gpgsm.conf

I see no difference between the last two example stanzas that show you running ../run-verify. Are they supposed to have different output?

I'm aware of the metadata leakage risks of OCSP, and i share your concerns about them.

OCSP can't be the default because it enables a web bug. The responder immediately sees when a signature is verified or a data is encrypted to a certificate.

If CRLs or OCSP are a MUST in a given profile, and the cert chain has OCSP but no CRL, it seems like that profile should then try OCSP, rather than failing.

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks; see gnupg/sm/server.c#option_handler. If you want to check the validity of the cert you check the TRUST status lines. This is what gpgme does for you. An example is gpgme.tests/gpgsm/t-verify. You can run the tests also manually, I do this as follows:

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

I can see no bug here. See my comment over at T4881.

If you want OCSP you need to enable it. CRLs or OCSP are a MUST under the profile we developed gpgsm. This is why --disable-crl-checks by default is not possible. There are lot of interesting things you will come across if you start to use S/MIME. For example you also need to care about the algorithms used for intermediate certificates used to sign CRLs - they need to comply to the policy as well. Or the rarely used PSS padding we encounter sometimes and which is not supported and will probably not be supported

I thought i'd try with other certificates. I started with the one from this website. It also fails to validate unless i supply --disable-crl-checks, apparently because the immediate issuer (the Let's Encrypt CA) doesn't offer CRLs, only OCSP responders. Perhaps --disable-crl-checks should be the default, or at least if there is no CRL available there shouldn't be a failure by default:

Aha, i can get it to say f if i use --disable-crl-checks:

i didn't know that, thanks. i'm now seeing i (which i think means "invalid") in the same configuration:

Add --with-validation to check the validity of a certificate in a listing.

Sorry, I have not yet followed you test plan but given that we have the patch in master for a long time now I think it is okay to port it to 2.2.

For reference, here's an error message from openssl smime when it is trying to verify an e-mail message with no embedded certificate at all (despite it knowing about the relevant certificate):

This is an important fix for a sensible S/MIME use case. Thanks for working on it!

It is actually questionable whether PSS is a better padding scheme than PKCS#1, see
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html . PSS seems indeed be rarely used; quoting Peter from a followup on his writeup: “If I get time over the weekend, and I can find a CMS message signed with RSA-PSS, I'll create a forgery using xor256.”

To summarize: The DGN CRL uses a the RSA-PSS Padding / Signature Scheme. ( https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme )

Fixed in master and 2.2

Really interesting: The code didn't changed since since 2003 and the bug must have been there all the time. It does happen only for 25% of the certificates with CR and LF; the others have padding characters at the end '=' which is also an indication of the end of the base64 block. I wonder why this has not been reported more often; maybe because most people import binary certificates.

Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.

Thomas, please provide a sample certificate. I can't access the intevation site to see whether one of the links has the cert. And pretty please fix the wald certificates!

Hi Andre, did you already get anywhere with this task? Thanks a lot in advance, Joachim

The description comes from gpg/gpgsm while the prompts are from gpg-agent. Thus if the agent has been started with the German local but gpgsm without a local this would explain the behaviour.