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 it fully supported S/MIME, so this was the main reason why we went with S/MIME.

CA Problems

Our biggest problem with deploying and maintaining S/MIME was getting certificates issued by a CA (Certificate Authority). We and very few of our customers could justify spending any amount of money for these certificates that should be free (gratis), and we weren't completely satisfied with any of the free CAs.

For several years, we believed that would be 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, thereby locking us out of some accounts due to passwords containing "special" characters ("-", "/", "\", and/or "|"). We offered to volunteer some time to help fix these passwords, but their responses 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 HTTPS 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, so we decided that it was time for another change. On 2020-05-04, we were surprised by a notice that it had finally renewed, but by then, we had already moved to something else.

Problems with a Standards-Flouting Email Client

A small minority of email users are using a closed-source email client that's notorious for being horribly insecure, extremely unreliable, and having severe problems with data corruption. Unfortunately, we and some of our customers sometimes need to send email messages to people who are using this really bad email client.

One of the many things that this problematic email client does wrong is treat non-encrypted digitally signed email messages as encrypted, even though they're not. When somebody using this really bad email client would try to open or reply to a non-encrypted S/MIME-signed message, they'd often be shown cryptography-related error messages, and they typically wouldn't know how to respond.

In 2012, we were horrified to discover that Canada's federal government was using this terrible email client for critically important correspondence. We contacted the IT department of the government official who had encountered this problem in their dealings with us, but despite our best efforts to educate them, this taxpayer-funded IT department couldn't understand the difference between digital signatures and digital encryption. We provided this IT department with detailed instructions that would have fixed this problem for free (gratis), but they showed no desire to learn anything. Four months later, they spent a small fortune of taxpayer money on a significantly inferior solution.

Switch to OpenPGP

On 2020-03-17, we switched from S/MIME to OpenPGP for cryptographically 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 CA their correspondents were using for S/MIME certificates, and when a certain standards-flouting email client wasn't involved, it worked perfectly for us and our customers.

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

We don't consider OpenPGP to be a perfect solution, but we feel that it's the best option at this time. We plan to switch to something else when we find an open standard that we like better, and we plan to announce this on our News page.