On Thu, Apr 02, 2026 at 02:15:32PM +0300, Ilari Liusvaara wrote:
> On Wed, Apr 01, 2026 at 02:55:24PM -0700, Eric Rescorla wrote:
> > WARNING: Potentially bad idea ahead.
> >
> > With that said, I think that there are two qualitatively different
> > scenarios when mutual TLS authentication is used:
> > [...]
>
> It seems to me that there is a difference in the way server
> authenticates the client in the two cases:
>
> - In the asymmetric case, the server authenticates the client via the
> subject and/or various custom extensions. Or even by the SPKI.
> (Leaving cases of CWE-284 aside.)
>
> - In the symmetric case, the server has a reference name for the client
> and authenticates client via that name appearing in SAN.
In both cases where using _naming_ there is (should be!) an
authorization function. They are not that different.
> > 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.
>
> One could scope that to just allowing using SAN for authentication in
> serverAuth certificates. That should cover all the cases where using
> WWW certs isn't Bad Idea anyway (XMPP, SMTP and similar stuff).
dNSName SAN certs was clearly part of the scope of EKR's proposal, which
is really just normalizing the outcome of the survey.
I'm coming around to this as the best option given Peter's response to
me explaining a vulnerability that the new policy does fix.
Nico
--
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
