On Wed, Apr 1, 2026 at 12:00 PM Russ Housley <[email protected]> wrote:
> Andrei:
>
> To protect a connection between two SMTP servers with TLS, one certificate
> should have cliantAuth and the other should have serverAuth. The simple
> solution is for both certificate to have both cliantAuth and serverAuth. so
> that either SMTO cserver can start the TLS session. While this is not the
> WebPKI, the Internet email system is not a private PKI. It seems like the
> proposed policy is forcing such certificates to be under a separate root.
>
Hi Russ,
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.
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.
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.
-Ekr
[0] Ignoring for the moment that the server may also connect to
other servers as in a CDN.
> Russ
>
> > On Apr 1, 2026, at 2:52 PM, Andrei Popov <Andrei.Popov=
> [email protected]> wrote:
> >
> >> So what actual problem was disallowing clientAuth intended to solve?
> > I would invert this: what problem does a public CA-issued client cert
> solve? When is it OK for a TLS server app or service to trust every client
> cert issued by an arbitrary root in a SW vendor's TRP?
> >
> > Cheers,
> >
> > Andrei
> >
> > -----Original Message-----
> > From: Peter Gutmann <[email protected]>
> > Sent: Wednesday, April 1, 2026 3:02 AM
> > To: David Adrian <[email protected]>; Mike Ounsworth <
> [email protected]>
> > Cc: Salz, Rich <[email protected]>; Tls <[email protected]>;
> [email protected]
> > Subject: [EXTERNAL] [TLS] Re: [lamps] Re: Re: Re: TLS Client
> Certificates; a survey
> >
> > David Adrian <[email protected]> writes:
> >
> >> History has taught us that commingling PKI use cases causes more harm
> >> than good. It is a consistent security problem when PKI hierarchies
> >> intended for public web sites get entangled in non-web use cases. As an
> >> example, such behavior slowed the deprecation of SHA-1 in 2018 because
> >> payment card terminal implementations and their corresponding root
> >> stores could not be updated.
> >
> > So what actual problem was disallowing clientAuth intended to solve? I
> can't imagine any situation where doing this is a good thing, but as others
> have pointed out there are numerous situations where it's a bad thing.
> >
> > Also, for users of said certs, is the eKU in them critical or not? Its
> usage has changed over time from the original "non-critical = advisory
> only, used to select the right certificate" to the more recent "both
> non-critical and critical are to be treated as per the critical text". I'm
> not sure if this newer interpretation was a unilateral decision on behalf
> of the RFC authors (it looks like the non-critical text portion just got
> dropped from the doc) but when PKIX debated it there was, as was typical
> for PKIX, a 50:50 split as to whether it was strictly enforced or advisory
> only.
> >
> > Peter.
> > _______________________________________________
> > TLS mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > _______________________________________________
> > Spasm mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> Spasm mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
