EC J-PAKE 1: create ad-hoc KDF for TLS 1.2

[mpg]

Context: RFC 8236 says the shared secret K (an EC point in case of EC J-PAKE) needs to be passed to a KDF chosen by the application, which is reflected quite nicely in the psa_pake_get_implicit_key() API that passes (serialized) K to a KDF operation.

Now, use in TLS requires us to compute SHA256(K.X) and that's the output from EC J-PAKE that the rest of TLS uses to derive session secret (the PMS in TLS 1.2 parlance). In the abstract, this absolutely fits the framework from RFC 8236, with the KDF being K -> SHA256(K.X). However, in practice that's not a standard KDF and not one PSA knows about, so right now we can't create a psa_key_derivation_operation_t with it to pass to psa_pake_get_implicit_key().

This task is to create an ad-hoc KDF algorithm PSA_ALG_TLS12_ECJPAKE_TO_PMS (or a better name) just like we already have PSA_ALG_TLS12_PRF and PSA_ALG_TLS12_PSK_TO_MS.

• [x] Declare and document it in the include/psa/crypto_sizes.h and include/psa/crypto_values.h
• [ ] Have this part side-ported to the PSA repo (most probably by pinging Gilles) where it will be reviewed by PSA folks, then integrate any changes from the PSA side back on the Mbed TLS side.
• [x] Implement this KDF in software. It will take as input a serialized point in uncompressed form (that's what psa_pake_get_implicit_key() passes to it), extract the serialized X coordinate (bytes 1 to 32 inclusive) and compute the SHA-256 of that. It only needs to work on P-256 (that is, 65-bytes input).

See also: #5904 "Check list for implementing a new mechanism in PSA crypto"

Follow-up: #5847

[AndrzejKurek]

Should we also add tests that check the computed output, similar to PSA key derivation: TLS 1.2 PSK-to-MS, SHA-256? Any other tests?

[mpg]

Should we also add tests that check the computed output, similar to PSA key derivation: TLS 1.2 PSK-to-MS, SHA-256? Any other tests?

The set of tests you added in #6115 looks right to me.