[lamps] Re: [TLS] Re: Re: TLS Client Certificates; a survey

[Jeffrey Walton <[e-mail]>]

On Wed, Apr 1, 2026 at 1:12 PM Nico Williams <[e-mail]> wrote:
>
> On Wed, Apr 01, 2026 at 12:09:46PM -0400, Mike Shaver wrote:
> > On Wed, Apr 1, 2026 at 11:08 AM Nico Williams <[e-mail]> 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.

This may be relevant:  "A very useful approach for a cartel or an
industry group" (25 January 2024),
<https://mailarchive.ietf.org/arch/msg/ietf/b_-fmgHnnR5_S4wKUvutk99JiEg/>.
And the link to the pdf:
<https://www.ietf.org/media/documents/2023.01.26_Correspondence_IETF.pdf>.

Jeff