thunderbird-android
thunderbird-android copied to clipboard
thunderbird
S/MIME support
There is an existing discussion on an old tracker ... https://code.google.com/p/k9mail/issues/detail?id=2538
A lot of work seems to be done on PGP support in the https://github.com/k9mail/k-9/milestones/PGP/MIME milestone. Hope this issue helps to track S/MIME support. I would like to easily verify both PGP and S/MIME signatures.
A few related issues:
- #916
- #571
There was a mobile application development project at our university and one project tried to implement this: https://github.com/FAU-Inf2/SMile
For me this looks like a big chaos but maybe you can use some parts... ;)
We can take some lessons from it, but:
- The project layout is not how we'll want it. They have a separate git repository for the SMIME app which is referenced by SMile as a project dependency. What we want is to do similarly to the OpenPGP system and to create a SMIME library inside the same GitHub repository which dispatches and receives Intents from an SMIME app. Otherwise it gets quite difficult to build the app.
- They've changed a lot of files which are not related to SMIME. For example they've added the ability to logout from an IMAP account by the look of it, added some form of reminder functionality, added lots of text changes and so on. This makes it substantially more complex to merge in just the SMIME changes. Even cherry-picking commits will be a pain because the commits aren't obvious what they do.
Similarly to the first OpenPGP implementation, we can probably learn lessons but direct code re-use is going to be problematic.
I've begun a branch in my local repository which assumes it will receive similar intents to that which OpenKeychain provides: https://github.com/philipwhiuk/k-9/commits/smime I will keep re-basing this on-top of master maintaining parity with any new relevant features that the PGP/MIME development adds.
I need to write a SMIME certificates storage app now to implement the other side so I can test decrypting a SMIME message (and test composition). It's possible I can fork https://github.com/FAU-Inf2/SMileCE for that. Otherwise it will take a while...
Right now the OpenKeychain project kind of owns the crypto provider interface and drives the development. Which is fine, because nobody else showed interest in integrating with K-9 Mail.
But really I want to have a crypto provider interface that is generic enough to be able to support both PGP/MIME and S/MIME. That is also part of the reason why I suggested using the openintents namespace back when this all started. My hope was this interface will be implemented by more than one app, and one day supports more than one crypto system. The use of "openpgp" all over the place is a bit unfortunate. But I suspect the API needs some tweaking to be able to support S/MIME anyway. So transitioning to a more generic name shouldn't be a huge problem either.
/cc @Valodim @dschuermann
I can recommend the library https://en.wikipedia.org/wiki/Bouncy_Castle_(cryptography) for this. At work we use this API for Java and S/Mime and it was simple to integrate. It also supports PGP, but I never tried the PGP part.
Hello everyone! I'm curious, what's the current status of the S/MIME integration? Are there still plans to ship this feature, do you need help with something specific, or is it just not going to happen?
I need an Android email app with S/MIME support. I see this issue is still open, but that a milestone for it was removed last month. Is there a version with S/MIME under development at this point? If so, can I test it for you? I am running a Motorola Moto E with Android 10 on it that would be my test environment.
Also interested in having an open source Android mail client that supports S/MIME. It seems this protocol is well integrated in most desktop clients, unlike PGP, which makes it the preferred choice for companies. As I need a mobile client mail for my pro email (having a S/MIME certificate), I would like to know if I can wait for a solution using my favorite K-9 client, or should I switch to another open source alternative ?
In case S/MIME will not be supported in the short terme in K-9, would you recommend an open source alternative ? (FairMail looks like a very good option)
Also interested in having an open source Android mail client that supports S/MIME. It seems this protocol is well integrated in most desktop clients, unlike PGP, which makes it the preferred choice for companies. As I need a mobile client mail for my pro email (having a S/MIME certificate), I would like to know if I can wait for a solution using my favorite K-9 client, or should I switch to another open source alternative ?
In case S/MIME will not be supported in the short terme in K-9, would you recommend an open source alternative ? (FairMail looks like a very good option)
I also had to switch because I needed S/MIME support, and FairMail works fine, though I'd still prefer K-9 very much if only for S/MIME..
I researched this feature in some K-9 forks like SMile and K-2. But they didn't actually implement this feature completely. For example, in Smile sign process, they didn't pass the email body to SMileCE service, and it returns error with null pointer exception. In the SMileCE project, MimeBodyPart object is from javax mail library, which is different from our MimeBodyPart in K-9
Thanks @rezazarchi for the info. I did not know these forks, but anyway, from what I read, S/MIME is not fully implemented so it won't save me :-)
I would also really like to see this feature integrated in my favourite mail client.
Is there a way to direct my donation to support this particular feature request?
I'm working on S/mime in the K-9 project. but I have some challenges with converting K9 MimeMessage to Javax MimeMessage objects and converting Javax to K9. The bouncy castle needs that to sign messages. I created a signed message successfully, but for reading and validating signator, I had challenge with converting saved local message to Javax mail. I don't know how to convert K9 LocalMessage to Javax MimeMessage properly. Could you please help me with that? @cketti
Part of my codes for converting is here. I will push my whole code when It is completed. https://gist.github.com/rezazarchi/8923ef38433677b77943195624cb6f71
@rezazarchi: I assume JavaMail (or I guess Jakarta Mail now) can read and write raw messages. Probably easiest to go that route.
If you want to get this merged into K-9 Mail, please find another way. I don't want to include another (rather large) mail library like Jakarta Mail. I'm sure BouncyCastle has more low level functionality to encrypt/decrypt and sign/verify S/MIME data.
Use Body.writeTo(OutputStream). See e.g. MessageCryptoHelper.getDataSourceForEncryptedOrInlineData().
Fellow developers, I've got a few questions regarding S/MIME support:
- Where does development for it take place?
- How's progress?
- Is it possible to support the development of S/MIME with targeted donations?
- Will it land on @thundernest's Android Roadmap?
We develop features in the open and usually reference the issue number of a feature request in pull requests. If you look closely, you can see this is not a feature we're currently working on.
We don't do targeted donations and we currently don't offer the option to pay for feature work.
There's quite a few feature requests that are more popular than S/MIME support. So I think it's unlikely that we'll start work on this feature anytime soon.
The comments in this thread about the code design are eight years old and I've wanted to check, if they are still valid:
- Is it still intended to implement S/MIME in such a way, that it uses a similar crypto interface to the PGP implementation (including an external application for key management)? Are there any arguments against directly integrating the complete logic (key import, key management, viewing keys, encryption and signing) into thunderbird-android, to have a similar experience to the desktop app?
