A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.

Less labour intensive for whom?

Anyone using email validation now needs to click a link every month, or their cert goes away.

I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains.

Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.

Less labor intensive than requiring validation and deploying a new signed certificate every month.

>and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day.

If you're in a position to MITM using a stolen certificate, you're probably also in a position to block the CRL response from going through. Since failing to get an updated CRL doesn't result in a security warning, your CRL proposal is essentially useless.

> you're probably also in a position to block the CRL response from going through

Not if the certificate is OCSP-Must-Staple.

One of the arguments that I've seen for shorter-lived certs is that revocations aren't honored particularly well. If we could fix that, then your proposal would make sense (but I'm not sure that's doable)

Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure.

Short cert lives make certain decloaking much, kuch more difficult.

It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key.

It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs.

[1] https://www.ssllabs.com/ssl-pulse/

However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange.

That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...

I heard perfect forward secrecy is intended to prevent decrypting past traffic.

Good!

CAs are resting all and every changes because it's easier, it makes sense.

CA's are resisting because the only person to buy from them is someone who can't set up certbot and lets-encrypt. As soon as they cant issue for longer than a year, their market is being whittled away.

> the only person to buy from [CAs] is someone who can't set up certbot and lets-encrypt

Digicert is in the process of migrating their customers to ACME (the issuance protocol used by Let's Encrypt and certbot). Where's your god now? :)

And that's two out of how many?

As long as you first create a root certificate then you can create how many certificates you want.

Assuming non-chained root CAs remain trusted.

I can forsee the browsers eventually treating self-created CAs like they currently treat self-signed certs. if they're not traceable to a trusted root CA then there's no accountability, from a browser perspective, in the event of abuse or breach.

Then people will create their own root CA and use it to sign the existing root CAs. Whatever it takes. Corporate users need internal certificates.

Self-signed certificates are insecure, so, no.

Aren't they allowed already, with a click-thru warning screen? And you can also choose to trust them permanently, aka trust on first use.

No... web of trust is an important aspect to https.

s/web of trust/centralization/

s/centralization/validating ownership

Without centralization I can MITM at the coffee shop and steal passwords.

WoT would fix that, unless the other coffee shop patrons have (directly or indirectly) trusted you.

They should at least allow for local addresses