←back to thread

Getting ready to issue IP address certificates

(community.letsencrypt.org)
314 points Bogdanp | 2 comments | 25 Jun 25 16:21 UTC | HN request time: 0.465s | source
Show context
Tepix ◴[26 Jun 25 05:56 UTC] No.44384559[source]▶
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

replies(7): >>44384654 #>>44384891 #>>44385019 #>>44385077 #>>44385105 #>>44386239 #>>44386412 #
1. arccy ◴[26 Jun 25 11:40 UTC] No.44386412[source]▶
Hell no. Email encryption should be left to rot.

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

replies(1): >>44387517 #
2. kurikuri ◴[26 Jun 25 14:00 UTC] No.44387517[source]▶
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.