[lamps] Re: TLS Client Certificates; a survey

[Nico Williams <[e-mail]>]

On Tue, Mar 24, 2026 at 03:15:59AM +1100, Viktor Dukhovni wrote:
> On Mon, Mar 23, 2026 at 10:58:49AM -0500, Nico Williams wrote:
> > Is this for SMTP ETRN?
> 
> No, [...]
>                               [...].  Rather it is mostly for policy
> servvice callouts, which get to see the issuer and subject CNs only when
> the certificate chain is trusted.
> 
> Access control by public key or certificate fingerprint is independent
> of PKI trust.
>
> But my long answer was not really intended to digress into SMTP access
> policy discussions.  Rather, it was an opportunity to give some context
> to a workaround that others may find useful in their applications, if
> the use-case warrants going there, rather than (generally better)
> rethinking whether relying on a third-party CA is the right way to
> handle client certs.

I've been imagining a TLS extension that includes details on how to
connect to a service that will have the same server certificate (or
substantially similar: same names and issuer) as the one being presented
as a client certificate (with serverAuth and not clientAuth).  Then the
server can connect, verify that the "client's server" has the same (or
substantially similar) certificate as the client and... presto: you're
using the serverAuth certificate as intended, as a server certificate! :D

The connection details extension would carry: the FQDN that the client
is authenticating as, and optionally one or more IP address and port
number pairs.

Nico
--