Official bridge from PK to PSA

[gilles-peskine-arm]

There are many scenarios where it's useful to use a legacy mbedtls API to construct a private key or a public key, then a PSA API to perform operations on the key. The PSA API is the future, it's where the accelerators and secure element drivers are, and in the long term it'll be the only API to perform operations. However, when it comes to constructing a key, the PSA API is lacking in many areas.

We are planning to extend the PSA API with a PK-like layer, but until then we need to provide a transition mechanism. In terms of timeline, this transition mechanism should appear in 3.x (to give users the benefits of PSA drivers), would remain in 4.x, and would be obsoleted by the time 5.0 comes out. The PSA API extension may or may not appear in 3.x, and even if it does, it's likely that it will miss some important use cases until after 4.0.

Some example use cases that are easy or at least doable with a pk→psa conversion, but require a lot of code duplication otherwise:

• The most common one: import a key pair or public key in a standard format (PKCS1, PKCS8, SEC, SubjectPublicKeyInfo). The pkparse module provides a very convenient interface to construct a pk object. While pk does include a compability layer for cryptographic operations when MBEDTLS_USE_PSA_CRYPTO is enabled, it's often awkward to use due to the differences between the encoding of mechanisms and policies.
• Create an RSA key in a way PSA doesn't support: random generation with e≠65537, import of (n,e,d) without CRT parameters, import of CRT parameters without d.
• Import an ECC public key in compressed form. Also, perform custom ECC arithmetic through ecp.h to create a key? Given that ECC formats are simple, a pk bridge might not be the best way.

(For the dual problem of exporting a PSA key and leveraging pkwrite, I think .mbedtls_pk_setup_opaque does the job adequately.)

Goals of this issue (which may be broken down into sub-issues depending on how the development goes):

• Design the new API. There is already a pk→psa bridge mbedtls_pk_wrap_as_opaque, but it's intended for testing and may not be the right prototype or resource behavior.
• Document, implement and test the new API.
• Update the upcoming PSA migration guide.

[mpg]

Design the new API. There is already a pk→psa bridge mbedtls_pk_wrap_as_opaque, but it's intended for testing and may not be the right prototype or resource behavior.

FWIW, my initial impression is that the existing mbedtls_pk_wrap_as_opaque will not be suitable as it is, as it actually does pk->psa->pk and gives the user no flexibility about attributes (usage and algorithm).

So I guess we'll end up implementing a different API, and then probably changing the implementation of mbedtls_pk_wrap_as_opaque() to make use of that API - and probably move mbedtls_pk_wrap_as_opaque to somewhere under tests/ (it's only used in test suites and SSL test programs) as I'm not a big fan of having functions that are technically public but documented as internal.

[gilles-peskine-arm]

I'm closing this issue because the design is done (#7766, #8769) and issues have been filed for the resulting tasks.