Driver interface stability promise in Mbed TLS 4.0

[gilles-peskine-arm]

What promises do we make in Mbed TLS 4.0 regarding the stability of driver interfaces? This covers:

• Prototype of the C functions that drivers implement.
• Provided tooling for generating driver wrappers.
• Support of handwritten driver wrappers.

Definition of done: a design decision (the hard part), and document it (the easy part).

[gilles-peskine-arm]

We're strongly considering officializing standardize the driver interface as a PSA interface. If this happens, the PSA Crypto working group will own the interface, not Mbed TLS/TF-PSA-Crypto. This is an argument against promising full backward compatibility of the current interface.

With my Mbed TLS/TF-PSA-Crypto hat, I am uncomfortable promising backward compatibility until we have done three things:

• Document the interfaces more precisely. In particular, make sure that it's clear whose responsibility it is to validate what.
• Test that the library is validating what the specification says it must validate.
• Implement the tooling for generating driver wrappers from JSON.

Given the high bar, I am revising my previous opinion: I don't think we'll have time to do it before the TF-PSA-Crypto 1.0 release. So I'm revising the priority as a COULD, but in all likelihood, this won't happen in time, and we'll have to live with unclear promises for some time longer.