Unit tests for mbedtls_ssl_conf_own_cert with respect to RSA policies

[gilles-peskine-arm]

Context

mbedtls_ssl_conf_own_cert() takes a PK context as argument containing a private key (as well as another argument containing the associated certificate). This key must allow the algorithm that will be used for signing the key exchange. There are subtleties with respect to which algorithm will be used for signing — this is not determined solely by the key type and the certificate, but also by details of the private key object. In a TLS server (we don't consider client signatures here):

• For ECDSA, there are two signature algorithms: deterministic or randomized. With legacy crypto, the PK module picks deterministic ECDSA if it's enabled at compile time and randomized ECDSA otherwise. With a PSA key, PK tries deterministic and falls back to randomized.
• For RSA keys, there are two signature algorithms. TLS 1.2 uses PKCS#1v1.5, and TLS 1.3 uses PSS. In Mbed TLS 3.6, the TLS code uses mbedtls_pk_can_do_ext() to determine whether the PK object can do the algorithm that is required by the protocol, then calls mbedtls_pk_sign_ext() to sign with the selected algorithm. If the PK object is backed by a PSA key, this key's policy needs to allow the algorithm(s) allowed by mbedtls_pk_can_do_ext(). If the PK object wraps an mbedtls_rsa_context, mbedtls_pk_sign_ext() just “cheats” to use whatever signature algorithm it wants.

In TF-PSA-Crypto 1.x, PK will change to always wrap a PSA key instead of sometimes wrapping a built-in context (in particular, after parsing a key with mbedtls_pk_parse_key()). Before TF-PSA-Crypto 1.0, we want to plan ahead and make sure that when we switch to full PSA, this will not break application workflows that load an RSA key and then want to use it in TLS.

See the TF-PSA-Crypto 1.0 PK specification for more background, currently the section “RSA in TLS” in Mbed-TLS/TF-PSA-Crypto#203.

Goal

The goal of this issue is to add unit tests for mbedtls_ssl_conf_own_cert(), covering the various ways in which a private key can be constructed and the policies that it can have. Note that we only care about construction methods (e.g. direct parsing vs wrapping a PSA object) and policies (on the PSA key, and on PK if relevant). We don't care about the key itself, it's fine to hard-code a single RSA key (no need to e.g. test different sizes), and it's fine to hard-code a single ECC key (no need to e.g. test different curves). Variations on the certificate are also out of scope here.

The test must try both TLS 1.2 and TLS 1.3. (It doesn't actually matter for ECDSA, but it very much does for RSA.)

There must be both positive and negative tests. Positive tests must ensure that the handshake completes successfully, and negative tests must ensure that the handshake fails due to the server not finding a matching signature algorithm. If the server thinks that the key is suitable, but then it fails to make the signature, this should result in a test failure, because it indicates something wrong in the library design. (If we discover such cases when writing the tests, we should probably file a bug.)

Notes

There is code to construct PK objects in various ways in test_suite_pk that could be moved to the framework, or adapted.

The tests are needed to validate the design of the new PK in TLS 1.0. It would make sense to backport them to 3.6, but that's not required.