Getting ready to issue IP address certificates

I think certificates for IP addresses can be useful.

However, if Let‘s encrypt were to support S/MIME certificates, it would have a far greater impact. Since a few years, we have an almost comical situation with email encryption: Finally, most important mail user agents (aka mail clients) support S/MIME encryption out of the box. But you need a certificate from a CA to have a smooth user experience, just like with the web. However, all CAs that offer free trustworthy¹ S/MIME certificates with a duration of a year or more² have disappeared. The result: No private entities are using email encryption.

(PGP remains unused outside of geek circles because it is too awkward to use.)

Let‘s encrypt our emails!

¹ A certificate isn‘t trustworthy if the CA generates the secret key for you.

² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical

I know little about s/mime encryption. But why do we need to decrypt old emails with the same protocol? In my head, I imagine certs would be for transport, and your server or host should handle encryption at rest no? So short lived transport certs, and whatever storage encryption you want. What am I missing here?

> ² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical

You don't need to change your decryption key - the new certificate can use the same decryption keys as the old one (certbot even has a flag: --reuse-key). Whether this is a good idea or not is a separate question.

I think the biggest benefit would be ACME-like automatic certificate issuance. Currently getting a new certificate is just too much friction.

How would CA verification work in this case?

This is totally off-topic. With all respect, if you want to discuss email encryption I would suggest that you write a blog post or start a separate thread.

A beautiful vision, but not practically viable. The average user isn't ready to handle private keys -- many can barely be trusted with their email passwords.

This means you either need centrally issued certificates for each domain, or face situations where legitimate users fail to obtain certificates, while cyber criminals send S/MIME-signed emails on the users' behalf.

Once a few generations of users have been trained to use passkeys then we can consider letting users handle key pairs.

S/MIME is about the mail (content) itself, not the transport. For the transport part there are things like (START)TLS and MTA-STS. With S/MIME you include your certificate in the mail and can either sign the mail with a signature (with your private key, others can verify it using your public key from the certificate) or encrypt the mail (with the receiver's public key, so only he can decrypt it using his private key). Certificate trust is determined normally via the CA chain and trusted CAs.

The other thing I would hope for is wildcard certificates. I stopped using S/MIME because I usually create a new email (based on the same domain) for each vendor that I deal with. I would find it useful to be able to get a single certificate covering all email with that domain. Obviously that does mean that anyone else using an email from that domain would have to share the certificate, but for private use that can be acceptable - I don't worry about my wife reading my currently unencrypted email!

PGP has WKD[1] (Web Key Directory) now if you want to use the TLS web of trust for email. TLS certificates are much easier to get than S/MIME certificates. Having a third party do the identity management can be good, but many people do not work for a company where that makes sense. ... and if you do work for such a company, it is better to do the identity management within the company.

I am currently appalled at how little of a wakeup call Signalgate 1.0 was and is[2]. Signalgate was, yet again, a failure of identity management in end to end encryption. You know, the exact thing that S/MIME certificates (or WKD) could help solve in a government environment if the resulting system was actually usable.

[1] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...

[2] https://articles.59.ca/doku.php?id=em:sg (my article)

Hell no. Email encryption should be left to rot.

https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...

Maybe with a local passkey on device ?

Oof, I don’t like this article much at all.

The first two major points they pose against email can be summed up as ‘people don’t use security unless it is by default, and because it wasn’t built-in to email we shouldn’t try.’ To which I respond with: perfect is the enemy of progress. Clearly, email is sticky (many other things have tried to replace it), and it has grown to do more than just send plaintext messages. People use it for document transfer, agreements, as a way to send commands over the internet, etc. Email encryption and authentication is simply an attempt to add some cryptographic tooling to a tool we already use for so many things. Thus, these points feel vacuous to me.

The last two points are less to do with email and more to do with encryption in general, and it is probably the most defeatist implication of the fact that there is no ‘permanent encryption.’ It is an argument against encryption as a whole, and paints the picture for me that the author would find other reasons to dislike email encryption because they already dislike encryption. These last two points are an extension of wanting an ideal solution and refusing to settle for anything less.

Based on my personal experience providing support for s/mime setups, you'd need: 1) A centralised solution for managing keys and certificates, connected to a login that the customer will be able to recover in pretty much any situation. 2) Email client support for fetching keys/certificates from the centralised solution. 3) A massive focus on usability and end-user support, because most email users have no idea what a certificate is, or how to use it.

Denmark actually has something similar to this (Sikker mail) but it's mainly aimed at businesses. Based on what I've seen, this resulted in a market for services that bypass the E2E aspect of it because business users can't figure out how to use it. It is also noteworthy that despite this s/mime being available for everyone, Denmark has a public digital mailbox for all citizens and businesses in order to ensure availability.

S/mime is great. It is also not suited for people who barelly know what it is.

If Lets encrypt sets up an automated system then MUAs could automatically request certificates for you. So the user wouldn’t have to deal with the issue.

There may be a need to distribute your certificate if you read and write mail on multiple devices.