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

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.

When dirmngr prefers Tor, this triggers an even longer delay.

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?

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

1. I am willing to rely on you to identify the parties with whom i communicate.
2. I am willing for you to learn about my communications patterns.

When something is a "trusted root CA", i think people are saying (1).

I don't think that saying (1) is (or should be) a proxy for saying (2).

My comment was only in response to this:

Potentially, it's even worse, because the S/MIME certificate could include arbitrary URLs to hit up for a CRL.

This seems to me to be only worse if gpgsm does crl or ocsp lookups for non-trusted certificates. I did not check if that is the case.

I don't have a response to your broader point.

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.

So with OpenPGP, The client could happen to pick a keyserver that the monitoring adversary doesn't control.

With the X.509 CRL lookup, the certificate issuer controls the specific host, protocol, and path that the client is obliged to fetch.

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.

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.

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.

What we could do is to reject loading new CRLs if we are in --use-tor mode.

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

It is the decision of the certificate holder to use such a certificate. but the crl lookups have an impact on the relying party, who made no such decision. this bug report is about the decisions made by the relying party, and the impact those decisions make on:

• their privacy (i.e. "phoning home" without explicit consent)
• the efficiency of their gpgsm-related workflow (i.e. what to do when checking a signature and the CRL or OCSP responder is not responsive)

If anything, --use-tor *avoids* the privacy leakage implied by the lookup, so it's not clear to me that that's the right way to resolve the problem. perhaps the other way around (don't check CRLs *unless* you've got --use-tor enabled)?

That still leaves the efficiency concern, however.

--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.

I would strongly suggest not to use S/MIME if you are concerned about leaking meta data.

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.