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:
>
> - Asymmetric, with clear roles for client and server (e.g., HTTPS)
> where one endpoint is always the client and the other the server
> [0].
> - Symmetric, where each side can take on the role of client or
> server depending on the situation, as in SMTP or XMPP.
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.
> 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).
-Ilari
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
