Add support for PGP / MIME

[koto]

From tankred@whiteout.io on June 06, 2014 11:36:13

If you're interested in supporting PGP/MIME for attachments, we have written MIME-codec for our application:

MIME encoding: https://github.com/whiteout-io/mailbuild
MIME decoding: https://github.com/whiteout-io/mimeparser

The code is MIT licensed and is part of our email.js effort:
http://emailjs.org

Looking forward to your feedback. Thanks
Tankred

Original issue: http://code.google.com/p/end-to-end/issues/detail?id=32

[koto]

From evn@google.com on June 06, 2014 19:05:29

Cool, thanks!

Summary: Add support for PGP / MIME (was: PGP / MIME)
Labels: Type-Enhancement Priority-Low Component-Logic Compatibility

[koto]

From evn@google.com on June 16, 2014 03:59:47

We might still support PGP/MIME, but for now we are considering making the EMail client expose an API to add/download attachments.

Status: FixLater

[koto]

From toberndo@yarkon.de on September 01, 2014 04:03:27

but for now we are considering making the EMail client expose an API to add/download attachments

This sounds like you plan to use PGP/Inline and encrypt the attachments separately. Which makes sense to me from a usability perspective: PGP/MIME in a webmail environment would mean you have to download & decrypt the complete message (possibly including large attachments) only to read the text part.

But the downside of the PGP/Inline + attachments approach is that while you can ensure the integrity of the separate parts with signatures, you can't verify the integrity of the complete message (which is what PGP/MIME does).

Would you say this is acceptable, or do you see any other approaches to ensure message integrity?

Thanks

[koto]

From evn@google.com on September 23, 2014 14:13:58

You are right Toberndo. We loose that with our envisioned design, unfortunately. Also, file names would leak in the design we are proposing, which is less than ideal.

We'll start working to add support for OpenPGP/MIME to the library.

Status: Accepted

[koto]

From evn@google.com on September 23, 2014 14:15:03

(to clarify, that's just to the library so that we can experiment but support for the extension might come later at some point)

[koto]

From tankred@whiteout.io on September 24, 2014 09:26:37

Awesome! Are you using the email.js libs or rolling your own?

[koto]

From evn@google.com on September 26, 2014 22:12:38

We are trying to figure that out now :-)

[koto]

From tankred@whiteout.io on September 27, 2014 00:14:13

I see. We've been using the libs in Whiteout Mail in production for quite some time now and they are quite battle tested. Especially the mimeparser, mimebuild and dependencies that would be required for PGP/MIME.

Mozilla have migrated to email.js for the stock email App in Firefox OS 2.1 and we we're now starting to get upstream bugfixes from them. So stability should improve. https://bugzilla.mozilla.org/show_bug.cgi?id=885110 We'd love to work with together with end-2-end on this. We've been evaluating using e2e due to the ecc support for quite some time now. And this could be a good first step towards integrating.

But I do understand that you have certain requirements for your code e.g. type annotations using the closure compiler. Please let us know if there are any issues that would prevent using the libs. We're happy to accept pull requests.

[koto]

From evn@google.com on October 13, 2014 02:42:07

Thanks Tankred

We are trying to find an owner to work on this on our side, and that person will decide how to make it happen. I totally agree that using email.js would save us time and effort (and we can simply closurize the external API, or create a wrapper).

[koto]

From reverseproductions on October 14, 2014 09:53:12

Hey Eduardo, et. al. Brennan here from Mailpile. I wanted to vote in support of PGP/MIME as the default that we all strive for with these next generation PGP email efforts. In addition to decreased message integrity, the more and more I work with data from Inline PGP the more I dislike it / find it limiting from a UI / UX perspective. Using PGP/MIME offers the following benefits:

• Accurately communicating the status & integrity of messages
• Minimizing clutter and cognitive load of UI
• Thus increasing potential for user understanding

[koto]

From tankred@whiteout.io on October 14, 2014 10:41:09

If you need any help getting started, here is our pgpbuilder that orchestrates mailbuild and OpenPGP.js to build an encrypted+signed message. It could be easily be changed to use end-2-end. Example code: https://github.com/whiteout-io/pgpbuilder/blob/master/src/pgpbuilder.js#L52

[koto]

From felix.ha...@gmail.com on October 14, 2014 10:42:09

Hi guys, Felix from whiteout.io here. Since this is becoming the de-facto meeting point, my 2 cents on PGP/MIME:
Other than the trojan-horse-style PGP/INLINE thing, PGP/MIME really uses MIME in its intended way. I would love to see this in e2e! As Tankred already said, the emailjs libraries are there and we'd love to work together with you guys!

On a semi-related note:

• Gmail breaks signed/unencrypted PGP/MIME messages when you have standardized domain-wide mail signatures. Maybe someone internal at Google might advocate to fix this? ... wink ;)
• Just in case you're testing against Enigmail w/ PGP/MIME: Enigmail just completely breaks for any content-transfer-encoding other than 7-bit.

[koto]

From y...@yahoo-inc.com on October 30, 2014 15:00:20

I talked to folks at Yahoo Mail about this a few weeks ago; they seemed supportive of the PGP/MIME approach for attachments. Does anyone from whiteout.io have spare cycles to work on this for End to End?

[koto]

From tankred@whiteout.io on October 30, 2014 17:09:10

Great to hear you're in favor of PGP/MIME.

Unfortunately we don't have any spare cycles right now, but we'd be happy to answer any questions you might have.

[koto]

From y...@yahoo-inc.com on October 30, 2014 17:19:52

No worries, I started implementing it today. :)

One question: whiteout's pgpbuilder builds signed-and-encrypted messages using the method in Section 6.1 of RFC 3156, as far as I can tell. End-to-end creates a single OpenPGP message for encrypted/signed data, so it would be easier for us to use the method in 6.2. Is this going to cause compatibility problems?

(btw this is Yan from Yahoo)

[koto]

From felix.ha...@gmail.com on October 31, 2014 00:09:06

hi yan, great to see progress on this :)
if i understood this correctly, 6.1 and 6.2 are not mutually exclusive: the multipart/encrypted node is a signed OpenPGP message, as it should be. the multipart/encrypted node contains a multipart/signed node as a fallback if the mua does not support the 6.2 format. if the mua can handle the 6.2 format, it just ignores the application/pgp-signature node and prioritzes the signature included in the OpenPGP message. this is how whiteout mail and gpgtools+mail.app handle this.

[koto]

From felix.ha...@gmail.com on October 31, 2014 00:11:09

and btw: sorry for the lack of documentation on pgpbuilder. i vow to improve this ... 0:-)

[sirdarckcat]

In case you are following this - #323

[sirdarckcat]

#323 fixed this