People often suggest that inline PGP signatures in e-mail are somehow more compatible or more acceptable than using PGP/MIME. This is a mistake. Inline PGP signatures are prone to several failure modes, up to and including undetectable message tampering.
Some of the problems include:
Some common implementations of inline PGP verification (e.g. enigmail) fail to robustly indicate to the user which part of a message is actually signed, and which is not.
RFC 4880 specifies the "Cleartext Signature Framework" but fails to specify what character encoding (e.g. ASCII, UTF-8, BIG-5, etc) or content-transfer-encoding (none, quoted-printable, or base64) must be used for the cleartext in question. As a result, inline-signed messages that use non-ASCII text are easily broken by MTAs that are willing to re-encode message bodies.
Some people prefer to write messages in text/html format; inline-PGP can't handle these messages cleanly.
Some MTAs and MUAs are willing to re-flow message bodies, depending on the content type. An inline-PGP-signed message that gets reflowed will often have the signature break.
Inline-PGP-signed messages can't properly sign subsequent or alternative MIME parts. This means attachments aren't covered by the signature, and most multipart/alternative composed messages (the most common are text/plain+text/html) are likely to have one of the message parts contain a broken or unreadable signature.
The lack of a signature on attachments presents a UI challenge for MUAs. It's possible to attach a file to an inline-PGP-signed message, which may subsequently be presented to an unwary user as though the attached part was also signed.
Inline-PGP-signed messages derive their Content-Type and Content-Transfer-Encoding from the headers of the associated message. Since the headers themselves are not signed, it's possible to interpret the same bytestream in multiple ways, depending on the available charsets. This presents an opportunity for mischief, since the bytestream itself verifies correctly, but the content may mean something different.
The two messages presented in iframes below contain the same inline-PGP-signed bytestream, but they present different information to the user because they are served with different charsets (you can also download them for signature verification: big5, iso-8859-8).
Note the price difference between the two quotes.
Most of these problems go away with PGP/MIME signatures. For example, PGP/MIME protects the Content-Type and Content-Transfer-Encoding within the message signature, so those messages are not susceptible to tampering by header substitution. Modern MUAs should only generate PGP/MIME signatures, and should not generate Inline-PGP signatures.
Modern clients that want to be backward-compatible with existing messages or archaic clients by providing inline-PGP verification should consider the risks outlined above. Is it worth exposing the user to the risks and failures described above in order to add this compatibility feature?
written on: 2014-02-18