> 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 <[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]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
