(resent without breaking the thread) On 2025-06-17 18:06:01, Viktor Dukhovni wrote: > On Mon, Jun 16, 2025 at 08:20:06PM +0000, Klaus Frank wrote: > >> because of recent events with policies of public CAs and associated >> "fallout" that removed the ability to get publicly trusted >> certificates with clientAuth for dNSName and ipAddress I've written >> this early draft of a now standard I'd like to propose. As this breaks >> any and all mutual TLS authentication between systems relying upon >> public trusted certificates (like XMPP, AD FS, or SMTP with mutual >> authentication, like e.g. the Microsoft Exchange Hybrid deployment >> uses) some solution is required. > Well, at least in SMTP, mutual server-to-server authentication is quite > rare, and even in the case of submission, where it is somewhat more. > common, rarely relies on identity bindings from public CAs, it is not > clear to me that SMTP would be significantly adversely affected.
mutual auth with SMTP mainly impacts Microsoft Exchange Hybrid deployments (and similar setups involving different contractors, e.g. anti-spam or "mail security" providers), as Microsoft still demands a publicly truted certificate on the on-prem side. It also was already tried to make Google reconsider. But to no avail. Basically they don't care about the practical issues and at most say "just roll your own PKI" as everyone apparently should just stop using the Web-PKI for other services entirely. Well only issue is that there is basically no other PKI infrastructure to migrate towards. Especially none that can be assumed to be universally trusted. Call it lazyness or whatever but almost everyone relied upon the Web-PKI. Or does anyone know a single one that is e.g. trusted by all operating systems but not by web browsers that could be used here? And as you can see within the discussions in the links I provided in my initial post most of the argument was basically spent trying to point out that "TLS-Client" is the client of a TLS connection and not a client device. Hence why I put that into the draft as well. Once that missunderstanding was solved there was basically no more discussion. > The XMPP use-case does seem more applicable, but isn't the solution > to convince the CA/B forum CAs to reverse their nascent policy, rather > and resume or continue to issue client+server certs, rather than to > try to change every TLS implementation to hack around this? I wouldn't consider this as "hack around this", apparently we're just re-alligning the understanding of what a TLS-Client is, as google (and CAs, see end of this mail) consider this to mean only enduser/client devices. So in my eyes we currently have a missmatch between what the policy says a TLS-Client aka clientAuth EKU is and what the RFCs and technical validators say it is. As some others (esp. on social media) were pointing out this argument (aka intentional missunterstanding of TLS-Client) could have been in bad faith. Some even said this was a very clear power move by google to prevent people from easily moving towards decentralized (not US tech giant controlled) infrastructure like XMPP as such decentralized setups were basically all relying upon clientAuth and mTLS. However that is speculation and it doesn't change the problem at hand. Basically over night all server-to-server usages relying upon mutual authentication using publicly trusted certificates broke. Many admins may not even have noticed it yet and will be faced with the choice of shutting down their server or disabling tls validation entirely (current implementations do not have any other options) once enough certificates start to expire. > If the purpose to authenticate any and all (particularly never before > seen) clients, then indeed you'll need public CA issued client certs. That is exactly the main purpose. And this is also what I was trying to solve with this draft. > If the purpose is authenticat a handful of peers with which the server > has an established prior relationship, that's better done by avoiding > the public CAs entirely, and issuing a privately minted cert to each > such server, or curating table of client public keys. Sadly not the case here. But even in that case there would be two sub cases. a) all involved systems belong to the same administrative domain => That's where I agree with you. b) the involved systems belong to multiple different administrative domains => There I don't agree, but a middle ground could be to pay a CA to maintain a dedicated private CA for all of the involved parties. Otherwise each of these organizations would be able to issue certificates that are way to broadly trusted in the systems as all of the enterprise CAs from each of these parties would have to be installed in each others Root CA store. And at least for windows that also would allow issuing ANY kind of certificate including the ones for domain controlers and such. > [ And we can always encourage adoption of client DANE TLSA records, if > the goal is to avoid server side "pinning" or issuance of client keys. ] I don't know if we need a dedicated "client DANE TLSA record" both sides are servers after all, so the "normal" DANe TLSA record should be sufficient. At least together with a forward-confirmed reverse DNS lookup as I wrote in the draft. >> This should also address the obscure and unspecified "security >> concerns" the Google Chrome team stated as reason for the policy >> change that caused any and all CAs to drop issuing clientAuth >> certificates. Even the ones that still issue certificates with the >> clientAuth flag set do NOT do so for devices and only for endusers and >> organizations (EV and OV). > If Google's advocated changes were poorly conceived, it should be > possible to make a case to the CA/B forum to reverse the erroneous > policy. Doesn't work, even though the Policy from google says it was agreed upon with the CA/B Forum it wasn't. The CA/B forum still says that a cert "MAY" contain clientAuth. Google however decided to throw all CAs out if they issue clientAuth certis from a CA that traces back to a root CA that is included within Google Chrome. Basically changing that "MAY" that was put in there exactly for these server-to-server reasons into a "MUST NOT". I don't know a single CA that issues clientAuth certificates that are commonly (aka publicly) trusted be it free or paid. Also I don't know which CAs are even commonly trusted and are not within the Web-PKI hirarchy. Some CAs setup a dedicated CA that isn't within the Web-PKI and therefore also isn't commonly trusted for issuing clientAuth certificates. However they do not issue such certificates towards dNSName or ipAddress. Also underlining that "clientAuth" is commonly missunderstood as "Enduser Authentication" by CAs as well. And if I take that argument literally on the other hand it shows that CAs and all of the people involved in the Chrome Root Program commonly understand clientAuth to mean authentication like e.g. via SmartCard and not server-to-server. So I don't see an issue with updating the RFC to reflect the common meaning of a term then. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
