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

[Andrei Popov <[e-mail]>]

  *   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…?
It’s a worthy problem to solve, but the “easy answer” only sounds good in theory.


  *   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.
Also sounds OK in theory; in practice we get security incidents where TLS servers trust client certs issued by any root out of hundreds in their TRP. This might be OK in some scenarios, but I’m not sure what these scenarios are.

Cheers,

Andrei

From: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Sent: Wednesday, April 1, 2026 12:08 PM
To: Andrei Popov <[e-mail]>
Cc: Tls <[e-mail]>; [e-mail]
Subject: Re: [EXT] [lamps] Re: [EXTERNAL] [TLS] Re: Re: Re: Re: TLS Client Certificates; a survey

> 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]<mailto:pgut001=[e-mail]>>
Sent: Wednesday, April 1, 2026 3:02 AM
To: David Adrian <[e-mail]<mailto:[e-mail]>>; Mike Ounsworth <[e-mail]<mailto:[e-mail]>>
Cc: Salz, Rich <rsalz=[e-mail]<mailto:rsalz=[e-mail]>>; Tls <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [TLS] Re: [lamps] Re: Re: Re: TLS Client Certificates; a survey

David Adrian <[e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Spasm mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>