The way I understand the history of x509 certificates, it was always meant to be decentralised. A network of trust with a certain level of hierarchy, but with lateral trust relationships between organisations. This is how it works for travel documents since many years. But on the internet we got a massive push towards centralisation, leading to the typical reply I now get when talking about setting up a CA (Certification Authority): "It will not be trusted". That's not how it should work...
1/n
The "It will not be trusted" comes from the move from "I decide which root CAs I trust on my machine(s)" via "It's OK to leave that decision to the experts" to "I will accept whatever the CA/Browser Forum, Google and the operating system provider trust and will not go beyond that". And we are getting closer to simply not being allowed anymore to add root CAs to the trust store ourselves. And where we are not allowed to remove root CAs ourselves when we decide they don't deserve our trust.
2/n
And especially Google and the CA/Browser Forum keep on tightening the rules, making it more complicated and expensive to be allowed to have your root CA added to their pool. It has become a very exclusive club where the bouncers will tell you "You are not a member, go away". That's a lot of almost dictatorial power in the hands of mostly commercial interests.
3/6
The latest move by Google and backed by the CA/Browser Forum: no more "clientAuth" in certificates, only "domainAuth". While this sounds like an obscure technical detail, it has quite big consequences. "clientAuth" is used to connect services (mTLS) in clouds and beyond. The fact that every LetsEncrypt certificate has "clientAuth" made microsoervices work seamlessly. Now the CA/Browser Forum tells you that if you need "clientAuth" you should setup your own CA. Which is quite a burden.
4/6
And while you might think "Opportunity! Let's create a CA a la LetsEncrypt for mTLS certs with clientAuth!", you will have a bigger problem. This decision by Google and the CA/Browser Forum means that they only accept root CAs in their pool that do NOT sign certs with "clientAuth" or any other EKU (Extended Key Usage) except "domainAuth". And yes, that includes the EKU "emailProtection" that you need for S/MIME certs. In case you wonder why I spent so much time on creating those ;)
5/6
I will stop here and turn this thread into a full blog post soon where I will also add sources for everything I said. I think that the certificate ecosystem needs more attention and that we in the Fediverse should have some tough discussions on how the current system works. As enabler or limiter of federation the way we use it.
6/6
Addendum: I've been thinking about this topic for quite some time. And I thought about possible alternatives to centralised trust stores in the certificate field. I put that on a website (with a letsencrypt certificate ;) at https://nerdcert.eu
Jan Wildeboer 😷
:krulorange: