I have no stake in this fight, as my CAs will do whatever’s appropriate for our use cases, regardless.
But for mTLS, when both client and server expect to authenticate each other via certificates — what KU/EKU is the client’s certificate supposed to have, to ensure it is allowed to authenticate a TLS client? And why the asymmetry (no pun intended) — server does provide a use-case-specific EKU, but a client doesn’t??? -- V/R, Uri From: David Adrian <[email protected]> Date: Tuesday, March 31, 2026 at 20:01 To: Mike Ounsworth <[email protected]> Cc: Nico Williams <[email protected]>, David Benjamin <[email protected]>, Salz, Rich <[email protected]>, Tls <[email protected]>, [email protected] <[email protected]> Subject: [EXT] [lamps] Re: [TLS] Re: Re: TLS Client Certificates; a survey This Message Is From an External Sender This message came from outside the Laboratory. > > Does the IETF have a Liason to the Chrome Root Program? > > + @David Benjamin and @David Adrian both participate in IETF. Speaking for the Chrome Root Program [1], the policy does not introduce a blanket prohibition on all CAs from issuing TLS certificates containing both clientAuth and serverAuth EKUs. Rather, after March 15, 2027, the Chrome Root Store will, by default, only include anchors representing serverAuth-only hierarchies. This does not preclude CAs from: - Continuing to issue from hierarchies that may be trusted elsewhere - Issuing clientAuth certificates from a new hierarchy Nothing also stops non-Chrome clients from altering the content of their trust stores to trust CAs relevant to their use case. History has taught us that commingling PKI use cases causes more harm than good. It is a consistent security problem when PKI hierarchies intended for public web sites get entangled in non-web use cases. As an example, such behavior slowed the deprecation of SHA-1 in 2018 because payment card terminal implementations and their corresponding root stores could not be updated. The plan to move to serverAuth only was first communicated to CA Owners at a CABF meeting in 2021 [2]. It is designed to prevent more situations like the one above from happening in the future. [1]: https://googlechrome.github.io/chromerootprogram/#introduction <b8ecfe8e-c6b0-4d98-a527-5e39faeb9ac7> [2]: https://drive.google.com/file/d/1pwhslUTqqkJci84nzyP4jUEmop4MeSVP/view <8e4a7a14-40d6-44ad-b876-a87b20adef04> On Mon, Mar 30, 2026 at 4:53 PM Mike Ounsworth <[email protected] <2eed0562-4e3c-41ca-a0da-9b4826adc12d>> wrote: > Does the IETF have a Liason to the Chrome Root Program? + @David Benjamin <772192e8-0ae1-4d55-a7d3-0d8558343eac> and @David Adrian both participate in IETF. On Mon, 30 Mar 2026 at 15:40, Nico Williams <[email protected] <aa796e94-2468-457f-853b-b5c3feef1d2e>> wrote: On Mon, Mar 30, 2026 at 08:04:54PM +0000, Salz, Rich wrote: > The overwhelming response (strong consensus) — both posted and via > private replies — is that applications will just switch to > TLS-Server-Auth identities for the client side. That violates RFCs 5280 & 8446 and vitiates the Chrome Root Program's new policy. Whatever problem that policy change meant to addres might only be made worse by this approach (sure, only for those apps that implement this workaround, but for those, yes, it will be worse). There has to be a better way. Does the IETF have a Liason to the Chrome Root Program? Can we reach out to them and ask them? When I did they simply did not respond, but if the IETF TLS and/or LAMPS WG chairs, or IETF Security ADs reach out to them perhaps they'll respond -- failing that then maybe the IETF Chair or the IAB. Nico -- _______________________________________________ Spasm mailing list -- [email protected] <cbbbea6d-891e-42ae-af1b-c4a38615c070> To unsubscribe send an email to [email protected] <aa8e755b-acd1-428f-be0a-2b6c48f764db> _______________________________________________ TLS mailing list -- [email protected] <e5e25659-c889-492f-b116-3efa3dfc80f1> To unsubscribe send an email to [email protected] <524c1d73-3023-417c-ad68-b0007292f0af>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
