PGP/MIME signed message with user signature verification failed
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
A PGP-signed mail sent via Horde/IMP fails to verify in Enigmail when a user signature block (prefixed with "-- \n") is present. Mails without this user signature verify OK.
Horde/IMP runs on a debian system (GnuPG 1.4.12-7+deb7u3) where Horde/IMP and Mutt verify PGP-signature OK on received mail with or without user signature.
Thunderbird runs on an ubuntu system (GnuPG 1.4.14-1ubuntu2.1) where mutt also verifies OK both type of mails.
"-- \n" is forbidden according to the OpenPGP standard (RFC 4880). The "failure" is not with Enigmail, but with Horde/IMP. Trailing spaces must be transcoded either using quoted-printable or base64 encoding.
Horde/IMP uses OpenPGP-MIME. As far as i understand the relevant RFC3676 there is an exception for this type of signature ("4.4 Usenet Signature convention") permitting this representation which also verifies OK with the commandline mailer mutt.
To assign the problem correctly please have also a look to my relevant mail snippet(note the blank after the signature tag "--"):
== snip ==
Last edit: Patrick Brunschwig 2014-02-01
Please read section 3 of RFC 3156:
"... implementations MUST make sure that no trailing whitespace is present after the MIME encoding has been applied."
I'm afraid, but this issue persists. Currently all mails I get which are signed by Horde/IMP cannot be verified by enigmail.
At first sight, it seems like the RFCs 3156 and 3676 contradict each other. I'm really no expert in this, but I would suppose that RFC 793 could be applied here, to prevent this conflict: "be liberal in what you accept from others". I know it is quite sensitive to be liberal with regard to verifying the signature, however, as I understand this, it is only a question of tolerating trailing whitespace in certain positions.
Therefore I'd like to ask to maybe reconsider this issue, as interop is kind of broken currently. Alternatively, maybe this issue could be discussed with the corresponding Horde developer
http://bugs.horde.org/ticket/12952
in order to get this fixed.
Thanks.
You can't be liberal in what you accept, when it comes to cryptographic signature verification. Either the algorithm matches or not. You don't have the option to say:"oh, well, this mail comes from HORDE, where we know that it errornessly keeps trailing spaces unencoded. Let's try to fix this on our side and recalculate the signature with this bug in mind". Who or which error from which mailer comes next needing such bug compensation?
RFC3676 does not apply, It simply does not deal with signed messages, these are covered by other RFCs (3156 and 4880).
The developer of Horde has been pointed here, so let's see what he has in mind to cover this bug.
Last edit: Ludwig Hügelschäfer 2014-09-20
The question is not what Enigmail accepts or no, but what gpg does with it. Trailing spaces lead to invalid verifications in all GnuPG versions that follow RFC 4880, unless they are configured to accept RFC 2440.
I am really no expert in this. Sorry, I do not mean to offend anyone, or call this a bug in enigmail - I simply do not know whether it is or not.
I am just frustrated about the situation that this ticket is in the state "wont-fix" and the horde bug is in the state "Not a bug".
@Mr Hügelschäfer: Though again, I'm not an expert, but actually I'm not asking for a special handling for Horde-sent-emails. From my humble "user's" point of view, mutt successfully verifies these emails and mutt does not have "special handling" for Horde mails. And I did not hear that mutt signature verification is "insecure" or whatever. Again, this is just my humble opinion.
I have no clue why mutt can successfully verify these mails. Maybe mutt passes --rfc2440 to gnupg. Maybe the mutt receiver has this in his gnupg configuration file. Note that this standard is obsoleted by rfc 4880.
There's nothing wrong with Horde. This was discussed at length at https://bugs.horde.org/ticket/12952
There is absolutely nothing wrong with trailing spaces in the raw part data, so that's irrelevant.
If trailing spaces still exist AFTER Q-P encoding (or IMP is not sending via Q-P encoding), then the sender is using a broken version of PHP and needs to upgrade (see Horde ticket above, discussing Q-P broken-ness in PHP and the patches that I made to fix it upstream).
Nothing Horde/IMP can do about installations running old, broken versions of PHP unfortunately.
Thanks for the update and the hint to upgrade PHP!