S/MIME Re-trial

In the blog S/MIME on Trial in 2013, I outlined some challenges using S/MIME to send secure email.

I also posed the question, was I confident the issues would be solved in a 3-5 year timeframe?

Well, here we are 3 years later, let’s take a look.  

First, the challenges I’ve come across this time.

1. Outlook App on iPad does not support S/MIME. The consequence of this is that I can’t send signed email; but more of an issue, where I have started a conversation with a client via signed (not encrypted) messages using Outlook on a PC, I can’t read any replies etc. – I get to see lots of .p7m attachments.
   I asked the Microsoft support team, via the app about this – they have helpfully passed a feature request to the product team.  Not holding my breath!
2. Outlook web access does not support S/MIME, giving the same issues as the previous point.
   The lack of ubiquitous support is important.  For S/MIME to be a defence against phishing, I need people who received messages from me to know every message from me is signed.  If I send an unsigned message – this should not be treated as authentic, a potential phish.  BUT at times, I have to send unsigned messages due to these technical constraints.
3. I am starting to see a few signed messages from other people, maybe from one out of 50 contacts.
   In approximately half of these cases, by default the root certificate is not trusted, so I need to go hunting for a root of trust. Most users will not have the knowledge on how to do this.
4. Sending encrypted messages remains too challenging – getting the client certificate into the Outlook address book in the right place is too hard. (For example, just hitting reply to a signed message is not always sufficient, somehow the message picks up an old/wrong address book entry, with no certificate).
5. By default, Outlook would only allow use of SHA1 with hardware secured private keys. So I could either use insecure keys in software, or if I switch to hardware based keys, I’m stuck with an insecure hashing algorithm.  I eventually solved this, but it took a lot of digging to find the CSP configuration option causing the issue.

Of the other issues in the original post, most still occur.  The one that I’ve not had issues with this time around is my root CA certificate not being recognised.  I’ve used a free certificate from Comodo, this seems to be well placed in root trust store (the value of a free certificate is probably a matter for a different blog – Is that Web Site Secure explores some of the issues, but not in an email context).

Conclusion

So, my conclusion is somewhat similar.  S/MIME sort of works if you are technically savvy and handle it carefully, but for mortals it’s still too hard.

Confusion

BUT email supply companies are talking about the benefits of their secure email, how can this conclusion be right?

There is a fundamental difference between end to end, cross technology, secure email that S/MIME offers, and secure infrastructure solutions, providers like Office 365 and Google provide.  These are secure infrastructure stories, with secure communication paths, secure storage and secure client access, but it is not end to end user level security offered by S/MIME and proprietary messaging platforms (e.g., messaging in WhatsApp) and secure email solutions (e.g., Egress).

Maybe this is why proprietary secure messaging and email solutions are finding a place in the market.  Open standards (S/MIME) are great, but unless there is a concerted industry effort to implement them in a usable way, it won’t happen.

Based on this assessment I can’t see the World changing in the next 3 to 5 years for S/MIME.  Can you?

See Also

• Why has encrypted email not taken off?
• An email native, giving way to digital natives.