Chuck Lever III <[email protected]> writes: >We're implementing TLSv1.3 support for PSK and note there is a capability in >the PSK extension described in S 4.2.11 for sending a list of identities. We >don't find support for a list of alternate identities implemented in user >space TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for >that omission?
If it's the same as similar locations in previous versions of TLS where it's possible to specify a list of X instead of just an X then it could be because no-one has any idea why you'd specify a list of X, or what to do with it if one does turn up. There are several fields where, in the past, we've had users ask what to do with them and it turned out, after some testing, that the answer is "whatever you want" because the other side pays no attention whatsoever to what's in there. Two that spring to mind are cert requests from the server, which some servers send out for every connection even though they don't actually want a cert from the client and get very surprised if one turns up (the user's comment on this was that no other software they'd used had an issue with this, which implied that exactly zero implementations actually paid any attention to it), and CA name lists, which some servers fill up with every CA name they've ever heard of with the server not actually caring which CA gets used, assuming they even care whether they get a response to the cert request. This actually extends to all of the other fields in the cert request as well, since the client typically has one single certificate to auth with and sends it, take-it-or-leave-it, without bothering to check whether it's in the server's long list of approved signature, hash, and CA names. Again, from interop testing, if you get a cert request from the server and have a cert you use it, if not you don't, and no server we could find ever complained about it. So the entire extension is in effect one of those zero-length signalling ones, telling the client "auth with a cert if you've got one, otherwise just keep going as if nothing had happened". Peter. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
