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

[Jeffrey Walton <[e-mail]>]

On Wed, Apr 1, 2026 at 6:45 PM Nico Williams <[e-mail]> wrote:
>
> On Wed, Apr 01, 2026 at 02:55:24PM -0700, Eric Rescorla wrote:
> > WARNING: Potentially bad idea ahead.
> >
> > id-kp-serverAuth is actually defined for "TLS WWW server
> > authentication", so ISTM that using it for an SMTP server is actually
> > already not really conforming to the Extended Key Usage requirements
> > in RFC 5280. I'm not as familiar with the specifications for SMTP and
> > XMPP, but AFAICT they don't update RFC 5280 to expand the meaning
> > of serverAuth.
>
> Which is why I was suggesting new EKUs, but yeah, deploying new EKUs for
> existing protocols is not easy.
>
> > [...]
> >
> > Given that using certificates with {client,server}Auth in these
> > other protocols is already off the fairway, it seems like we could,
> > if we wanted, clarify matters by (1) explicitly permitting
> > serverAuth in these protocols and (2) stating that for at
> > least some of them, server-to-server connections needed the
> > TLS client to have a serverAuth certificate rather than
> > (or more likely in addition to) a clientAuth one, but with
> > serverAuth preferred going forward.
> >
> > This may well be a bad idea, and people should definitely feel
> > free to say so, but it seems like at least one potential
> > way out of this mess, given that we know that a lot of
> > endpoints are going to do this in any case.
>
> Ironically this _could_ be a bad idea if the Chrome Root Program policy
> change was a good idea, unless there is something about this use case
> that elides whatever problems there were with clientAuth cert issuance
> by WebPKI CAs.
>
> On the other hand, this could be a desirable change anyways.  Which
> would also be ironic given my complaints about ending up here (but my
> complaints are about process or lack thereof).
>
> To take this proposal seriously -which we should- we need to understand
> the vulnerabilities that the Chrome Root Program policy change was meant
> to prevent.  So far we've not seen a reference to a single CVE.
>
> But also: how much does this differ from changing the Chrome Root
> Program policy to say that intermediate CAs chaining to WebPKI roots can
> only issue EE certs with clientAuth when they have only dNSName SANs
> (and either empty DNs or just CN=<FQDN>)?  Because this alternative is
> much cheaper in terms of code that needs to change.

Regarding just "just CN=<FQDN>", that's a CA/BF Baseline Requirement
(BR) violation.  A name must always appear in the SAN.  If a name is
present in the CN, then it must be duplicated in the SAN, too.

>From the CA/BF BR v2.2.6, Section 7.1.4.3 Subscriber Certificate
Common Name Attribute:[0]

    If present, this attribute MUST contain exactly one entry that is one
    of the values contained in the Certificate’s subjectAltName extension
    (see Section 7.1.2.7.12). The value of the field MUST be encoded as
    follows...

[0] https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.2.6.pdf

Jeff