Nanoman's Company Support

These pages are intended to be referenced by customers of Nanoman's Company. Visitors are welcome to reference these pages, but our support for you may be limited.


On 2006-07-02, Nanoman's Company began using and recommending S/MIME to "digitally" (cryptographically) sign and encrypt email messages. At the time, Mozilla Thunderbird didn't have built-in support for OpenPGP, but Thunderbird fully supported S/MIME, so this was the main reason why we chose S/MIME.

Since 2020-03-17, we no longer use or recommend S/MIME, and we advise our customers to use OpenPGP instead. This page describes our rationale for making this change.

CA Problems

Most of the problems that we had with S/MIME were due to its dependence on a CA (Certificate Authority):

  • For each user, issuing and renewing certificates required having to deal with varying amounts of administrative bureaucracy from the CA.
  • When using self-signed certificates or CAs that Mozilla didn't trust, it required more administrative work for everybody involved.
  • Mozilla trusted many different CAs, including paid CAs and free (gratis) CAs, but we couldn't justify spending any amount of money on S/MIME certificates, and we didn't trust the paid CAs any more than the free CAs.

For several years, we believed that would become the kind of CA that we wanted, even though Mozilla wouldn't trust's root certificates. In 2015, we discovered that -- without public notice -- had changed their method for handling passwords entered into their website, and we knew multiple users who were unable to access their accounts because their passwords contained "special" characters (specifically "-", "/", "\", and/or "|"). We offered to volunteer some time to help fix this problem, but the responses from weren't as receptive to community participation as their website had indicated.

We expected that there would someday be a CA that fully satisfied our needs, and Let's Encrypt seemed exactly like what we wanted, but they decided not to issue S/MIME certificates. They've been great for TLS certificates, though.

On 2020-03-16, we tried to renew one of our S/MIME certificates, but for the first time ever, it didn't renew immediately. By the next day, it still hadn't renewed, and we didn't know of any other CAs that we'd rather use, so we decided that it was time to migrate ourselves and our customers away from S/MIME. On 2020-05-04, we were surprised by a notice that our renewal request from 2020-03-16 had finally been processed, but by then, we had already moved to something else.

Problems with Microsoft Outlook

A small minority of email users use a closed-source email client named Microsoft Outlook. Microsoft Outlook is notorious for being horribly insecure, extremely unreliable, and having severe problems with data corruption. We used to support Microsoft Outlook, but we ended our support for it in the summer of 2005 after multiple customers of ours who weren't using their backup systems experienced catastrophic data losses that were caused by some of Microsoft Outlook's inherent problems.

After we started using and recommending S/MIME in 2006, we discovered another problem with Microsoft Outlook: it treats non-encrypted digitally signed email messages as encrypted. We received several problem reports from Microsoft Outlook users who said that trying to open or reply to non-encrypted S/MIME-signed messages caused them to be shown cryptography-related errors. We didn't have access to any of these computers, and we don't have a record of the errors that they saw, but we were confident that this was yet another bug in this standards-flouting email client.

Unfortunately, we and some of our customers sometimes need to send important email messages to people who use Microsoft Outlook. We want to be able to protect the integrity of our messages, but Microsoft Outlook's problems with S/MIME made this very difficult.

In 2012, we sent a non-encrypted digitally signed email message to a Canadian federal government official, and this official telephoned us to say that they couldn't open our message because Microsoft Outlook told them that our message was encrypted. We assured this official that our message definitely wasn't encrypted, and that we couldn't have used S/MIME to encrypt a message for them because we didn't have their public key. We were also horrified that our federal government was using Microsoft Outlook for some of their critically important correspondence.

We contacted the IT department of the federal government official who couldn't open our letter, but despite our best efforts to educate them, this taxpayer-funded IT department couldn't understand the difference between digital signatures and encryption. We asked them to try using a plain text editor to open our message, and they had no problem reading it because our message didn't contain any ciphertext, but they insisted that our message was encrypted because Microsoft Outlook told them that it was.

At our own expense, we provided the federal government's IT staff with detailed information that they could have used to fix the S/MIME problems that they were having with Microsoft Outlook. We showed them how they could fix this problem immediately, on their own, and at no cost to taxpayers. Four months later, instead of fixing this problem, they spent an absurd amount of taxpayer money on an add-on for Microsoft Outlook that worked around this problem.

Switch to OpenPGP

On 2020-03-17, we switched from S/MIME to OpenPGP for digitally signing and encrypting email messages. Mozilla had announced on 2019-10-08 that Thunderbird version 78.0 would be released in 2020 with built-in support for OpenPGP, so our primary motivation for using S/MIME instead of OpenPGP was gone.

The problems that we encountered with S/MIME had nothing to do with S/MIME itself. When users trusted whatever CAs their correspondents were using for S/MIME certificates, and when Microsoft Outlook wasn't involved, it worked perfectly for us and our customers.

A feature of S/MIME is that the S/MIME signature file attached to each message includes both the message's signature and the sender's public key, thereby simplifying key exchange for correspondents who trust each other's CAs. This feature means that S/MIME signature files are almost always larger than OpenPGP's signature files, but we've never encountered a situation where the size of an S/MIME signature file was a problem.

We don't consider OpenPGP to be a perfect solution, but when we needed an alternative to S/MIME, we felt that it was the best available. If we someday find an open standard that we consider better than OpenPGP, then maybe we'll switch.