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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

> So what actual problem was disallowing clientAuth intended to solve?
I would invert this: what problem does a public CA-issued client cert solve? 


That is easy to answer: a public CA-issued cert is supposed to contain authenticated (and verified by that CA) attributes of the owner of the corresponding private key, that allow the entity (e.g., a public/official/whatever server) that received that certificate, to apply a meaningful authorization policy to the request this client made. 


If you don’t think the above is a valid/worthy problem to solve — feel free to speak up; or if you think there are other “worthier” problems…?


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?


As was mentioned here before, this question is disingenuous. Any sane TLS server would have a policy that tells what CAs to trust, and what to allow to incoming clients authenticated by certs issued by those CAs. 


-----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]