[DI] Use interruptible sign/verify in X.509 & TLS

[mpg]

PSA recently gained interruptible functions for signing and verifying hash-based signatures. So far, these functions are not used by X.509 or TLS, but they should be used when MBEDTLS_USE_PSA_CRYPTO enabled, in all places that currently support restartable operations using the legacy API (that's currently just 1.2 with the ECDHE-ECDSA key exchange, including client authentication), in order to avoid feature gaps in PSA-based builds.

This task is to investigate how to achieve that goal, and break the work down in reasonnably-size and testable steps.

Note: execution of the work will probably depend on https://github.com/Mbed-TLS/mbedtls/issues/7029

[mpg]

I've just been thinking: since the keys are held as PK contexts in X.509 and TLS so far, and those modules always use PK functions to operate on them (even when USE_PSA_CRYPTO is enabled), perhaps the easiest way to achieve what we want is to extend mbedtls_pk_verify_restartable() and mbedtls_pk_sign_restartable() so that they use the PSA interruptible API under the hood when USE_PSA_CRYPTO is enabled. That way absolutely no change to X.509 or TLS is needed.

This would probably involve providing an alternative definition of the type mbedtls_pk_restart_ctx when USE_PSA_CRYPTO is enabled, as well as providing PSA-based implementations of ecdsa_verify_rs_wrap and ecdsa_sign_rs_wrap when USE_PSA_CRYPTO is enabled.

[mpg]

Alternatively, as a completely different strategy, we can leave PK alone and instead change the TLS and X.509 code to:

• create a PSA key from the PK context they have, using the newly introduced mbedtls_pk_import_into_psa(),
• and then directly call PSA API functions on that PSA key.

I'm not sure which one is best. Perhaps changing PK is easier in the short term, but leaving it out of the equation is better in the long term?

[gilles-peskine-arm]

In general I think pk is a good abstraction layer between X.509/TLS and crypto, and I think it can stay around for a while. I'd like to change some things about it in an incompatible way (in particular, make its concept of mechanism match the one in PSA), but I don't feel any need to remove it. Especially not until we have PSA functions to replace parse/write.