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.

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

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

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.

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.

As I understand it, the reason for so much work is that eMudhra was not a root CA. It wasn't added to any official root CA list, instead it was signed by a different root CA with the assumption that eMudhra will complete the work required to become a root CA and this hack will become unnecessary. This is a common, temporary process. So while all the mechanisms for root CA revocation were in place, no one was quite prepared for intermediate certificate revocation.

Good point. I get why some stacks use their own trust stores and not the system trust store. But there should be some mechanism to revoke trust to some of the CAs, without applying patches or rebuilding. Even if its just a convention based /etc/certs/revoked-certs file.

It looks to me like the world was decently prepared to deal with it. The bad certificates are being blocked and there don't appear to be widespread compromises.

That doesn't mean it's cheap or easy, or that it's reasonable for the responsible party to brush off all the havoc they've caused.

It's the attitude that riles me.

This demonstrates how hard we are messed up in a CA revocation. But no need to rub it in like that, is there?