On Mon 2022-01-24 14:02:33 +0100, Justus Winter wrote:
> navse@mailbox.org writes:
>
>> I have been using Notmuch with Emacs for a couple of days and it has
>> been working great, except for when I open mails from a certain sender
>> with S/MIME signed messages, Emacs will freeze up for about 4 minutes.
>> Opening the expandable signature inside of the Email repeats the lag.
>
> Just to point you into the right direction, I'm pretty sure that this is
> gpgsm reaching out to a network server, maybe to fetch certificate
> revocation lists or something.

I think Justus is on target about what the issue is here.

GnuPG upstream appears to think that the privacy and latency costs of
default revocation checking are an acceptable tradeoff:

    https://dev.gnupg.org/T3348

The S/MIME standard barely touches on revocation checking, and doesn't
seem to mandate it or refuse it:

    https://www.rfc-editor.org/rfc/rfc8551.html

The IETF LAMPS working group has adopted a document about guidance for
end-to-end cryptographic protections for e-mail, which currently has a
FIXME in the section about revocation checking:

    https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-mail-guidance-02.html#name-checking-for-revocation

I'm the original author and editor of that draft, and i would be *very*
happy to get additional feedback/suggestions/contributed text about what
folks think *should* be done here.

If you might be interested in making a contribution, the LAMPS WG
mailing list is spasm@ietf.org, or you can reply to me on this thread,
or you can open issues or merge requests at
https://gitlab.com/dkg/lamps-header-protection

Arguably for notmuch, one of the ways to address this (or at least to
amortize the costs) would be to cache the results of signature
verification so that it doesn't happen for every message every time you
view a thread.  Presumably a cached sig verification could also skip
over cert revocation checks.  See id:87sgodxlk0.fsf@fifthhorseman.net on
this mailing list (from me, Subject: "performance on long
encrypted+signed threads" Date: 2019-09-30) for more discussion of the
problem.  Regrettably, i haven't made any progress on fixing it.

        --dkg