Yeah, I didn't post here in case it just confused things more than helped things. I think there are lots of different Microsoft-run email products, so I don't know as they all do this. But there are configurations where the current recommendation is authenticating your mail server to theirs with a publicly-trusted client certificate, yes.
I think there's sometimes a lot of focus on Let's Encrypt just because they're more proactive and transparent than other CAs about their planning. This Chrome policy charge really isn't anything specific to Let's Encrypt, and while people might have found utility in using Let's Encrypt certs for client certificates in the past and present (I know I have in the past, at least), it really isn't part of their core mission.
I think that's actually the ultimate goal here: To have client certificates be a separate hierarchy, and only used if needed. Kind of like how S/MIME and Code Signing and such are separate things for separate purposes. I think the question that may really be on people's minds is around what the typical user cost and experience will be for getting such certificates (in an automatable way such as through ACME), and from what CAs. I'm not aware of other CAs having stated their plans yet, so there's uncertainty. If we could just say "Oh, the such-and-such CA is running a client certificate hierarchy, and you can just point certbot to --server https://such-and-such.example to get free client certificates just like you are now", then I think there'd be a lot less consternation. But we don't yet know what the future will bring.
Well, if you're using Google CA right now for client certificates, please ask them for what their plans are for complying with the Chrome root program requirements to split out server and client roots.
It's a tough problem. Each root program really can use whatever criteria they want for including or excluding roots, which I'm sure makes things tricky for the CAs to try to be included in all the places they want to be included. The state of the public PKI is certainly better than it was in say, 2011. The CA/B Forum (created the next year) has helped with that governance and discussion to make common standards. But certainly root programs have sometimes felt the need to push past that and just implement their own additional requirements to move the industry forward: Google unilaterally required Certificate Transparency logging, and Apple reduced maximum certificate validity to ~one year, both I think (correct me if I'm wrong) without having full buy-in from everyone, though the rest of the industry eventually followed. I don't know as that's really the best approach, and I'm not thrilled about so much power being concentrated in a couple specific big companies either. (And the issue goes well beyond CA root programs: W3C lost control of the HTML specification because browsers wanted to do their own thing, and many web standards are basically "What does Chrome do" now.) I'm not sure forcing users to pick and choose which CAs they really want to trust rather than having browsers ship with their own carefully-chosen defaults would actually be a better world, though.
Exactly. It's just not clear (at least to me) how a public-CA-driven client certificate hierarchy has enough advantages over using private CAs to make it worth non-profit organizations spending effort on it. Maybe it is worth it, and another non-profit, or maybe some big tech company, will make something. I can see how it's worth asking around for who's interested in running such a thing. But I don't think there's a whole lot of interest out there yet. Or maybe there just needs to be clearer guidance and how-tos out there about how people should set up and run their own private CAs, both for client certificates and for server ones.
And while I appreciate your trust in me, I'm not officially a "Community Leader" in the sense of having that "title" in the system. And regardless of title, to be clear I'm just a random guy on the Internet who sometimes has some coherent thoughts, but I have no idea what Google/Apple/Mozilla/Microsoft/CAs/etc. are planning on doing next.