Pros and cons of PGP/MIME for outgoing e-mail?

[Bjarni Runar Einarsson]

Hi Bernhard,

Bernhard Reiter <bernhard at intevation.de> wrote:
> 
> thanks for working on Free Software and for discussing questions 
> like this in the open!

And thank you for the friendly reply. :-)

> The short answer (from someone that was in the project team of S/MIME 
> implementations for mutt and kmail and support for PGP/MIME for Kontact
> Mail and the Outlook plugin for Gpg4win (my roles did include technical 
> coordination, analysis and testing.):
> 
> I am on the PGP/MIME side of things, I recommend it as default for
> sending out  emails. See also http://wiki.gnupg.org/SignatureHandling .
> 
> a) for encrypted emails, there is no drawback. Every email client just
> have to be able to deal with message/rfc822 mime-parts anyway.

I actually disagree, the drawbacks are significant if you broaden the
scope to include users of mail clients that do not have native support -
which once you step out of the Free Software bubble, is most mail
clients.

As discussed in my post, if you have a PGP key but are unable to use a
PGP/MIME aware mail client for whatever reason (work supplied laptop, no
Internet outside of Internet cafés etc.), then you will not easily be
able to receive and decrypt PGP/MIME attachments, even if you have GnuPG
installed, because if you download the raw encrypted payload for
processing offline, then after decryption you end up with a fragment of
MIME and tools for working with such fragments barely exist outside the
world of development tools (downloading the raw message source and
manually feeding that to mutt, after manually adding the leading 'From '
delimiter is absolutely possible, but is not something you can expect a
normal user to do, and not something a techie would enjoy doing on a
regular basis).

If this is carried to its logical conclusion, a burden ends up being
placed on the user of a PGP/MIME enabled mail client - he has to carry
around in his head a mental model of the technical capabilities of those
receiving encrypted mail and *manually* change the format of his
outgoing mail if he wants it to be readable by less technically
privileged recipients. All in all, this goes way beyond what I consider
an acceptable user experience.

Of course, today encryption is so rare that the only folks encountering
this problem are nontechnical people, journalists and activists and the
like, and they just give up and us something else to communicate and we
don't hear from them again. This issue came to my attention however, due
to the rise of webmail and attempts to write plugins to communicated
using PGP (although Javascript is getting so powerful, they are likely
to overcome this in the near future, with a select few compatible
webmail services), and I'm told this is also what happened with the K9
mail client and APG.

I'd like Mailpile users to be able to easily exchange secure content
with these users, even if their tools are a bit on the primitive side.

I will however freely admit that I am not a veteran of the PGP
encryption field. I've worked with it off and on for the past 20 years,
but Mailpile is my first serious attempt at implementing a full stack.
So perhaps I am overestimating the impact here?

> b) for signatures, https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime
> lists the drawback that some transport agents will modify attachments. In the
> past  I've published a number of patches and problem reports to Mailman, so I
> know  this issue quite a bit. It is due to a missdesign of the python email
> package  and it should be fixed. (And it is fixable by a reasonable effort).

Yes, Mailpile is written in Python and I've had to bend over backwards
in order to validate and generate signatures. I am pretty sure I still
have bugs to work out there, trying to compensate for the Python
library's flaws without rewriting the whole thing is, long term, a
losing game. It is tempting to blame the Python libraries, but the fact
is that they do generate valid MIME - after swearing at Python for
months, it dawned on me that it's probably the PGP/MIME standard that is
just being too picky.

This is part of what I meant by tightly coupled in a previous e-mail -
unless MIME libraries and interfaces are explicitly written with
PGP/MIME in mind, and carefully tested, they easily end up being
incompatible. MIME is a forgiving standard, PGP/MIME is emphatically
not. This causes headaches for people trying to implement PGP/MIME and
any source of friction like this reduces tool support and uptake.

> Another drawback is that some proprietary email clients (like outlook)
> do not  enable someone to influence the mime-structre. This is the bigger issue
> of course.

Exactly.

> On the other hand, the advantages are clear and PGP/MIME seems the best
> design given current standards and practure of SMTP and MIME. And given a
> reasonable mime library, the implementation for creation is much easier as for
> parsing and should not pose a major problem.

In my experience both generating and validating PGP/MIME signatures is
very error prone if you are saddled with a MIME library that has
different ideas about things. You are right, it is the best standard
we've got at the moment, but only by virtue of being the ONLY standard
we've got. All the other issues aside, I don't think anyone will
seriously argue that an e-mail encryption standard which transmits the
subject line in the clear is a "good standard". It's silly and we can do
better.

So really, I guess I'm asking this community for feedback on two things:

1) Are these problems as common as my experiences imply, or am I just
really unlucky?
2) Is there any interest in trying to improve the standards?

-- 
I make stuff: www.mailpile.is, www.pagekite.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: </pipermail/attachments/20141124/122bf65c/attachment-0001.sig>