[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Nico Williams <[e-mail]>]

On Tue, Jun 17, 2025 at 02:16:19PM -0400, David Benjamin wrote:
> (As always, wearing an individual hat here. In particular, I am *not*
> speaking on behalf of the Chrome Root Program.)

Can we somehow inquire as to the Chrome Root Program's rationale for
this change?  What alternatives were considered?  Was backwards compat
considered in making this change?  Is the program open to alternatives?

The links you listed help, but they do not fully elucidate.  I have
questions below.  Specifically the links you listed show that the
concern is indeed applications with bad trust anchor defaults (i.e., the
WebPKI roots) that use name forms other than dNSName (e.g., rfc822Name,
for S/MIME), which matches my speculation elsewhere in this thread.

What is not clear to me is why a slightly different policy would not be
acceptable that also limits the breakage caused by this change.

The slightly different policy I'm proposing is that the WebPKI CAs
should not issue any certificates with any name forms other than
dNSName, and that they must have either or both of clientAuth and
serverAuth EKUs.

The reasons I'd prefer such a policy are:

 - I don't see how PKIs for dNSName client certs would function
   differently than WebPKI CAs do for dNSName server certs!

   Therefore it follows that the two could and even should be the same
   PKIs.

 - There exist protocols that are fairly symmetric, such as SMTP (TURN)
   and others.  I don't see what value anyone gets from making the
   entities playing the TLS client role in those should use different
   PKIs than from the same entities playing the TLS server role.

 - Such a policy would not break current uses of WebPKI-issued EE
   dNSName client certs.  This relates to the previous item.

> This draft is not the way to solve this problem.

I agree, but I want to explore the policy change that motives it and
potential alternative policy changes that mitigate the motivation for
OP's I-D.

> As for PKI hierarchies, the Web PKI, as curated by web clients,
> authenticates web servers. All the policies and expectations around it,
> from monitoring to domain validation to Certificate Transparency, are
> maintained with web servers in mind. [...]

I would say that "As for PKI hierarchies, the Web PKI, [...],
authenticates machine FQDNs".  More specifically I would say that the
WebPKI does not certify any other name forms than dNSName.

Do you disagree?

Rephrased: is there any reason that the WebPKI cannot certify
dNSName-only certificates for _clients_?

What really differs between a certificate for dNSName foo.bar.example w/
serverAuth and dNSName foo.bar.example w/ clientAuth besides the EKUs?
Is `foo.bar.example` not the same entity either way?

If prior to this change the WebPKI could be said to not be able to
reliably certify dNSName clientAuth certs then I would agree with the
policy change.  But if so I'd like to understand why the WebPKI could
not reliably certify dNSName clientAuth certs.

> That is not to say that backend services shouldn’t authenticate as TLS
> clients with certificates. If a backend service needs to take the role of a
> TLS client, a certificate from some PKI is a fine way to solve that. But
> there is no reason for that to use the same PKI hierarchies as web server
> authentication. [...]

I really want to understand why the WebPKI cannot authenticate _clients_
w/ _only_ dNSName SANs.

You are making the assertion, but I don't understand the rationale, and
there must be one, and it might well become obvious when you lay it out.

>          [...]. You could use entirely private hierarchies, hierarchies
> shared across a large class of applications (e.g. all of S/MIME), or
> anything in between. As noted elsewhere in this thread, and in the
> references you linked, this is the standard way you build applications with
> TLS and X.509:

I am not sure that a PKI for rfc822Name-named client entities would be
appropriate for dNSName-named client entities.  If anything I'm sure of
the opposite.

ISTM that for dNSName-named client entities there is no better way to
identify and authenticate those entities to the issuing CAs than... the
same mechanisms we use now for dNSName-named _server_ entities.

If a PKI for dNSName-named client entities would work no differently
than the WebPKI does for dNSName-named server entities then I want to
understand why not use the WebPKI for dNSName-named client entities.

My suspicion is that the Chrome Root Program's motivation for this
change was indeed name forms other than dNSName ones, and that with the
bathwater out went the baby.

Nico
--