On Wed, Apr 01, 2026 at 12:09:46PM -0400, Mike Shaver wrote: > On Wed, Apr 1, 2026 at 11:08 AM Nico Williams <[email protected]> wrote: > > I don't see how the IAB, IESG, or IETF can possibly accept the program's > > policy change > > Why do those groups have to "accept" the change? Do they commonly review or > require changes to browser root programs (including the Microsoft and Apple > ones which are aligned with the change to clientAuth issuance from included > roots)? I've been quite involved in WebPKI discussions and I've never > previously heard about IETF or related approval being required or even > appropriate for those programs' policies. > > Are there other elements of the policies that you think should be subject > to IETF approval?
We don't have a protocol police, true, and yes we don't care if some random implementation of TLS and PKIX allows serverAuth certs as clients, but when one actor somehow forces such a change on everyone without discussion, I think that is qualitatively different from a random implementor ignoring a MUST in an RFC in some niche use case. Certainly I think the IAB could choose to make a statement. I hope they do. I do think the Chrome Root Program's decision is forcing changes on the Internet that we did not even get a say in. The IETF should be a bit zealous about its turf. As an IETF participant myself I object to the complete lack of responsiveness to the plubic by the Chrome Root Program leading to it being able to force unwritten changes to RFC 5280 on implementors. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
