On Tue, Jun 17, 2025 at 02:16:19PM -0400, David Benjamin wrote:
> This draft is not the way to solve this problem.
I should mention, that though that is also my reaction, we are by no
means on the same page here. I find the Google position in:
https://googlechrome.github.io/chromerootprogram/#321-applicant-pki-hierarchies
to be substantively indefensible. Google are not merely saying that
Chrome will not trust certificates with a "mixed" client/server EKU
(which is a nuisance position I can live with), rather they are coërcing
the CAs to not issue any client certificates even for non-Chrome
use-cases. That in my view is massive overreach, bordering on
(if not squarely) monopolistic behaviour.
> The point of markers like EKUs is to avoid cross-protocol attacks.
Sure, but *TLS* client auth vs. *TLS* server auth is NOT a
*cross-protocol* attack. The Certificate chains presented by clients
and servers have the same structuure in TLS protocol and the certificate
verify messages are constructed identically, both covering the handshake
trascript to that point in the protocol. Yes, the key holder may have
just one the usages in mind, and so request a certificate for just one
of the two roles, and Chrome might (a nuisance) might be in a position
to refuse to trust mixed use certificates, but to preclude the CA from
issuing mixed-use certificates, seems to be an invitation for just the
kind of work-around seen in the proposed solution.
The fix is for Google and the CAs to back down and make it possible to
obtain clientAuth, serverAuth or clientAuth+serverAuth certificates from
the same (not just WebPKI) CA, be it that perhaps two of these might
not work with at least Chrome.
Otherwise, libraries used for more than browservers may well have to
implement the proposed ugly work-arounds.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
