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.
Russ > On Apr 1, 2026, at 2:52 PM, 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
