On Thu, Jun 19, 2025 at 09:29:06AM +0200, Filippo Valsorda wrote:
> 2025-06-19 07:39 GMT+02:00 Viktor Dukhovni <ietf-d...@dukhovni.org>:
> > 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.
>
> No, they are requiring CAs who wish to have a root included in Chrome
> for the purposes of TLS server authentication to issue roots dedicated
> to TLS server authentication.
>
> CAs as entities can operate multiple roots and are not constrained in
> what they issue from other roots. (That would be indeed outrageous!)
And which roots are these that are dedicated to non-web use-cases? And
is the rationale for this sort of domain separation at the root CA layer
at all compelling? One might, for example, instead dedicate to this end
intermediate issuer CAs having a serverAuth EKU, that will in many (be
they for now ad hoc, rather than RFC5280-blessed) TLS stacks be
intepreted as restricting any issued EE certificates to that EKU
(implicit or explicit).
Imposing the requirement on the root CAs, rather than on the EE
certificates considered valid, seems rather dramatic overreach.
If this remains in effect long-enough, ugly work-arounds should
be expected.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
