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.
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?
If the purpose to authenticate any and all (particularly never before
seen) clients, then indeed you'll need public CA issued client certs.
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.
[ 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. ]
> 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.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
