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.

Yeah, lets do that. Commit 8489b12 to go into 2.1.17. Thanks.

What about putting in the suggested patch as an intermediate step towards a full
solution?

D198: 866_gnupg-2.1.14.diff

With T1590 irrelevant, issues 1862, 1970, and 2336 resolved (very special
thanks to everyone who helped in fixing them!), this is the only problem left in
version 2.1.14 that forces me to use a patched version of gpgsm for my webmailer.

My patch from 2014-04-30 works, but by mistake ("if (cmp < 0)" in place of "if
(cmp > 0)" it selects not the newest but the oldest one of the ambiguous
certificates what is bad in the DFN PKI because an older one of the certificates
is revoked, so I attach a new patch against 2.1.14.

Ah, I see. The GUI interface affects the S/MIME algorithm, not the general
one. I don't know why I didn't put that together sooner. Well, I'm glad that
it revealed the minor bug anyway.

Anything else I can do to help?

For what it's worth, with the following trivial patch the decryption works:

diff --git a/sm/decrypt.c b/sm/decrypt.c
index a560272..aa6e874 100644

• a/sm/decrypt.c

+++ b/sm/decrypt.c
@@ -74,9 +74,9 @@ prepare_decryption (ctrl_t ctrl, const char *hexkeygrip, const
char *desc,

    log_printhex ("pkcs1 encoded session key:", seskey, seskeylen);

  n=0;

• if (seskeylen == 24)

+ if (seskeylen == 24 || seskeylen == 16)

{

• /* Smells like a 3-des key. This might happen because a SC has

+ /* Smells like a 3-des or AES key. This might happen because a SC has

          already done the unpacking. */
     }
   else

I am not sure this is a good solution, though, it is probably better to somehow
pass along the information whether the padding is already stripped or not.

Kind regards,

Lorenz

This is likey due to the card already decoding the pkcs#1 - we need to look
closer at this use case.

For reference, I have a OpenPGP v2.0 card from "ZeitControl".

I think the card will always remove the encoding internally and only return the
plaintext, as far as I can tell from
http://g10code.com/docs/openpgp-card-2.0.pdf, Section 7.2.9

This should be something similar to gpg --always-trust

yes there are no remaining problems that I can see here.

Thanks -> resolved.

aheinecke: Did you had a chance to test this with 2.1.7 or master?

Pushed as 5e1a844. Thanks.

Ok now I found kbxutil and learned about ephemeral certificates (Yep reading
helps) ;-)

After the first import kbxutil lists the Root certificate three times.
Twice with ephemeral flags, once without. So gpgsm -k shows it only once. But
kbxutil --find-dups already lists those duplicates.

fpr=11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 recno=5 7 8
fpr=98:2D:D4:1D:BE:91:EE:72:B3:B8:43:33:F2:21:F7:74:64:39:08:7E recno=2 4 6

Now after the verify gpgsm takes the first of those certificates and unsets the
ephemeral flag as it was used as part of a complete trustchain. (sm/certchain.c:

If the first certificate was ephemeral we now have two certificates that are not
ephemeral but are the same and gpgsm -k shows both.

My solution is to check in keydb_store_cert for ephemeral certificates and
instead of inserting those again without the ephemeral flag to remove the
ephemeral flag of the existing certificate.

It's still unclear to me though why there were three certificates (Two ephemeral
and one normal) I would have expected one ephemeral and one normal certificate.

Patch attached.

D287: 648_0001-sm-Fix-cert-storage-for-ephemeral-certs.patch