Signature Handling in Emails

There are different formats how to sign the contents of an email:

1. MIME (prefered way)

OpenPGP/MIME or S/MIME standards.

• Example:

      Content-Type: multipart/signed

      Content-Type: text/plain
      This is the text.

      Content-Type: application/pgp-signature; name=signature.asc 
      -----BEGIN PGP SIGNATURE-----
      iQEXYZXYZ
      -----END PGP SIGNATURE-----

• Advantages:
  • attachments are signed as well
  • no encoding problem
  • easy way to encrypt a signed structure
  • all MIME compatible clients show the signed text, even if they cannot understand the signature

• Disadvantages:
  • Some email applications are not MIME compatible, e.g. Outlook in some versions requires the user to explicitely open the body as attachment.
  • In order to implement it, the email application must allow the crypto module to influence the raw MIME structure of the email.
    • GpgOL shows that this is a hard in Outlook, probably impossible to do in some elder revisions of Outlook
    • Webmailers do not expose the inner structure to Browser-Plugins

• Conclusion: This is best for the user experience and compatibility. In short: You really want proper MIME handling like with OpenPGP/MIME!

2. "no-mime" (old term: "clearsign")

Some people used to call this "clearsigned" or "inline", but we believe this to be missleading.

"clear" is something positive, something you would want. Similiar to "inline". But we know that the user experience is much better with the OpenPGP/MIME way of clearsigning the mail body. The chance to see the text correctly with OpenPGP/MIME is much higher and the email is better structured, aka more clearly structured. Therefore we suggest to give the old format a different name: "no-mime signed".

We suggest to use "no-mime signature" as a description of this less wanted method to sign a mail body contents everywhere. No-mime maybe a slightly better solution compared to just using attachments for email communication and the name would point more to the even better solution.

• Example:

      ----BEGIN PGP SIGNED MESSAGE-----
      This is the text.
      -----BEGIN PGP SIGNATURE-----
      iQEXYZXYZ
      -----END PGP SIGNATURE-----

• Disadvantages: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

Discussion

• Simon Josefsson (author of gnutls and one crypto support for gnus) argues for OpenPGP/MIME

NB. “Cleartext Signatures” is a term from the OpenPGP standard and “clearsigned” is a commonly used abbreviation of it. Thus I don't think we shall invent another term for such a precise and well known term. -- Werner Koch 2013-08-26 13:03:04

• Re: Terms that may be "correct" from the technical viewpoint can still be detrimental for the user perspective, because they are counterintuitive and do not provide a natural mapping. The technical difficulties of the no-mime format make the clearsign format of OpenPGP/MIME much more desireable. bernhard 2013-09-13 06:42:00

Old, unused idea from 2013: "double no-mime"

This was new format idea which we had considered for testing in GpgOL 1.2.x for Outlook 2010 and 2013. When a technical method was found to support OpenPGP/MIME construction in Outlook, the idea became obsolete. In 2015 Gpg4win 2.3.0 was released with GpgOL 1.3.0 that supports the preferred methods OpenPGP/MIME and S/MIME.

The body text is included twice, so we call it "double no-mime". You can see its structure in the example below or in attachment:doublenomime.mbox.

• Example:

      This is the Text
      -----BEGIN PGP MESSAGE-----
      XYZXYZ                        <- contains "This is the Text" again, **unencrypted** but encoded
      -----END PGP MESSAGE-----

• Advantage:
  • works with PGP and CMS (less encoding problems, because other character sets can be properly encoded to be email safe).

• Possible disadvantage:
  • Other clients may not display the decoded text, but the surrounding text instead.

It was not tried in GpgOL and with Gpg4all2015 it is likely that full MIME support can be added to Outlook versions (>=2010).

Discussion (old 2013)

I believe that solving a problem in Outlook by defining yet another format is the Wrong Thing. Recent mail privacy discussions go along the lines that the mail format (rfc822) will be used for the foreseeable future but the transport protocol (rfc821) will eventually change. Thus the Exchange/Outlook problems will soon turn non-relevant and thus we can stick to OpenPGP/MIME. This is in particular true because GpgOL already has a full fledged OpenPGP/MIME parser. -- Werner Koch 2013-08-26 13:11:10

• Estimations I have seen claim that Outlook is the dominating desktop mail reading application, so it is worth taking some extra steps to make Outlook work somehow and this includes old versions because their takeup time of new versions is very slow. While OpenPGP/MIME support for Outlook is the best solution, it requires more effort than our Gpg4win Initiative was able to bring to the table. I think we have a responsibility to still give users a second best solution if the best solution cannot be implemented in the foreseeable future. And of course try to get help and funding for the MIME solution. The proposed "double no-mime" format solves an important issue for non-mime solutions: Because of its "protected" copy of the contents, there are less encodings and thus signature verifying problems. Of course, it will only be feasable, if enough clients show the signed copy of the contents correctly flagged. -- bernhard 2013-09-13 06:56:42