Jan Wildeboer’s thread on setting up a cooperative CA inspired me to finally write down (and then forget about them again for over a week) my thoughts on a related topic: Email encryption.
With PGP and S/MIME, we already have two mature solutions for sending encrypted emails that have been around for decades. And while there are a few issues here and there, we can essentially consider the problem resolved. If it wasn’t for the UX…
PGP’s method of establishing trust via TOFU (Trust On First Use) or a web of trust has proven too complicated for many casual users. And S/MIME’s reliance on CAs has made it prohibitively expensive outside of a business context. In addition, neither solution offers a smooth way to manage the required certificates. It seems that visitors to crypto parties usually don’t mind managing their certificates, and corporations, which decide which software to buy without consulting their employees, don’t care about usability either.
This led to a situation where most people don’t use email encryption at all, and even the few corporations that do, use mail gateways to keep the overhead away from their users. With the rise of webmailers, most didn’t even bother to implement the feature, or created a barely functioning workaround that isn’t used much.
The ingredients for disruption
Given the current situation, it seems hopeless to think that this could change. But 10 years ago, the state of HTTP encryption was also dire. CAs charged an arm and a leg for certificates, which had to be manually replaced every one or two years. This made offering encryption, especially for private websites that didn’t earn any money, a pain in the ass.
And then Let’s Encrypt came along with free certificates and automation, changing the situation basically overnight. Today, offering HTTPS has become the norm — nobody has to think twice about it.
What would be the required changes to email encryption that could be similarly disruptive?
Free certificates
The first change would be the same the same as for HTTPS: Free certificates. There are a few CAs that offer free S/MIME certificates, but usually with a caveat, such as server-side key generation.
Users need access to free certificates. There is still a market for extended validation, but users do not want to pay dozens of euros for a certificate that only validates their email address.
Automation
But free certificates are not enough. The deployment of the certificates must be seamless so that users don’t have to think about it. This could be achieved using ACME, the same protocol that Let’s Encrypt uses to issue TLS certificates, with an appropriate challenge. The existing challenge types are not suitable for issuing S/MIME certificates, but the protocol could be extended with an email-based challenge for this purpose.
This is more challenging to implement than HTTPS because users will not set up Certbot themselves. The email clients must do this transparently. Imagine an “acquire S/MIME certificate automatically” checkbox during the initial setup, with everything else happening in the background.
Certificate management
While desktop clients and mobile apps can manage certificates themselves, web clients require a different solution. Neither server-side storage of the keys nor browser plugins can fulfil the security or UX requirements. My suggestion would be a standardised web API (like or as an extension of the Web Crypto API) that would enable browsers to give websites the ability to use certificates to sign and decrypt messages without revealing the key. This would be a feature that would fall within the responsibility and expertise of the browser. All browsers already have the capability to store and handle certificates for client authentication via TLS, although the UI might need some work.
The biggest challenge would be how to backup and synchronise the certificates across multiple devices. Users can do this manually, but lost certificates and emails that can only be read on one device could still dampen their enthusiasm.
Making it official
While making it as easy as possible to use encrypted emails is certainly a requirement for success, external pressure can be similarly pivotal. The success of HTTPS was not only due to Let’s Encrypt, but also to Google’s call for HTTPS Everywhere and making HTTPS a ranking signal in their search results.
For email encryption, this could be communication with government agencies. After decades of disastrous e-government initiatives like DE-Mail, a well-made effort to simplify communication between citizens and government agencies could lead to a renaissance of email encryption.
Imagine S/MIME certificates that are issued together with national identity cards and can be used for correspondence with tax or registration offices. Without any web portals or other isolated solutions. The certificate would validate the identity, not the email address, which would require an update to the S/MIME standard. However, this change would not be that big and could easily be adopted in different countries.
As this is an idea that would need to be pursued independently of the aforementioned changes anyway, I won’t go into any more detail than this today. Maybe I’ll write a full article on the concept at some point.
Conclusion
Even with the proposed improvements, it is likely that email encryption will never become widely popular. However, as email is not going anywhere, we shouldn’t give up on it either. IMHO, even if we can only make it slightly less annoying, it’s worth trying.