Pros and cons of PGP/MIME for outgoing e-mail?
Bjarni Rúnar Einarsson
bre at pagekite.net
Sun Nov 23 19:05:03 CET 2014
Samir Nassar <samir at samirnassar.com> wrote:
> I would care more about the arguments if you were able to re-state them
> while dropping references to legacy email clients. I don't think new mail
> clients have an obligation to be backwards compatible.
> If you, and others, think the PGP/MIME RFC is incomplete or invalid,
> then that's a conversation I want to hear.
Oh, I absolutely do. I think it's fundamentally lacking. Key points:
1) It tightly couples MIME parsing and PGP processing, making it hard to
compose "does one thing well" type tools and requiring quite invasive
plugin APIs in order for people to be able implement PGP/MIME from a
2) It is hard to implement correctly. The white-space handling
3) It does not protect any of the RF2822 message header - it doesn't
even verify the integrity of its contents.
Flaws 1) and 2) are why we still keep seeing new mail applications
written that do not support PGP/MIME, and still see PGP email projects
that can't do it either. See Mailvelope, APG/K9, more. The developers of
these projects are not lazy, the standard is just a pain in the ass to
implement. I know, I've done it. Flaw 3) is one of the reasons why big
chunks of the security community write off PGP and e-mail as a lost
This was touched on in my post and a alternate strategy for encrypting
mail was suggested that does not have these flaws.
I am disappointed that you think it's okay to just ignore real world
compatibility and dismiss all the mail clients that don't implement
PGP/MIME as "legacy". That's a very lonely ivory tower, and with that
attitude our community will never help the masses communicate securely.
I make stuff: www.mailpile.is, www.pagekite.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 213 bytes
Desc: OpenPGP Digital Signature
More information about the Gnupg-users