Closed Bug 894817 Opened 7 years ago Closed 2 years ago

[email][meta] S/MIME and PGP/GPG encryption and signature support


(Firefox OS Graveyard :: Gaia::E-Mail, enhancement)

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: klaustester, Assigned: marta)


(Depends on 1 open bug)


(Keywords: feature, foxfood, Whiteboard: [apps watch list])

I should be able to send encrypted e-mail to other people and to read encrypted e-mails other people send to me on my mobile phone.

Currently I need to use a desktop e-mail client because Firefox OS does not have S/MIME support. 

(iOS already supports S/MIME, Android has K-9 which also supports S/MIME and Microsoft has announced that S/MIME support will be in the next minor update to WP8.)
Ever confirmed: true
Summary: S/MIME support → [email] S/MIME and PGP/GPG encryption and signature support
Duplicate of this bug: 903320
GPG and S/MIME are very different and they should be tracked by separate bugs.

Also, it is unclear that the W3C Crypto API is the best choice for either of these tasks. The way keys are stored in the W3C Crypto API makes them much like cookies (transient things). S/MIME and GPG need more permanent storage, AFAICT.

It might be better to just create S/MIME and/or GPG-specific APIs for encoding/decoding messages with keys that are managed by the system.
I was mainly thinking of this bug as a meta bug to consolidate feature requests for support for encryption and signatures until some actual work happens.  (Because this app is basically driven by product and UX concerns, and our huge backlog of fundamental e-mail features, we're probably looking at v1.4 at the earliest of when we could do something with crypto.)

I agree the PGP web-of-trust and S/MIME CA models are very different.  (Although for MIME part purposes our handling will be very similar.)

I added the W3C crypto dependency because my impression was that the W3C crypto API would provide us with native crypto primitives that would protect us against timing channel attacks against the atomic crypto operations.  The general theory I've heard about JS-implemented crypto is that it's nuts because you have no idea how JS interpreter optimizations are going to affect things, so you can't really avoid timing-channel attacks.  I'm sure that's an over-simplification and some algorithms can have risk avoided by using blinding or something.  (And it seems very possible that higher level operations consisting of chained lower level operations mediated by JS could still leak some information, but that's way less horrible than potentially letting entropy about private keys be inferred, etc.  Especially since the e-mail app is harder for an attacker to control, except for the predictability of us attempting to decrypt e-mails and the obvious CPU spikes when we do that.

Do you think the the W3C crypto API will help us out there, or should we try and start getting WebAPIs created for PGP/GPG and S/MIME?
Summary: [email] S/MIME and PGP/GPG encryption and signature support → [email][meta] S/MIME and PGP/GPG encryption and signature support
Andrew, I agree that we should try to avoid implementing the crypto algorithms in JS for the reasons you described. I think that we should evaluate which approach (W3C Crypto API vs. more specific APIs vs. something else) makes the most sense when we have a better idea of how this feature fits in the product roadmaps and if/how other features end up driving the development of the W3C Crypto API in Gecko. Part of that evaluation would be determining how much effort it would be to implement the GPG and/or S/MIME logic--not the crypto primitives, but everything else--in JS. Are there existing S/MIME/CMS/GPG JavaScript libraries that we could use, or would we be doing all the decoding ourselves?
I'm interested in this because I'm working on MIME parsing in JS for Thunderbird, and S/MIME and PGP support are things I care about. I also definitely want Gaia and Thunderbird to be using the same code stuff here [for backend parsing, at least].

I would be surprised if there was a full S/MIME implementation in JS, since you have to deal with the entire certificate stack. I don't think there's even a bare CMS implementation, since ASN.1 is a royal pain in the rear--JSMime was basically planning on plugging its ears and using nsICMSMessage for this stuff. I've had occasion to briefly peruse the PGP spec a day or two ago, and implementing it (assuming you have access to a lower-level crypto API) does not appear to be difficult. It looks much easier to parse than CMS at least.

My personal opinion is that S/MIME is going to need higher-level support in the crypto APIs for certificate handling, while PGP can probably get by with keystore and low-level crypto support.
(In reply to Joshua Cranmer [:jcranmer] from comment #5)
> I've had occasion to briefly peruse the PGP spec a day or two ago, and
> implementing it (assuming you have access to a lower-level crypto API)
> does not appear to be difficult.

Assignee: nobody → marta
Whiteboard: [apps watch list]
I'm interested in this feature. Encryption is becoming the only way to keep private conversations in this completely surveilled world. Is this being planned for 2.0?
No, this is not planned for 2.0. Do you want to contribute?
For the time being, you may want to take a look at They have a WebApp email client with OpenPGP (100% HTML, CSS, JS/Browser) which should be able to run on Firefox OS – though as of now, I think the client is not released for Firefox OS. You may want to ping them. (Nevertheless, the built-in app should definitely support PGP sooner than later.)
Speaking of, they open-sourced email.js ( which is part of their stack – alongside openpgp.js which the CTO (among others) developed prior to founding openpgp-js is not a (emscripten-)compiled version of the library, but a new implementation, and in Q1 they had a security audit which did not uncover major mistakes (for specifics, you may want to contact @tankredhase – their CTO – directly). If this is not yet the case, I strongly suspect that they will target the WebCrypto API rather soon, falling back to their JS crypto libraries when WebCrypto is not available. 

According to Tankred, Mozilla already decided to use email.js in their Mail app, though I haven't seen any mention of it here yet. Mixing this with openpgp.js shouldn't pose too much of an issue since this has been done already at
Bug 885110 tracks moving to email.js for the low-level protocol libraries.  I am generally in contact with Tankred and Andris Reinman of

The current plan is to not land anything that uses OpenPGP.js because we want to keep Gaia Apache 2 licensed and OpenPGP.js is LGPL 2.1.  This specific call was made by :gal when I asked on the dev-gaia list.  The thread is here: 

Note that as part of the privacy phone project there has been interest in prototyping PGP support for the email app using OpenPGP.js, which is fine, but just can't land into mozilla-b2g/gaia.  From previous survey work it seemed like since we would ideally be building on top of WebCrypto for the crypto operations there actually isn't that much code to be written for the PGP "protocol" level.
Thanks for the writeup! I agree with the licensing issues. Though did anyone try to get a different license from the developers of OpenPGP.js (or ask them to switch)?
The license was discussed a bit back in 2012. Might worth it to revamp this discussion on the mailing list again.
For those looking for the openpgp.js license discussions, I think these are they:

- In the context of the Apple App store:

- Sub-thread about our license desire as raised by Tankred that didn't go anywhere in the context of a larger thread about the gaia email app:
I'd really like to see PGP support in Firefox OS
Duplicate of this bug: 1177526
Keywords: foxfood
Firefox OS is not being worked on
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.