Add support for the TLS 1.3 signature_algorithms_cert extension
authorBenjamin Kaduk <bkaduk@akamai.com>
Thu, 11 Jan 2018 17:47:12 +0000 (11:47 -0600)
committerBenjamin Kaduk <bkaduk@akamai.com>
Thu, 25 Jan 2018 18:57:22 +0000 (12:57 -0600)
commitc589c34e619c8700ab16b152dd9c8ee58356b319
treea2e3f758062721c082f0d836040b80c37bad329a
parenta6419d1ed873a94bce99ae2b880885b8780d6eb9
Add support for the TLS 1.3 signature_algorithms_cert extension

The new extension is like signature_algorithms, but only for the
signature *on* the certificate we will present to the peer (the
old signature_algorithms extension is still used for signatures that
we *generate*, i.e., those over TLS data structures).

We do not need to generate this extension, since we are the same
implementation as our X.509 stack and can handle the same types
of signatures, but we need to be prepared to receive it, and use the received
information when selecting what certificate to present.

There is a lot of interplay between signature_algorithms_cert and
signature_algorithms, since both affect what certificate we can
use, and thus the resulting signature algorithm used for TLS messages.
So, apply signature_algorithms_cert (if present) as a filter on what
certificates we can consider when choosing a certificate+sigalg
pair.

As part of this addition, we also remove the fallback code that let
keys of type EVP_PKEY_RSA be used to generate RSA-PSS signatures -- the
new rsa_pss_pss_* and rsa_pss_rsae_* signature schemes have pulled
the key type into what is covered by the signature algorithm, so
we should not apply this sort of compatibility workaround.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
crypto/err/openssl.txt
include/openssl/sslerr.h
include/openssl/tls1.h
ssl/s3_lib.c
ssl/ssl_err.c
ssl/ssl_locl.h
ssl/statem/extensions.c
ssl/statem/extensions_srvr.c
ssl/statem/statem_clnt.c
ssl/statem/statem_locl.h
ssl/t1_lib.c