Hi,
any plans to create support for s/Mime / Mail clients and/or application signing?
3 Likes
There was another topic requesting encryption of email As far as I’m aware I’ve seen no official plans.
2 Likes
I want this as well.
We don’t have any plans to tackle email encryption at this time (though you can use Let’s Encrypt certs for TLS between mail servers). We don’t yet know of any email encryption solution that can scale very far beyond a technical elite niche.
It’s an important but very hard problem to solve. We don’t have the answer now but we’re keeping an eye out for promising ideas.
2 Likes
josh
We don't yet know of any email encryption solution that can scale very far beyond a technical elite niche.
Josh, what advanced technical skill or elite status is required to use Comodo's free S/MIME solution then?
If one admits no technical skill is required to use the Comodo solution, what are the drawbacks of using it, if any?
Thanks.
1 Like
@Josh and serverco: Thanks for the great job you guys/gals are doing. Your work is making the internet a better place for everyone.
I can imagine that things are busy right now. If in the future, when you may be exploring new waters, may I second the request for S/MIME?
-
One solution could look like Comodo’s automated process, in which the end user applies for an s/mime cert for their email address by filling out a small form.
-
An alternative solution could be background work with major email providers to issue s/mime certificates by default to each of their customers, but these certs could reside ultimately with LE’s CA, or, LE could act as a middle man for email providers’ own CA servers (which act as subordinate to LE).
Freely available website encryption is probably the single best thing that has happened to the internet in recent years. Thank you for doing the hard work. Email encryption could take that another major step forward.
1 Like
why not look at PGP encryption?
There are plenty of providers who will allow you to distribute public keys so other can encrypt emails to you
Looking at this there are two aspects of SMIME one which is integrity which is fairly straight forward. The challenge with the encryption component (from what I see) is that you need to distribute certificates ahead of time to trusted parties.
ACME is designed to be automated and require little human intervention. I can’t see how this would be possible when users email clients are involved.
Andrei
Dear Josh,
as far as I know, S/MIME requires an X.509 certificate like the ones you are already issuing. The difference to a certificate used for an Apache e.g. is a populated eMail field. The CN field can even be empty for S/MIME. So it should not be too difficult to offer a service like that. All it requires is a web interface to upload your CSR. The certificate could then be loaded into the browser or offered as a download.
@Jarod42, I believe it’s not that simple.
Issuing valid S/MIME certificates requires additional trust bits set on root CA certificate and enabling them is on discretion of root CA store operators, such as Mozilla, Microsoft and Apple. This would require Let’s Encrypt to use cross-signed CA to speed up inclusion process (just like with certificates for websites), which would probably require changing their agreement with IdenTrust and/or obtaing separate CA certificate (I guess that IdenTrust is not doing that for free 
).
You cannot simply upload CSR to obtain S/MIME certificate, as CA has to perform validation that you are indeed in control of email address. Let’s Encrypt is based on ACME, so I guess that would require changes to ACME protocol specification (and implementing them in Boulder - CA software). It’s difficult to perform email-only validation securely, as validation message may be intercepted between SMTP servers (some servers are not using SSL/TLS at all, so messages are transmitted in clear text).
I guess there may be also some technical challenges, as more certificates would require more OCSP signing capacity - which may in turn require buying additional HSMs (Hardware Security Modules) to be able to sign responses for all certificates. Let’s Encrypt is still non-profit run for the public’s benefit - and unfortunately HSMs are not cheap.
A lets-encrypt baked acme for smime solution would be really game-changer in my eyes. Imagine those setups running groupwares with central smime store and a lot of e-mail addresses handled. As far as i see, this is the typicall use-case of email in a company context or privatly used by tech-geeks. These groupwares like kopano could integrate acme for smime to retrieve certificates in a centralized manner. So there will be no excuse to have no e-mail end-to-end encryption in company contexts, when this is mechanism is available.
So i would love to see acme for smime baked by letsencrypt 
1 Like
Although I do enjoy “baked” products…
I think it reads better as “backed” or maybe I’m just not as hungry as you are! - LOL
2 Likes
Flagging that Comodo/InstantSSL is discontinuing their free S/MIME support under their new structure (Sectigo?). StartCom’s certs are no longer trusted for good reason, and CACert requires user configuration to trust their certs for all purposes, which is suboptimal. It looks like there is an Italian cert provider (actalis.it) still offering 1-year S/MIME certs, but the space is shrinking.
While I would overall prefer GPG, S/MIME is built in across platforms, including mobile, without having to support a wide variety of different helper applications which don’t interoperate perfectly (and/or get mangled by MS Exchange).
All this to say, I know this is a long-standing ask of LE, which has been reliably rebuffed – but – it could be amazing in terms of normalizing e2e encrypted and authenticated email.
(I am happy to help seek additional sources of funding and provide mountains of uses cases and personas)
1 Like
It seems like Signal and other messaging platforms designed from the ground up to be e2e have taken over entirely, though. And while nominally supported, built-in S/MIME usability is … woeful, at best.
I’d totally be overjoyed if LE supported it, like any advancement, but S/MIME kind of died on the vine outside of internal networks.
Obligatory, 'came here to post this' - but yes, the options are definitely narrowing. It's a huge shame ISRG haven't committed to doing anything in this space.
I don't see the relevance of Signal, it's an IM platform.
What's the problem with S/MIME usability in modern email clients? It's certainly easy enough to sign and encrypt messages in Thunderbird. OWA supports it, GMail in organisations supports it (and can verify signatures just fine with the consumer version).
I'd argue adoption has been limited precisely because certificates have been a pain to obtain.
3 Likes
If only someone would make a simple and automated way to obtain such certs…
3 Likes
And I don't see the relevance in splitting messaging into "IM" vs "email" when they're essentially the same thing, merely presented slightly differently in the client. Gmail's web interface famously blurs this line significantly. Signal is a decentralized store-and-forward protocol to exchange encrypted messages.
Signal clients turn all of the steps to get the equivalent to S/MIME working for an individual (who doesn't have an IT infrastructure to do it for them) into a turnkey package, with a few buttons you can click to generate a new encryption key or erase an old (along with any unsaved messages encrypted with it) permanently.
Unless you need your identity verified by real documents ($$$), I don't see the purpose of pursuing S/MIME over currently established secure messaging routes. After all, that was the real original purpose of S/MIME -- identity and organizational verification alongside encryption.
There's a very significant differentiator that immediately comes to mind: adoption. How many organisations do you know of that are using Signal? S/MIME is definitely already in significant use within government and industry. People have email clients which support it out of the box. How many systems have a Signal client pre-installed?
I'd also argue that their is a significant difference between "IM" and email, and the user expectations that go along with the two different forms of communication. This is definitely more of a UX thing, but there's no concept of a 'conversation' thread AIUI. There's much more of an expectation of real-time messaging with these platforms too.
Anyway, I fear we are straying off-topic. For anyone else interested in this, @josh posted a comment on a HN thread today re-affirming that S/MIME is not something LE is interested in pursuing.
1 Like
I think this is still possible. Instead of installing certbot (or any ACME client) in the server, we install it in the same machine running email client. We will need the user to interact (like clicking a link in email), but this is no more complicated than current S/MIME certificate issuers like Sectigo (Comodo). In addition, this is pretty scalable on issuer's side, as scalable as current ACME for TLS certificates.
1 Like
The situation for S/MIME in a private setting is bleak.
There isn’t a single CA that will sign your S/MIME certificate for free with a duration of one year or more.
There are two CAs that I am aware of that generate a private key for you (which is a total no-go). They are secorio and wisekey. People who are not knowledgeable will fall for these scams.
This leaves a huge gap for Let’s encrypt to fill.