On Tue, Oct 16, 2018 at 08:13:11AM +0200, Jakob Bohm via openssl-users wrote: > > As for the 16K limit, and whether we should be sending client > > CA names without further indication from the (TLS 1.3) client > > to do so, I'm hoping Matt Caswell and or other team members > > will chime in. > > Just for clarity, how is an OpenSSL 1.1.1 client supposed to tell > the local validation code which CAs to trust, especially if loading > the list before entering a chroot jail? Loading CA files is not a problem in itself, the issue is that some (typically server) applications overload the CAfile as also being the source of CA hints to clients in certificate requests. This creates bloated server certificate request messages. With TLS 1.3, this is further compounded in applications that are *both* a server and client, and use the *same* context for both purposes. Once that happens, the CA hints are used in both directions. > How is this different from the OpenSSL 1.0.x API? The API is identical, what's different is that TLS 1.3 makes the CA hints bidirectional, given such hints have never been useful before, it is IMHO just needless generality that's counter-productive. Perhaps OpenSSL should require an additional non-default configuration to enable transmission of the client's CA DNs to the server. Or perhaps separate the server->client and client->server CA name lists in the SSL context, so that setting one does not (surprise!) also set the other. Overloading the same setting for both directions may not have anticipated bidirectional use of contexts. Someone should perhaps open an issue to track whether anything needs to change here beyond advice to users, and if so what. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
