I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.

Tester reports that this works now.

I got feedback from the user that had the problem. It's fixed with 2.2.9 which contains your commit afaik.

This was a misunderstanding. Import is possible. The german translation of Kleopatra wrongly indicated an error because it translated "unknown certificates" as "ungültige Zertifikate".

Commit rEbd5bcd2dd19ef0b1c3d33a3a388b537ba08a4eb6

it is not due to windows but due to the use of NTBTLS. I have the same problem here... and found it: We call es_fflush to let ntbtls flush its internal buffers but libgpg-error's estream module does no propagate this explicit flush to the cookie functions of ntbtls. Thus ntbtls gets stuck most of the time. I am not sure when this regression happened but it is pretty obvious.

I have logging to a socket always enabled. That may explain why I don't see that error on Unix.

Hi Werner,
I have performed some experiments on the issue I have and the following are the results:

I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.

Hi Werner,
The issue is the following:
I have 2 certificates in the trusted-certificates folder that is searched by gpgsm (C:\ProgramData\Gnu\etc\gnupg\trusted-certs) which I want to trust. When dirmngr starts, it reads the Windows trusted certifcate store (certlm.msc for both system and user - I don't know the path / location of the windows certificates folder outside certlm) and builds the list of certificates to use. Once this list is read and if any duplicates are found in the trusted-certificate folder, it ignores them - they are already present.

I do not fully understand your problem. Can you please explain it with an example and also state the full file names of the mentioned folders?

Do you have any other implementation to test against?

But why is that the case for OpenPGP Signatures, then? The difference does not make sense to me.

The key receives fully trust and thus we get the "green" flag plus the "expired" flag. In my test with OpenPGP the key was not trysted and thus we did not got only the "expired" flag. At some distant past we agreed on these rules.

gpgsm behaves exactly as gpg and as explain in doc/DETAILS. VALIDSIG is issues even for signatures done by an expired certificate. Let me check whey GPGME claims "green" here while it does not not an expired OpenPGP signature.

Wait. Users should not have the ability in the GUI to mess with the CRL cache. That is internal / private stuff. And something for developers, so this should be removed from the GUI altogether.

I think this issue is important as GPGME should not report "Green" / Everything OK in that case and only have the EXPKEYSIG in details.

This is resolved in my opinion. I've tested with some larger CRL's and it worked on Windows.

No longer happens when the good old ldapwrapper is used.

The highest priority I see here is for T3953 which I think is a bug that might result in a good signature shown for an expired, but otherwise valid and trusted certificate.

Still happens. There are also "BER" errors that seem random.

Fixed with: https://commits.kde.org/libkleo/1318d2e13764e736d29c902500c21979e99eef9c

See also T2448

This for importing passwords using a somewhat heuristic approach to accommodate for all the weird things other PKCS#12 implementations do. I have not looked into the specs for a decade and thus can't tell you the reason for that limitations. There might have been one back then. In any case PKCS#12 is the most insecure things in the PKCS suite and it is questionable whether this can be called a standard.

Looks ok now in my tests. I still want to test against more CA's with more CLRs (e.g. COMODO and CACert)

I wonder if CACert intentionally sabotages X509 / CMS.

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.

--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.

it is the decision of the user to use such a certificate.

The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

DCO = Developer's Certificate of Origin. See gnupg/doc/HACKING under "** License Policy" .

I am preparing the patch I am using against 2.2.0. What is DCO?

@perske, may I ask you to send a DCO and an possible updated patch against 2.2 to gnupg-devel@ ? I would like to add it to 2.2.2. Sorry for the delays.

I would suggest that MUAs who care about privacy do no use S/MIME at all or at least direct GPGME to not consider CRLs during signature verification. We don't have such a feature in GPGME right now but I think that is the right place to add it. X.509 is way to complicated to avoid meta data leaks.

i think it's strictly worse, even when the certificates are "trusted" in sense (1) -- with OpenPGP keyserver lookups, at least it is the client who decides which keyserver to use, on what protocol, to look up the given issuer fingerprint.

My comment was only in response to this:

I see at least two different kinds of "trust" here.

If the certificate is signed by a trusted root CA, doesn't that mean that we at least trust the URLs in the certificate chain for CRL and OCSP access?

Making matters worse, i note that some CRLs, like those issued by MIT's Lincoln Lab are quick and easy to fetch over the Internet directly, but hang or timeout when fetched via Tor.

Debian Bug 842291 shows some performance impact of the CRL checks (as well as the potential for privacy problems).

Well, iff we implement that for gpg we also need to implement it for gpgsm.

I don't know if decryption method was changed, but at least the "can't sign using" message appears to be unchanged yet (from looking at the source code).

7 years old and meanwhile Kleopatra has been reworked. Further showing two fingerprint (for the signing and the too be signed key) is confusing. In particular because the passphrase for the signing key is usually cached.

we are now at 2.1.20 - time to mark this one as resolved.