Generalize mbedtls_pk_setup_opaque to MBEDTLS_PSA_CRYPTO_CLIENT

[gilles-peskine-arm]

Extend mbedtls_pk_setup_opaque to provide support for MBEDTLS_PK_OPAQUE whenever PSA crypto API functions are available, i.e. whenever MBEDTLS_PSA_CRYPTO_CLIENT is enabled, regardless of the status of MBEDTLS_USE_PSA_CRYPTO.

For testing, we assume MBEDTLS_PSA_CRYPTO_C, since the case of MBEDTLS_PSA_CRYPTO_CLIENT without MBEDTLS_PSA_CRYPTO_C is currently untested and not officially supported.

See docs/architecture/psa-migration/psa-legacy-bridges.md (from https://github.com/Mbed-TLS/mbedtls/issues/7760) for some background.

Definition of done:

• The relevant library code and the declaration in pk.h are gated by MBEDTLS_PSA_CRYPTO_CLIENT instead of MBEDTLS_USE_PSA_CRYPTO.
• The unit tests for the function are enabled whenever MBEDTLS_PSA_CRYPTO_C is enabled.
• This may involve writing additional unit tests if the coverage is deemed insufficient according to the implementer and reviewers.

Related, but should in principle be independent: https://github.com/Mbed-TLS/mbedtls/issues/8712

[gilles-peskine-arm]

@mpg notes that if we do that, all.sh test_psa_crypto_client won't work anymore, since we'll be missing some functions at link time. The only thing we'd be able to do with CLIENT && !C would be make lib.

[mpg]

I'm also suggesting we grep the generated libmbedtls.a in order to ensure mbedtls_pk_setup_opaque() is indeed present.

[gilles-peskine-arm]

Idea to be explored: we prepare and test two client-only scenarios:

• MBEDTLS_PSA_CRYPTO_CLIENT && !MBEDTLS_PSA_CRYPTO_C && !MBEDTLS_USE_PSA_CRYPTO → can link everything, but some legacy-psa bridge functions are not available. Note that “everything” is default config minus LMS only, i.e. what we're currently testing in component_test_psa_crypto_client. Other stuff (especially LMS and TLS 1.3) need PSA functions.
• MBEDTLS_PSA_CRYPTO_CLIENT && !MBEDTLS_PSA_CRYPTO_C && MBEDTLS_USE_PSA_CRYPTO → all legacy-psa bridge functions are available, but can't link due to missing implementation of some PSA functions. We try compiling with everything (full config, minus ad hoc exceptions if needed), and check that certain functions are present in the build.

[valeriosetti]

Idea to be explored: we prepare and test two client-only scenarios:

Since I need the same test case also for #8709 (PR #8774) I'm planning to add this testing support there since it's already ongoing. This issue will be started on top of that for simplicity.

Very late edit: as suggested by @mpg I'll implement test components here instead of #8774 in order to keep that PR simpler (it already includes a good amount of changes...)

[valeriosetti]

#8797 seems to implement some changes to check_config.h that are interesting for the test components proposed above. I think that PR will be a prerequisite for the one aimed at solving this issue.

[gilles-peskine-arm]

We have abandoned opaque PK support without USE_PSA_CRYPTO as a feature in 3.6.