Server will always sign CertificateVerify with last given SignatureScheme in ClientHello

[oweisse-msft]

1. Client is configured to support several algorithms via FFI_mitls_configure_signature_algorithms.
2. Server is loaded with a private key and certificate via
   • _FFI_mitls_configure_cert_chainfile,
   • _FFI_mitls_configure_private_keyfile,
   • _FFI_mitls_configure_cafile
3. Client sends in ClientHello "signature_algorithms" extension, listing all the supported algorithms configured in step 1
4. Regardless of the type of key and hash algorithm configured for the server, the CertificateVerify will always have SignatureScheme set to the last one in the list given by the client. This means that the CertificateVerify may be illegal, if the last algorithm in the list is actually different than the key used by the server. This fails the inter-operability tests with NSS client.
5. Calling _FFI_mitls_configure_signaturealgorithms in the server, with a list containg the right key type and hashing algorithm solves this, and interop tests with NSS are OK. While this solves the issue, it is not clear that code configuring a server should do this, as _FFI_mitls_configure_signaturealgorithms seems to be a client-config function. For comparison, in OpenSSL there is no need to call SSL_CTX_set1_sigalgs_list on the server side, as it will infer the algorithm from the certificate.

While https://github.com/mitls/mitls-fstar/issues/180 describes an issue in the client (accepting malformed CertificateVerify), this issue describes a potential problem in the server.

[ad-l]

The real bug here is that we used to reverse the client's preference when we parse the list of signatures.