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.

I found a solution for master and 2.1.19 which minimizes the risk of regressions:

I think this is now resolved.

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

Thank you.

I uploaded the certificate files. For a test please do the following:

Sorry, a fix didn't made it into 2.2.18.

I give this normal priority even if it is a whish because I have the same whish and already have some code around that would make it more comfortable, especially if it is used directly in GpgOL.

Thanks for the sample certs. I noticed the posts but had not the time to look into them.

It appears (for me) correct behavior.

Works for me! :-)

I have a larger change for the wait code in the works. This will go into 1.14.0 but not in 1.13.1

I had to patch strace to follow threads but not forks (P8) and then when built with support for -k I tracked it down: In the inbound handler we close the fd immediately on EOF. However the upper layers don't know about it and a select fails with EBADF. Of course we could ignore the EBADF, figure out the closed fd and restart. The problem is that another thread may have opened a new oobject and that will get the last closed fd assigned - bummer.

Just noticed that due to me failing to properly understand re-entrant locks the run-thread test is broken at least on windows in that it never waits for completion. So running out of filedescriptors is to expect. I'll fix the test.

My observation from running the verify threaded test on windows is that it does behave differently. The EBADF does not occur.

Something(tm) closes an arbitrary file descriptor behind our back. Not easy to track down because strace can not trace only threads - it always wants to trace all children as well - which is a bit too much and leads to other problems.

A newline is required by the PEM standard.

Thanks, the mentioned OpenSSL option should be helpful.

A high level test description is:

1. Configure both gpgsm and dirmngr to use OCSP.
2. Import the responder signer certificate with gpgsm --import.
3. Use a certificate with OCSP responder extension present, or configure a default OCSP responder in dirmngr.
4. Configure your OCSP responder to identify itself with key ID (and not subject name)
5. Attempt to sign or verify with gpgsm.
6. You should get an error, with dirmngr logs showing that the responder signer certificate could not be found.

Thank you for a quick fix (despite this being a minor problem).

Do you have any test cases? Note that T3966 is due to missing support for SHA-256.

We only supported SHA-1 signed OCSP requests. Fix will go into 2.2.16.

Thanks to your very good analysis, this was easy to fix.

Interesting tinge: The main CRL of the dgn.de CA uses a nextUpdate in the year 2034 (15 years in the future) which would force dirmngr to cache the CRL until then. However, the CRL of the intermediate certificate has a nextUpdate only one month in the future. There is currently no entry in that second level CRL, so their idea might be that an updated second level CRL will also trigger a reload of the main CRL. I have not checked how we implement that in Dirmngr but I doubt that such a thing will work for us and that it is in any way standard compliant.