[TLS] Re: [lamps] [EXTERNAL] Re: Re: Re: Re: TLS Client Certificates; a survey

[Andrei Popov <[e-mail]>]

> It seems like the proposed policy is forcing such certificates to be under a separate root.
Got it, thanks Russ. Would you say that this is an inconvenience/configuration change or a blocking issue?

> While this is not the WebPKI, the Internet email system is not a private PKI.
It is unfortunate that a change intended for the Web scenarios affects unrelated use-cases. Perhaps this is where improvement can be made (although this seems to be CA/B forum territory).

Cheers,

Andrei

-----Original Message-----
From: Russ Housley <[e-mail]> 
Sent: Wednesday, April 1, 2026 12:00 PM
To: Andrei Popov <[e-mail]>
Cc: David Adrian <[e-mail]>; Tls <[e-mail]>; [e-mail]
Subject: Re: [lamps] [EXTERNAL] [TLS] Re: Re: Re: Re: TLS Client Certificates; a survey

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 <Andrei.Popov=[e-mail]> 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 <pgut001=[e-mail]>
> Sent: Wednesday, April 1, 2026 3:02 AM
> To: David Adrian <[e-mail]>; Mike Ounsworth 
> <[e-mail]>
> Cc: Salz, Rich <rsalz=[e-mail]>; Tls 
> <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] [TLS] Re: [lamps] Re: Re: Re: TLS Client 
> Certificates; a survey
> 
> David Adrian <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail] 
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]