On Wed, Mar 25, 2026 at 12:41:09AM -0700, Wei Chuang wrote:
> > I am very surprised to hear that Gmail presents client credentials in
> > the SMTP-OUT direction? Why is this done?
>
> We observed that for 38% of outbound messages, the server requests client
> the certificates.
Sure, but that alone does not mean you have good cause to oblige, and in
fact provider a client certificate. Do you have specific evidence these
are actually needed in enough cases to warrant their use?
The same 38% of servers surely also request certificates from all the
other MTAs that send them email, and those MTAs (often Postfix)
typically ignore the request...
> > I don't see why one might expect just sending "serverAuth" certificates
> > as a TLS client would be expected to work, except by prior arrangement
> > with specific servers known to tolerate this, or those that do not
> > actually validate CA trust in any presented client credentials.
>
> I would argue that the SMTP MTA-to-MTA traffic model differs from the
> original WWW TLS client-server model envisioned in RFC 5280, Section
> 4.2.1.12 anyways.
But those STARTTLS-capable SMTP servers use mainstream TLS stacks that
in generally support the EKU extension, and enforce the expected
semantics. Much as one might wish for a more liberal interpretation, I
am not aware of library support for that. My proposed work-around for
Postfix is just days old, and may not land in a stable release until Q1
'27, and even then would require a non-default configuration.
> Since clientAuth will soon be unavailable, serverAuth is
> the closest fit for SMTP-OUT certificates.
That's wishful thinking, it is not a "closest fit" it is not a fit at
all, i.e. not viable for use by TLS clients.
> Further, clientAuth certificates for the most part lack governance
> behind their content (besides closed ecosystems like X9), so beware.
But the prior practice was not to issue "clientAuth"-only certificates,
rather it was that "serverAuth" certificates also got an *additional*
"clientAuth" EKU in case they needed it (as some do). In fact you're
specifically suggesting exactly that, treating "serverAuth" as good
enough also for "clientAuth", but this is not currently implemented
at any case (my own Postfix server aside, where I briefly turned it
on to test).
So we now see that the Chromium Root Programme policy was likely a
tactical error, that may be doing more harm than good. Perhaps it
can be refined to state that "clientAuth"-alone must not be issued
by conforming CAs, but "serverAuth" + "clientAuth" is fine?
> > If possible, please keep us (or at least just me) apprised of any
> > substantive changes that come out of these conversations.
>
> I'm not part of those conversations. Someone pointed out those
> discussions to me, so I wanted to pass that along as I thought they
> would be relevant and help inform the conversation here. -Wei
Thanks. I guess I'll have to keep abreast of these by other means...
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
