I love this summary, which is better than I could have written myself, and feel no need to clarify. Instead I'll add the origin story of my dislike for mTLS. N

I love this summary, which is better than I could have written myself, and feel no need to clarify. Instead I'll add the origin story of my dislike for mTLS. Not too long into my tenure of being an active maintainer of Apache httpd I somehow ended up being the X509 person. I'd worked on some of the crypto code in Apache-SSL, which was maintained by non-US people only at the time, and X509 sort of fell into that bucket. I also got on well with Dirk-Willem van Gulik who wrote a lot of the original X509 code, and later he ended up hiring me, but that's a different story. As part of being an "Apache x509 person" I got a consultancy gig to audit an "Enterprise" company's mTLS setup. On the first day, based on nothing more than tailing logs, it became clear that some people had access to things they really shouldn't. The CTOs Executive Assistant, who was part of the group trying out mTLS, actually had god level access to everything. EAs are gods and should be worshiped, they make companies run, but this level of access was not intentional. A few hours of root causing and I figured out that the EA had god-level access to everything just because the string "admin" was in their job title. Access was being granted based on a greedy PCRE regex match on a string. It wasn't even in the right field in the certificate, but the string matching didn't care. This is what x.509 does to your brain. Similar gigs would find more problems; to an approximation, no one had working revocation, more than once I found setups that didn't even require client certificates, but no one had noticed. Over time I just got the impression that x509 was commonly set up by folks who were blinded by a cryptographic luster but wouldn't follow through. There's been a general absence of professionally built solutions that get the details right.