That only applies when you're replying to someone. It doesn't apply to new conversations or adding someone new to an existing conversation.

Let's Encrypt has always had short-lived certificates, long before they were mandated by the CAB. They've been pushing the cutting edge here

And at how many days or minutes does it turn from security into security theater?

If we follow this line of thought it would be more secure to only serve sites to consumers through a few "trusted" third parties right?

Certificate revocation applies to all uses of PKI, not just web browsers. In fact, it is an even bigger problem with email, because there are so many more email addresses than web sites.

But you can't re-use the private key, and you can't keep the same one around for very long. In a thread about "why can't we do Let's Encrypt but for email", surely we must start by accepting one of the most important lessons of the modern WebPKI era, which is that CRLs and OCSP do not work at the scale involved here, which has led to keys and thus certificates being constantly rotated.

Somebody else already said "key management is the hardest problem" and I wholeheartedly agree.

The short lifespans are to encourage people to actually automate, not just say they want to.

If the cert lifetime is 5 years, Bill installs "just the first one" manually, solemnly swearing they will automate next time, and in five years nobody even knows who Bill was, Bill left three years ago. How do we replace the certificate?

If the cert lifetime is 2 years. Bill is still there or maybe somebody on the team still knows Bill's email address, but most likely the decision is taken to "just do it manually once because it's urgent" and we just recurse. This would have been the "obvious" choice when ISRG lit up Let's Encrypt.

But because the cert lifetime was 90 days, Bill gets told it's expiring at about the same time he's about to shove that "Actually automate certificates" work onto the back burner. Oh yeah, right, we should actually do that.

Now, it may be that at a startup that "Automation" is initially "Put it on Natalie the intern's TODO list every Monday" but by week six Natalie has learned about cron, or Windows event scheduling, or a dozen other ways to make stuff you always do regularly happen without actual work. Today I expect her LLM will tell her how to do it.

And Natalie is going to discover that some "permanent" solutions are more permanent than others, that you want monitoring and so on. But because Let's Encrypt is so popular unless you're doing something pretty esoteric you won't even be the first person to ask about it this month.

You wouldn't. Let's Encrypt doesn't verify anything more than that the requestor of the HTTPS certificate currently has control over the domain. The equivalent would verify nothing more than that the requestor of the S/MIME certificate currently has control over the email address. This part is actually a fairly standard procedure already, as a lot of websites will send verification emails to fully activate new account signups.

Persona?