I’ll use it even if I have to become my own CA and sign my own certificates…which is what I did.
But back up.
3 years ago, I wrote about how and why to use S/MIME, and its numerous shortcomings:
The biggest inconvenience, aside from getting people to use it, is that it relies on a public key infrastructure. Those familiar with web TLS no doubt already understand this. In short, it’s a real pain to get a trusted certificate authority to issue a certificate. And they cost money. But the system worked nonetheless, until the day most major browser vendors decided to remove keygen support. This meant that certificates could no longer be manufactured and signed in the user’s browser session. But all was not lost, because some browsers hadn’t decided to fully deprecate the feature. Notably, Safari:
Then that changed too. I wondered then, why can’t I generate my own certificate and send it off on a certificate signing request the way one does with a TLS certificate? I wish I knew, but no one offers that. Probably because no one uses S/MIME anyway. So I was left to reevaluate my needs:
- While it makes me feel all super official, I doubt any recipients of my general correspondence even notice that my emails are signed.
- There’s nothing stopping me from minting my own certificates. They just won’t be trusted inherently.
- The main purpose of me using S/MIME is for encrypted information exchange with Liz.
- I can simply have Liz’s phone explicitly trust my certificate.
And so, using Apple’s keychain, I minted a general purpose master root certificate, trusted it explicitly, installed it on our phones, trusted it on the phones, then used it to sign an email certificate. The certificate, now installed on my own devices, was then inherently trusted due to the explicitly trusted root certificate that signed it. Problem solved.
Alas, I can’t feel all super official when I email other people, but oh well. Such is the fate of a mostly unknown encryption system.
–Simon