On Thu, Jun 19, 2025 at 11:51:54AM +0200, Filippo Valsorda wrote: > 2025-06-19 09:52 GMT+02:00 Viktor Dukhovni <ietf-d...@dukhovni.org>: > > 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). > > 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 - use WebPKI trust anchors by default just because - support no naming constraints whatsoever - use certificate subject distinguished names (typically only the CN attribute) - maybe support rfc822Name SANs from accepting certificates issued by WebPKI CAs that they really should not. However, I would think that apps that support client certificates only with dNSName SANs should be able to continue to work with WebPKI _if_ that's what they were already doing. Are there any such? It sounds from this thread like "yes", there are. Does Google's change break previously-working use cases? 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. Nico -- _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
