The number of awesome things we're going to get as a result of this is exciting to think about.

My wife bought this fuckass IoT air purifier that's constantly phoning home. I'm gonna figure out what it's telling the mothership.

> Yes, but in the end that's not their fault, and in a sense it's good that this happened.

I am reminded of the US DST changes back in the 2000s: there was all sorts of drama because a lot of software is written in the US, and there was much 'computerization' in the 1990s, but US coders had never personally experienced a DST rule change during that time period, so any change needed a reboot to pick up the new rules.

That drama led to (e.g.) periodic dynamic checking of /etc/localtime on various Unix-y system.

Sometimes you don't realize that things can be improved until you experience situations in which they currently suck.

Google has decided to stop trusting certificates with dual purpose (server and client) and managed to negotiate a decrease in the maximum (SSL/TLS) certificate lifetime because certificate revocation doesn't work.

We've had to rework part of our application and certificate use because of this.

Kind of what Let's encrypt did for automating certificate rotation.

Let's call it "Let's Decrypt!"

Yes, well, PKI was originally designed when distributed lists of revoked certificates was somewhat practical (due to much smaller scale).

Now we are in a situation where we don't really have a practical and correct way to revoke certificates, but many, many things depend on pki.

> It might even be sensible to intentionally revoke a small number of certificates every month, to make sure nobody is complacent.

No, this is not even remotely sensible.

Honestly, that's not a bad idea at all. That's exactly the kind of thing that companies like Google do in disaster recovery testing.

If you don't know if you can hot-swap your certs, you probably can't.