multipart/signed mails are missing the micalg parameter, breaks Enigmail

[danc86]

When sup signs a mail it uses the multipart/signed Content-Type with protocol=application/pgp-signature but it doesn't set the micalg ("Message Integrity Check Algorithm") parameter in the Content-Type.

According to RFC1847, micalg is mandatory:

2.1. Definition of Multipart/Signed (1) MIME type name: multipart (2) MIME subtype name: signed (3) Required parameters: boundary, protocol, and micalg (4) Optional parameters: none

RFC3156 covering application/pgp-signature defines the values for micalg:

The "micalg" parameter for the "application/pgp-signature" protocol MUST contain exactly one hash-symbol of the format "pgp-<hash- identifier>", where identifies the Message Integrity Check (MIC) algorithm used to generate the signature. Hash-symbols are constructed from the text names registered in [1] or according to the mechanism defined in that document by converting the text name to lower case and prefixing it with the four characters "pgp-".

Sup actually did previously set micalg=pgp-sha256, but it was dropped in commit d1911d43 with no explanation given -- maybe by accident, or maybe because the gpgme gem doesn't allow specifying --digest-algo?

I also found this older patch about switching sha1 to sha256: http://supmua.org/community/sup-devel/msg00919.html

The micalg parameter seems to be superfluous for PGP signatures since the hash algorithm is part of the signature already and there's no reason I can see why it needs to be specified in the Content-Type. I guess for that reason, most other mail clients tolerate its absence.

However Enigmail considers the missing micalg parameter to be an error, and it doesn't handle it very well either. Enigmail 1.8.x claims (incorrectly) that the mail has a bad signature, in 1.9b1 it gives a generic error about signature verification, and starting from Enigmail 1.9b2 the user just sees a blank message body with no error or signature info at all. The reason I started digging into this issue is because a bunch of Enigmail users complained to me that my mails were blank. :-)

[danc86]

As a workaround I have just patched micalg=pgp-sha256 back into the Content-Type, which is okay since my gpg happens to be using SHA256 for signatures by default. But I guess this is not a good general solution since gpg wants to decide for itself what hash algorithm to use, and the defaults will presumably change in future or across different gpg installations.

This is enough to make my mails readable to Enigmail 1.9.x users though.

diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
index 5befeaa..68b9589 100644
--- a/lib/sup/crypto.rb
+++ b/lib/sup/crypto.rb
@@ -150,7 +150,7 @@ EOS
     end

     envelope = RMail::Message.new
-    envelope.header["Content-Type"] = 'multipart/signed; protocol=application/pgp-signature'
+    envelope.header["Content-Type"] = 'multipart/signed; protocol=application/pgp-signature; micalg=pgp-sha256'

     envelope.add_part payload
     signature = RMail::Message.make_attachment sig, "application/pgp-signature", nil, "signature.asc"

[danc86]

Amusingly, I just found an old Enigmail discussion where the developers wonder how to handle mails with micalg=php-sha1 but the signature is actually using SHA256 -- the messages were ironically produced by sup. :-)

Regardless, Enigmail definitely has regressed in how it reports such errors and so I'm off to try and file an Enigmail issue on Sourceforge about that...

[danc86]

Enigmail bug about the bad error handling when micalg is missing: https://sourceforge.net/p/enigmail/bugs/588/

[danc86]

BTW the same bug probably applies to multipart/encrypted as well but I haven't bothered to investigate that since I don't normally send encrypted mails.