Two of the axioms of my generation (I was born in the Netherlands in 1970) always were
- The USA is good
- Israel is good.
We were taught that valid criticism is OK, but the axioms stand, not to be disputed.
For me, those axioms have been destroyed. By the USA and Israel themselves.
That's a fundamental change, but I accept it.
1/3
(Axiom: a statement or proposition which is regarded as being established, accepted, or self-evidently true.)
This means to me that I hold no grudges nor do I feel hate against citizens of the USA or Israel. I have friends in both countries, who continue to be friends. My friends are people, not countries. But for me it will take a long time and a lot of reliable and sustainable action by the USA and Israel to rebuild trust in them..
2/3
Two of the axioms of my generation (I was born in the Netherlands in 1970) always were
- The USA is good
- Israel is good.
We were taught that valid criticism is OK, but the axioms stand, not to be disputed.
For me, those axioms have been destroyed. By the USA and Israel themselves.
That's a fundamental change, but I accept it.
1/3
(Axiom: a statement or proposition which is regarded as being established, accepted, or self-evidently true.)
TL;DR Jens Spahn (paraphrasiert von mir): "Wir verurteilen uns ausdrücklich für unser Verhalten und freuen uns darauf genauso weiterzumachen."
(possibly paywalled) https://www.sueddeutsche.de/politik/bundesregierung-liveblog-news-brosius-gersdorf-bundesverfassungsgericht-kandidatur-rueckzug-li.3294142
Die SZ berichtet ausführlich über die Fehlplanungen hier in Trudering:
"Der Witz an der Truderinger Straße aber sei, dass diese „das am wenigsten gelungene Beispiel“ dafür sei, Fahrradfahrern mehr Raum zu geben. „Sicherer ist für Fahrradfahrer nichts geworden, und ich kann jeden verstehen, der bei dem Konfliktpotenzial auf den Gehweg ausweicht“, sagt der BA-Vorsitzende Ziegler.
(leider evtl Paywall) https://www.sueddeutsche.de/muenchen/muenchen-truderinger-strasse-verkehr-umbau-radfahrer-autos-li.3267050
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
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
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
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
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 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
Jan Wildeboer 😷
:krulorange: