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
