On Wed, Jun 18, 2025, 10:42 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. > No they are saying the CA has to issue those off a different hierarchy. Nothing prevents the CA from offering that service. > > > 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. > The WebPKI is the universe of CAs that issue certs that browsers trust. They don't care about anything outside that. > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
