On Tue, Mar 31, 2026 at 08:00:21PM -0400, David Adrian wrote: > > > Does the IETF have a Liason to the Chrome Root Program? > > Speaking for the Chrome Root Program [1], the policy does not introduce a
Thanks for _finally_ responding. I don't mean just "in this thread". > 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. "Only", and yet the net effect on the Internet -meaning Internet Standards, and the IETF standards process, but also the market for Internet-related services and products- has been disruptive and negative. For example, this and other threads have taken a fair bit of our time. For another the disappearance of a valuable product/service. > This does not preclude CAs from: > - Continuing to issue from hierarchies that may be trusted elsewhere > - Issuing clientAuth certificates from a new hierarchy The net effect appears to have been to drive all CAs that used to issue client certificates to no longer do so under _any_ root, not just the ones in Chrome's trust anchor store. Or are there any CAs that do issue client certificates that I don't know about? For SMTP and XMPP users are specifically interested in client certificates with dNSName SANs. Are there any organizations that have ACME-style dNSName SAN clientAuth EE cert issuance? I believe hte answer is "no", but please disabuse me of that. When CAs stop providing a valuable service to the market on account of the Chrome Root Program policy change, then that policy has damaged the market. (If there was no way to securely provide that service, then certainly everyone would agree that ending that service was the correct thing to do, but _that_ proposition has not been made and is not in evidence.) When implementors race to allow clients to use certificates with only serverAuth, the Chrome Root Program policy has damaged the Internet and the policy has backfired. We now have CAs in browsers' trust anchor set that unwittingly issue client certificates because implementors are removing the check for clientAuth -- surely this is the inverse of what the program wanted. To be fair I can't say yet whether _some_ applications accepting serverAuth certs as client certs is a particularly bad outcome or a tolerable one. If it's just MTAs and XMPP servers, then maybe it's tolerable. The problem is that we don't know what more applications will be affected, and we don't know whether this change will infect TLS implementation libraries in ways that expose even more applications. But what bothers me the most about this policy is that it obviously had a high potential to make changes to RFC 5280 without the IETF approving those changes. The moment people suggested accepting serverAuth certs as client certs is the moment the program should have rethought the policy and sought to discuss it here or at the IAB at minimum. You should reconsider your policy. And in the future please be more responsive. Some of us tried to contact the program about this policy long ago and never got even the courtesy of a non-answer response. > Nothing also stops non-Chrome clients from altering the content of their > trust stores to trust CAs relevant to their use case. This is non-responsive. If your policy has caused there to be no public CAs that will issue these certificates, then that's a problem. > 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. That example cannot motivate this change. Do you have a better example? Changes of this magnitude should require discussion, and not just between a closed group. Near as I can tell there was no way for the public to comment. I don't see how the IAB, IESG, or IETF can possibly accept the program's policy change or the program's behavior in light of this survey's result, and I do not think they would have accepted it had they (we, in the case of the IETF) been asked. > 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. The CA Owners are not the public, and [2] is not public notice. But thanks for pointing out that you've been trying to make this happen since 2021: that means that the policy change and the program's earlier silence on it could not have been motivated by an urgent need to fix some serious vulnerability since enough years have passed that it could have been fixed. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
