On Tue, Mar 24, 2026 at 7:20 PM Viktor Dukhovni <[email protected]> wrote:
> On Tue, Mar 24, 2026 at 06:36:16PM -0700, Wei Chuang wrote: > > > > what's gmail currently doing? I don't run mail server so I don't know > > > what cert it sends for smtp > > > > Currently for SMTP-IN TLS, Gmail publishes an entity TLS certificate > > w/ serverAuth only EKU, and for SMTP-OUT, publishes serverAuth and > > clientAuth EKUs. > > 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. > Postfix SMTP-IN servers > do not request client credentials (certificates and/or raw public keys), > and by default and in the majority of configurations Postfix SMTP-OUT > servers do not present clientcrdentials, even if the server happens to > ask. I expect the same is true in Exim. > > > Due to the policy change noted in this thread, we will move to serverAuth > > only EKU for both SMTP-IN and OUT. > > Well, that policy change rules out use of WebPKI certificates (perhaps > more precisely those issued by CAs in the Chrome root programme) in the > SMTP-OUT direction. Any "serverAuth"-only certificate presented by an > SMTP client (SMTP-OUT MTA), violates the express key purpose of the > certificate, and should (barring optional work-arounds along the lines > of the patch I posted) result in the certificate failing validation. > > 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. Since clientAuth will soon be unavailable, serverAuth is the closest fit for SMTP-OUT certificates. Further, clientAuth certificates for the most part lack governance behind their content (besides closed ecosystems like X9), so beware. > > FWIW we've started a small pilot deployment of serverAuth only for > > SMTP-OUT and saw a few domains that returned a SMTP 5xx error. We're > > trying to reach out to them to understand what in their configuration > > is causing this. > > Well, if they: > > 1. Only accept traffic from Gmail when the SMTP client presents > a "valid" (chaining to a trusted CA) certificate. > 2. Use a typical TLS software stack that checks at least the EE > EKU extension. > > then of course they'll refuse to accept the presented credentials. > > > I also wanted to note a closely related CABF [email protected] > > thread "Client Authentication - Initial investigation > > < > https://groups.google.com/a/groups.cabforum.org/g/public/c/Kna_osq-6F8?e=48417069 > >" > > as I think several of the CAs are asking very similar questions > > concurrently. In particular Ryan Hurst noted in that thread that there > is > > a very important distinction for client certificates between "human > > identity" and "machine/service identity" uses, which may simplify or > > descope some of the problematic aspects of client certificates. > > Furthermore, it sounds like some of the CAs in the CABF are thinking > about > > a WG for Client Authentication. > > 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
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
