On Thu, Jun 19, 2025 at 10:04:47PM -0500, Nico Williams wrote:
> > If making a serverAuth intermediate is acceptable, then it sounds like
> > there is no issue here: just self-sign it and submit that to the
> > Chrome Root Program. The policy doesn't say anything about the parents
> > of the roots. (That would be indeed outrageous!)
>
> I'm guessing the rationale for Google's change is to protect apps that
> support client certificates poorly (usually the norm) that
I haven't seen a definitive statement of the rationale, I am sceptical
that the Chrome browser would be concerned about the security of some
server soliciting and misinterpreting client certificates. David
Benjamin's mention of hypothetical cross-protocol issues is somewhat
more plausible, but not in my opinion defensible.
Abrupt removal of features that fall just outside their particular
use-case, without taking other, be they minority, use-cases into
account, looks at least inconsiderate if not outright hostile.
Is there an up and running Let's Encrypt alternative root for client
cert issuance that non-web-server ACME clients (dual-rôle servers) can
use instead?
> Does Google's change break previously-working use cases?
Yes. Let's Encrypt intermediate issuers no longer vend EE certs with a
"clientAuth" EKU.
> I think perhaps what is desired is a policy that WebPKI root CAs (the
> ones in browsers' default trust anchors) should only issue intermediate
> CA certificates that only issue certificates with:
>
> - empty DN
>
> - dNSName SANs
>
> - no other SANs of any other kind
>
> Then allowing clientAuth would be well enough, I suppose.
That may be sufficient for most of the relevant use-cases, but
are Google and the CA/B Forum willing to budge from the present
"get yourself another !@#$%^& PKI" position?
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
