Task on hold during rethink

A possible wrinkle: in the long term, we'd like to support explicit PSA contexts in non-PSA APIs, as requested in ARM-software/psa-api#77. Under that design, functions that take an RNG argument and no key argument should take a PSA context argument, and should make RNG calls through that context. Functions that have a key argument would use that key to determine the PSA context.

In many places, we already track a “context” in the form of RNG arguments that are passed down from API functions to legacy crypto calls. Rather than completely remove those RNG arguments, it could make sense to rewrite f_rng, p_rng to psa_context, and pass the psa_context down. When we reach a PSA API, we'd still only support the default context for now, in which the RNG is psa_get_random.

By the time of the 1.0 release, it's unlikely that the PSA crypto context API extension will be finalized, and in any case we do not intend to implement that context API until well after 1.0. So in 1.0, we would have a context parameter where the only supported value is NULL, and other values would be silently ignored. That doesn't seem very nice. But on the other hand, if we don't do it, then later we'll have to reintroduce a context parameter that's passed down, and more annoyingly, we'd have to add a with_psa_context variant of all the functions involved with an extra parameter. Is it worth having this temporarily in TF-PSA-Crypto 1.x and Mbed TLS 4.x, in order to avoid having to extend mbedtls APIs when we implement the context feature?

We do not currently consider multiple crypto contexts to be high priority in TF-PSA-Crypto and Mbed TLS, and it will likely have consequences on the API that go beyond the functions that take an RNG argument. Therefore it's unlikely that whatever we can do before 1.0 would be sufficient to finish the for multiple crypto contexts in 4.x. Hence, let's not bother with them at all, and go ahead and remove the RNG parameters.