We talked recently about Apple mostly fixing one bug related to S/MIME encrypted email messages with their release of iOS 7.1. Now it appears that they may have another.
Normally when using S/MIME email signing and encryption, the Mail app will indicate a blue lock icon next to any recipient with whom you’ve previously received a signed message and installed their public certificate. Any recipients for whom you don’t have a certificate installed, and are therefore unable to exchange encrypted mail, are shown in red with an unlock icon next to their name. It’s perhaps the most visually intuitive S/MIME implementation out there.
If you’ve previously installed a certificate for every recipient on a given message, Mail will indicate that the message is Encrypted at the very top, again accompanied by a blue lock icon. If there are any recipients on a message for whom you don’t have a certificate, the message will normally drop back to Not Encrypted at the very top and show the red unlock icon. You would never want to send out a single encrypted message to a group of people such that only certain recipients had the means to decrypt and read it.
At the Connecticut-based healthcare practice where I work, we collaborate with outside technical people all the time. In day-to-day e-mail exchanges, I’ll frequently receive e-mail messages from third parties where the sender chooses to include or carbon copy our CIO or one of my IT colleagues. More to the point, someone who doesn’t use S/MIME signing and encryption will send me a message where they carbon copy someone who does use S/MIME. Often the topic will merit a response, where I begin by hitting Reply All.
The iOS 7.1 Mail screen captured at the top of this article should not be possible. You’re looking at a Reply All where I have no S/MIME certificate for the To party, but I do for the Cc’d party. Yet the overall message status at the very top still indicates Encrypted. If I began a new e-mail message to the very same recipients, the message status would be Not Encrypted. This inadvertent Encrypted status on Reply Alls to a mixed group of recipients isn’t just a visual problem. If sent, the reply message actually goes out encrypted as promised, such that only the name in blue will be able to read it. Red recipients will get an smime.p7m attachment that they can’t do anything with.
Curiously, I’m only able to replicate this problem situation when doing a Reply All from my Microsoft Exchange e-mail account. I’m unable to duplicate it when replying from Google-hosted IMAP accounts. I should mention that while I’ve seen it happen from multiple devices running iOS 7.1, the device from which I recreated this scenario is an iPhone 5s that was completely wiped and reloaded after having been upgraded to iOS 7.1.
The work-around, for now, seems to involve avoiding the Reply All button. If you instead limit yourself to choosing Reply, and then manually add the other recipients back, the message status seems to behave appropriately. It’s an unfortunate extra bit of work, with the potential to stand in the way of wider S/MIME use in iOS-centric enterprises.
This information has been submitted to Apple on case number 593916475.