avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

[Daniel Kahn Gillmor]

Hi GMime and GnuPG developers--

sorry for the cross-posting!  coordinating this kind of thing
cross-project is tough.

I recently learned that default handling of signed S/MIME mail with
GnuPG causes an inherent metadata leak about the user's activity:

    https://dev.gnupg.org/T3348#110132

As a MUA developer, I'd like my MUA to simply handle as much crypto as
it can on the user's behalf automatically, correctly and silently,
without needing any special configuration or asking the user to make any
tough tradeoffs that they might object to.

What kinds of tradeoffs are objectionable?  Performance tradeoffs are
probably OK, since they're user-visible, and can be mitigated by
disabling crypto.  But metadata leakage by default seems really
problematic, because (a) it is invisible to the user, and (b) once done,
it cannot be undone.

So my question for GMime and GnuPG developers is how a MUA that uses
GMime should approach this.  Given that GMime relies on GnuPG, and GnuPG
basically says "if you process S/MIME mail, you'll leak metadata", what
is the best way to instruct GMime to say "handle as much cryptographic
mail as you can without leaking metadata"?

GMime 3 has greatly simplified its crypto handling interface, and it has
moved fully to GPGME on the backend, which i appreciate.  However, i
think the interface is now so clean that i don't know how to either:

 * tell GMime to disable crl checks

or

 * tell GMime not to verify S/MIME signatures at all

Either of these methods would address the default metadata leakage
concern, but the first choice provides more functionality to the user.

i note that GPGME offers gpgme_set_offline(), which tells it to avoid
talking to the network entirely.  Maybe that can be exposed by GMime
somehow?

i don't think invoking gpgme_set_offline(true) would break other uses of
GPGME inside GMime or any other sensible MUA, but if there's a fear that
it does, i'd like to hear about it.

Note: i'm perfectly happy to allow the user to override this choice if
they *want* to leak metadata, but i don't think that my MUA should do
that to the user by default.

I'm willing to write patches if there is a reasonable plan forward.

Any suggestions?

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180202/7208286a/attachment.sig>