On Fri, Jun 20, 2025 at 04:16:57PM +1000, Viktor Dukhovni wrote: > On Thu, Jun 19, 2025 at 10:04:47PM -0500, Nico Williams wrote: > > Does Google's change break previously-working use cases? > > Yes. Let's Encrypt intermediate issuers no longer vend EE certs with a > "clientAuth" EKU.
Weird. Let's Encrypt could tell Google to take a hike on this and Google would abandon their position. So why is LE going along? Do they know more about Google's rationale, or did they not realize it was going to break real use-cases? (I take LE's prior issuance of EE certs with clientAuth and dNSName SANs as evidence of actual use of such certs.) > > 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? We'll see. But without knowing the rationale for Google's position we're left to speculate as to that rationale and possible alternatives. My speculation is that the rationale has to do with client certs with name forms other than dNSName SANs and that Google overreacted. But perhaps there is more to it. Can we ask LE? Nico -- _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
