[lamps] Re: TLS Client Certificates; a survey

[Wei Chuang <[e-mail]>]

I apologize for my late reply to this thread and this question.

On Mon, Mar 23, 2026 at 6:18 PM Seo Suchan <[e-mail]> 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.

Due to the policy change noted in this thread, we will move to serverAuth
only EKU for both SMTP-IN and OUT.   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.

I also wanted to note a closely related CABF [e-mail]
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.

-Wei


> 26. 3. 24. 03:09에 Nico Williams 이(가) 쓴 글:
> > On Mon, Mar 23, 2026 at 02:00:35PM -0400, Michael Richardson wrote:
> >> Salz, Rich <rsalz=[e-mail]> wrote:
> >>        > Since WebPKI CA’s will not be able to issue TLS-Client
> certificates,
> >>        > what are the customers and CAs thinking of doing?
> >>
> >> You say this as if it's a new thing :-)
> > well, it's recent.  It happened around October 2025.
> >
> >> Is it the "change" that certificates obtained for code signing or email
> use
> >> will have the tls-kp-clientAuth EKU ommitted?
> > The change is that roots in the Chrome Root Program may not sign
> > intermediates that sign any EE certificates having any EKUs other than
> > id-kp-serverAuth.  A CA can still have roots outside the CRP that do
> > sign intermediates that do sign non-server EE certificates, but probably
> > few will.
> >
> >>      > Replies to be will be summarized to both lists. Please be
> careful if
> >>      > you use reply-all.
> >>
> >> 1. This assumes the RP are checking EKU.
> > Yes, but they should.
> >
> >> 2. I think 94% of usage of mTLS is via private PKI for the client side.
> > Probably true.  The two applications I know to be affected are XMPP and
> > SMTP.
> >
> > Nico
>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>