Handle PKCS#7 signedData (S/MIME single-part clearsigned)

Subject: Handle PKCS#7 signedData (S/MIME single-part clearsigned)

Date: Wed, 4 Dec 2019 00:51:48 -0500

To: Notmuch Mail


From: Daniel Kahn Gillmor

PKCS#7 is the binary format used by Cryptographic Message Syntax

S/MIME (RFC 8551) specifies a number of different "smime-type" PKCS#7
wrapping layers.

Until now, notmuch has only handled multipart/signed PKCS#7
clearsigned messages.

But S/MIME has another form of clearsigned message named "signedData"
(or as the smime-type parameter writes it "signed-data").  This type
of clearsigned message can transit through mangling MTAs slightly
better than multipart/signed, because an S/MIME-ignorant MTA will
treat it as an opaque blob.  This avoids the scenario where a legacy
MTA tampers with the body of a multipart/signed message in violation
of ยง3 of RFC 1847, breaking the signature.

However, PKCS#7 signedData objects are also opaque to legacy
(S/MIME-ignorant) MUAs, which can't read the contents of the
clearsigned message because they don't know how to unpack the PKCS#7.

notmuch is currently such a legacy MUA, but this series will change
that, giving notmuch the ability to read the contents of (and verify
the signatures on) PKCS#7 signedData parts.

Note that this series does not yet handle PKCS#7 envelopedData or
authEnvelopedData (the S/MIME encryption layers, which differ only in
ciphertext malleability), and it also does not handle compressedData.

The framework it puts in place should be useful in handling those
kinds of additional S/MIME layers, as long as GMime is capable of
handling them.  But the series is long enough without adding that
additional complexity, and I'd love to get some review of it before i
carry on working on the decryption parts.

The series starts with a small number of cleanup/framing patches, then
adds a sample S/MIME signedData message and a bunch of known-broken
tests, then proceeds to fix each of the tests.

Several of the patches should be simple to read and uncontroversial (I
hope!), and I welcome/encourage merging of those patches to reduce the
length of the remaining series.

As always, feedback and critique and questions are welcome :)


notmuch mailing list