S/MIME on Trial

For the last 3 months I have, by default, digitally signed my email. Well that was the plan…

I first tried to digitally sign all my email in the 1990 as part of the Password (’93) and the EMA Challenge projects (’97). I had to use clear-text S/MIME, otherwise very few email clients in common use would be able to read the message (so they show the user the raw mime – but at least they could read the text). As would be expected the results were not that encouraging, and showed that wild the core technology existed, the industry had a long way to go in terms of the roll out of core infrastructure.

While working at Intercede around 2003, I once again had a go at sending out all emails digitally signed, this time using a smart card as my signing device (Intercede was in the smart card market after all). The experience was again mixed. While the email clients seemed to cope with the experience, the email infrastructure was far less robust; far too many email gateways made subtle changes to the email or attachments, causing the digital signature check to fail. Obtaining a public certificate was also not easy – requiring me to use the expertise available at Intercede about certificate management to achieve it. Way beyond the average user.

At Siemens Insight around 2006 I once again tried, but gave up quite quickly. While an advanced organisation in terms of using smart cards, my main issue is I had two. One Insight issued to log onto my PC, and the other Siemens issued with a public certificate. If anyone has ever tried to use a PC with two smart cards, from different manufacturers, with difference card drivers, you will know why I quickly abandoned the experiment. The few messages I did manage to send, suffered email gateway issues, invalidating signatures.

So when earlier this year I got an unsolicited email from Symantec to try their new PKI service, I though why not…

The 2013 Trial

Obtaining the certificate was easy, a little bit of technical understanding needed, but not too much – something I think most motivated people could achieve.
Integrating to Outlook was relatively easy (using the windows certificate store, not a smart card), as was configuring digital signing to be the default (finding the TrustCentre in Outlook took some hunting down – why so well hidden?).
Then the fun started:

  • Next time I tried to send an email, Outlook helpfully asked if I wanted to grant permission to access the signing key.
    This I granted.
    However, to my surprise I was not asked again on subsequent emails. Seems like once granted, you give Outlook full permission to use it whenever it so chooses, until to log out. (I suspect this a crypto driver choice, so if I used a smart card this issue would be overcome).
    Not ideal.
  • A few people at Nexor instantly had difficulties.
    Their clients did not recognise the root certificate, showed the email, but also flagged the email as untrustworthy.
    Easily fixed with a few mouse clicks – but required some limited PKI knowledge.
    Curiously this did not affect everyone.
  • A user reading the email on an Android phone had difficulty, their phone refused to show the message.
    A root certificate issue again and easily fixed with a few screen presses, but required quite a detailed knowledge of what was going on.
  • Some users reported my emails arrived with a strange icon (the signed email icon) – and wondered what it meant. (I took this to be good, as my emails stood out in their email box, so hopefully stood a higher chance of being read / actioned!)
  • Users of Outlook Web mail, could not read the message at all. OWA helpfully said “There is an S/MIME” attachment, with no offer of help about how to read it.
    Bizarrely, googling this issue revealed that emailing the message to yourself sometimes fixed it.
    For some odd reason, this does work – sometimes.
  • Users reading the email on iPad/iPhone were blissfully unaware the messages were signed – by default Apple choose to hide all this.
  • One automated response email I got, choose to use my certificate to encrypt its response to me.
    That threw me for a bit, as I initially tried to read the email on my phone – but did not have the private key on my phone.
  • The gateway issues seen in previous attempts seem to have gone away.
    Some gateways validate the signature at the boundary, stripping it and adding text to say the message was signed.
  • Finally, I was limited to sending email for my outlook client. As previously observed, web mail does not support S/MIME.
    I do also send email from an iPad – looks like I could export my private key from Microsoft and import into iOS, but did not give that a try (the security implications of doing so could be a blog subject in its own right).

The Future

So 20 years after I first tried to send a secure email, have we made progress?

  • YES. The email gateway infrastructure issues seem to have largely gone.
  • YES. Usability has got a lot easier – but perhaps a bit too easy.
  • NO. Client issues are largely the same.
  • NO. I now use multiple email clients to access email on the move, and having the credential tried to one device is a real limitation.

If I try again in 3-5 years, am I confident the issue will be resolved?


The issues I have documented are supply side issues, they are all solvable if the respective vendors were motivated to do so. Why have they not been solved in 20 years? Lack of wide-spread demand.  In general, we appear happy to live with the situation.  Sure there are closed user groups where point solutions and proprietary solutions can be made to work, but there does not seem to be the drive needed to make a general solution.

What do you think?  Will ever get to the stage when we can communicate using secure email, in a true open environment?   Please let me know below.

Update November 2016:  See S/MIME Re-trial.


4 thoughts on “S/MIME on Trial

  1. Colin –

    No doubt you’re well aware that iOS has supported S/MIME signing and encryption since iOS 5. If you use the iPhone Configuration Utility for Mac (not the Windows version), I’ve found it pretty intuitive to load my certificates and the public certificates of business partners, and configure my e-mail accounts to include S/MIME support, all in a single configuration package. Curiously, iOS 7-7.0.3 has broken attachment handling on S/MIME encrypted messages. I wrote about that at… http://snnyc.com/2013/09/ios7-smime-fail/.



    1. Thank you for the comment.
      My concern about iPad/iPhone interface, is the S/MIME is not turned on by default; as a consequence you may not know you have received a S/MIME message.


    2. Once you’ve enabled S/MIME on an iOS device, you’ll see a checkmark on any new incoming signed messages and a lock icon on any new encrypted message to the right of the sender’s name or e-mail address.

      When creating a new outbound message from the iOS device, it’ll show you a lock icon in blue or an unlock icon in red next to each recipient, and indicate at the top whether the message will be encrypted or not.

      iOS’s S/MIME handling is one of the more user-friendly implimentations I’ve seen. While it would take a tech-saavy user or administrator to set up the iPhone / iPad initially, even non-technical people can tell whether the message they just received or are about to send is encrypted or not.


    3. Hi Robert, I agree once set up the IOS S/MIME handling is good. My nagging doubt, is I suspect 96% of iPhones have not switched the support on, so the good work is all hidden.


Comments are closed.