I think that is also true for NSS, though my experience of this is not thorough. As David notes, client certificates are something of a mess once you step outside a context where the client already knows what it should be sending.
On Thu, Apr 13, 2023, at 07:20, Andrei Popov wrote: > Windows TLS stack uses them (when available) for certificate selection. > Schannel-based TLS servers don’t send CA names by default, but can be > configured to do so. > > > Cheers, > > Andrei > > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of * David Benjamin > *Sent:* Wednesday, April 12, 2023 2:16 PM > *To:* tls@ietf.org > *Subject:* [EXTERNAL] Re: [TLS] Servers sending CA names > > Chrome also uses this to filter the set of client certificates when > asking the user to pick one. We also sometimes use this to figure out > what intermediates to send, in cases where the server does not already > have all its intermediates available. (Though this is not very reliable > and OS-dependent. Client certificate deployments are a bit of a mess.) > > Omitting it may be fine in contexts where you expect clients to only > have one possible certificate chain and that they have a priori > knowledge to only send that one. That can make sense in > machine-to-machine communication, and makes less sense when the client > is a human that needs to make decisions about identities to use. > > I agree with Viktor that this isn't any more optional in TLS 1.2 than > TLS 1.3. Optional and non-empty if present vs. mandatory but may be > empty express the same set of states. It's just an encoding difference, > motivated by extensibility and client/server symmetry, not changing > client certificate expectations. > > On Wed, Apr 12, 2023 at 4:59 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: >> On Wed, Apr 12, 2023 at 08:41:31PM +0000, Salz, Rich wrote: >> >> > Is this generally used? Would things go badly if we stopped sending them? >> >> I take you mean sending CA names as part of a certificate request. >> >> https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2 >> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4 >> >> Yes, many servers send a non-empty list of CA names as part of >> certificate request, and some clients (notably some Java-based clients) >> fail to complete the handshake if the request does not list an issuer >> associated with any of the client's available certificates. >> >> So servers historically have been able to get away with an empty list, >> hoping that the client will then send the only/default certificate it >> typically has on hand (or not send any, but still continue the >> handshake). >> >> It looks perhaps like CA name lists are "more optional" in TLS 1.3 than >> they were in TLS 1.2, but this impression may be just an artefact of the >> separation of the CA names to a separate extension, rather than an >> actual change of expected client behaviour. >> >> -- >> Viktor. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
