#291 accepted
leeb

<Feature Request> S/MIME signing/encryption support

Reported by leeb | October 10th, 2012 @ 05:52 PM

Good day Benny,

MailMate is looking great overall, but unless I'm missing something MailMate, like many of the Mail.app alternatives so far, doesn't appear to have support for signing and encrypting/decrypting emails. While it's in less use overall then would be ideal, for me it's an utterly critical feature and I honestly think it's should be of significant importance to users in general. In a world with ever more network scanning, spoofing, spam and so forth certs provide a free/cheap and standard way of mitigating a range of attacks and attesting to authenticity. Particularly for a "power user" client like MailMate I hope you'll strongly consider it.

At a minimum, it'd be fine to just ape Mail.app's implementation, where if the proper certificate/keys exists in the Keychain signing and encryption options will get automatically added. That'd get the basic job done at least and make MailMate a contender there. If you wanted to go beyond Mail though there is plenty of scope for improvements, such as:
- Supporting dual certs (separate signing/encryption per best practices) - GUI for management and display within MailMate (probably as part of account preferences) - Support for hardware tokens via PKCS#11 like Thunderbird and other Mozilla products. Multifactor support is fantastic for easy and security. However, this would be certainly be more trouble since Apple has to my knowledge made absolutely no signs of progress on their claimed next generation crypto framework and OpenSC is still pretty immature. Maybe for the "someday" or "keep an eye on it" category. - Support for OpenPGP/GPG as well.

Thanks for your consideration of this and all your hard work so far!

Comments and changes to this ticket

  • benny

    benny October 10th, 2012 @ 06:02 PM

    • State changed from “new” to “accepted”

    You'll be happy to know that the latest test versions of MailMate include basic support for both S/MIME and OpenPGP. It is not quite ready for intensive testing (primitive GUI), but it is ready for basic tests like “does it correctly verify/decrypt/sign/encrypt messages”. S/MIME uses Apples API (and keychain). OpenPGP is currently hardcoded to use the command line program installed by GPGTools.

    What is dual certs? Do you mean first signing a message and then encrypting it? (Instead of doing both in one go.) That is currently not supported.

    I don't really know anything about hardware tokens, so that is probably in the bluesky feature category.

    If you send me an email then I'll add you to my list of people who would like to use/test S/MIME support.

  • leeb

    leeb October 10th, 2012 @ 06:42 PM

    First, great to hear this is being worked on already! I'd be happy to give it a whirl, do I just use the mm-info address?

    What is dual certs? Do you mean first signing a message and then encrypting it? (Instead of doing both in one go.) That is currently not supported.

    No, dual certs is where separate certificates/keys are used signing vs encryption operations. It's considered general good practice because it means that the signing key can be kept 100% secure and private for authenticity purposes, while the encryption key can be handled separately. It might get put into escrow for example, or on a mail filtering server. That means that only the original user can send new emails and show up as being authentic, but if there's an emergency (or if policy requires it) any already sent messages can be decrypted via backup.

    That's not a critical initial feature like basic support though, and since I've primarily used the smime functionality of openssl I don't know how much functionality Apple's API exposes. It should be pretty straight forward to test out, but you can probably safely toss it into the "later" pile anyway since Mail itself doesn't offer it natively.

    I don't really know anything about hardware tokens, so that is probably in the bluesky feature category.

    I don't blame you for this, it's mainly something to have on your radar I guess. Ideally we'd be back in the pre-10.7 days but better, with Apple themselves supplying a good core supported framework as they once did. Then a token could simply show up as one of the system keychains for any program to use with minimal additional lifting on your part.

    Were the software to be more mature adding support yourself via existing commandline utilities, just as you are with GPGTools, would in principal be pretty straight forward. You can take a look at what's offered by say the pkcs11-tool, pkcs15-tool, and pkcs15-crypt if you're curious. Combined with smime and it'd mainly be some GUI glue on stuff that's already there.

    Unfortunately, that "Were" is the big catch. Right now the install process is pretty user unfriendly and significant bugs have still appeared from time to time. Tokens themselves (like the ePass 2003) are cheap enough (~$20), but it's still hard to really recommend anything right now. Maybe in 6 months or with 10.9 it'll be different, so in the end just something to keep in mind.

    Anyway, thanks again for your prompt reply here.

  • benny

    benny October 10th, 2012 @ 06:51 PM

    Thanks for the details.

    Dual certs: I get it now and I can see why it makes sense to do it like that. You are welcome to re-request that feature when the S/MIME and OpenPGP support is more mature. I don't think Apples API is going to be a problem.

    Hardware tokens: Sounds like you should re-request that feature when the other parts of the system has matured.

    And yes, just write to mm-info (or use the “Help ▸ Send Feedback...” menu item in MailMate). It is a one-man-shop :-)

  • leeb

    leeb October 15th, 2012 @ 02:41 PM

    I received the signed email you sent. Unless I'm mistaken the feature isn't in the current beta so I can't test it there, but I can report that Mail.app (under both OS X and iOS) cannot read the certificate. It does report it as being "Signed" but shows "Unable to verify message signature: There was a problem reading the digital signature for this message."

    It's not a matter of it being untrusted, I simply can't see the cert at all unlike normal.

  • benny

    benny October 15th, 2012 @ 05:28 PM

    You are right. The message has an empty signature MIME part. Not sure why it happened, but I'll keep an eye out for it when testing.

    You need the latest test version for a bit of S/MIME support. You can fetch it by holding down ⌥ when clicking “Check Now”. The current test version is stable, but this is not always true :-) I'll let you know when a new test version is available. It'll include some GUI settings for S/MIME and OpenPGP and therefore be a bit more ready for actual testing.

  • leeb

    leeb October 16th, 2012 @ 07:47 PM

    Good to hear, thank you. I can confirm that the latest test message you sent now does properly display the certificate in Mail. It does appear to be successfully decrypting message as well. Comments so far:
    - For encrypted messages, it always shows the "Successfully decrypted the message." box, but sometimes it also shows the "Successfully verified the signature of the message text" box and sometimes it doesn't. - As far as GUI, I know that's a total work in progress. You should probably just ape Mail here, or at least do something similar (a closed lock and color background next to the From perhaps). The boxes are wasteful. It is important to though to both verify and decrypt, decryption by itself doesn't mean anything. The final GUI (again like mail) should also make it easy to display the certificate itself. - Might want to note in the Release instructions that GPGTools is required (apparently?) even if only using S/MIME. I'd also note that users who still want to use Mail should probably install the latest nightly for GPGMail at this point, which supports swapping back and forth. The latest nightly is also needed for 10.7.5, and right now it doesn't work well or at all in 10.8.

    Thanks again for working on this! It's another important checkbox in the bag, and might even be a real area of differentiation someday.

  • benny

    benny October 16th, 2012 @ 09:16 PM

    There is some bug in the text shown by MailMate. It does not always reflect what was actually done.

    GPGTools should not be required if only S/MIME is used. I'll see if I can remember to test it before the next test version.

    What do you mean by “supports swapping back and forth”? I don't think advice for Apple Mail belongs in the release notes of MailMate (it might even confuse some users). And I think MailMate works with “any” version of GPGTools. The path to gpg2 is also going to be configurable at some point. In that case GPGTools is not strictly needed (although recommended).

  • leeb

    leeb October 16th, 2012 @ 09:35 PM

    GPGTools should not be required if only S/MIME is used.

    Huh, wouldn't seem to work for me before that. Merely enabling security did nothing. I'd been meaning to play around more with GPG anyway, I'd been primarily holding off to try to get my token squared away first (and it seems like there's never enough time in the day either). If that was just my install though then all the better, in that case I'd merely suggesting clarifying the notes.

    What do you mean by “supports swapping back and forth”?

    I mean that both S/MIME and OpenPGP can be used, rather then the installation of OpenPGP breaking S/MIME support.

    I don't think advice for Apple Mail belongs in the release notes of MailMate (it might even confuse some users).

    I think it's just general good practice when suggesting installation of 3rd party software to note any significant gotchas that might actually break existing workflows. It seems likely that many of the ones who care most about encryption in MailMate (and would be engaging in early testing) are probably already using encryption, and thus Mail in parallel to MailMate. Just grabbing the recent installer at https://nightly.gpgtools.org/ fixes that. Not a major issue and something beta testers could probably figure out on their after a bit of Googling of course.

  • benny

    benny October 16th, 2012 @ 09:41 PM

    Ah, I get your point now. Yes, it would be a good idea to warn that installing GPGMail can break S/MIME support in Apple Mail. It can of course also be solved by not installing the GPGMail part of GPGTools.

  • leeb

    leeb October 16th, 2012 @ 09:42 PM

    Curses, I messed up formatting again. My apologies, I should have read the core Markdown guide rather then Lighthouse's version. I missed:

    Markdown allows you to be lazy and only put the > before the first line of a hard-wrapped paragraph:

    Which in practice actually sucks :(. Why would you do that Gruber? I will preview more carefully from now on.

  • benny

    benny October 16th, 2012 @ 09:46 PM

    As you can see I fixed the formatting for you. The Markdown style used in MailMate is actually different (for other reasons) and does not behave like that. (Ideally, I should precisely define an email-appropriate variant of Markdown and name it something else.)

  • benny

    benny August 18th, 2017 @ 08:19 AM

    • State changed from “accepted” to “fixcommitted”

    This is a very old ticket, but for the record, MailMate now supports separate signing/encryption certificates. It's currently only in the test release (hold down ⌥ when clicking “Check Now” in the Software Update preferences pane). It'll be in the public release when the state of this ticket switches to fixreleased.

  • benny

    benny September 22nd, 2017 @ 12:54 PM

    • State changed from “fixcommitted” to “fixreleased”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket

Pages