Andrew Thoelke

Need to also add these functions to the list of APIs that require the SIGN and VERIFY usage flags in `doc/crypto/api/keys/policy.rst`.

Rebased this PR, now that #177 has been merged. I have also reworked the introduction of Interruptible operations to the Functionality chapter, following the restructuring that was introduced by the...

I've also attached a new PDF render (see the main PR description above)

Although we worked hard during API development to avoid having collisions in the first 31 characters of API identifiers (minimum requirement for a C99 implementation), we missed the collisions between...

The identifier length maybe-problem comes back again, but harder with the additional interruptible operations required for #198. See [my comment](https://github.com/ARM-software/psa-api/issues/198#issuecomment-2113034144).

Revisiting the naming of the API elements, after considering an interruptible API for key agreement use cases (#198). For those functions, there are no expected multi-part operations, so we dispense...

> Given the length constraint, we have to consider key derivation. Even though Mbed TLS doesn't need interruptible ECC derivation at the moment, the API should include it. > >...

> I actually quite like the simplicity of this approach. Given the various stages for sign/verify message are basically going to be compulsary, do we necessarily have to have separate...

> If these assumptions are not, in fact, correct, because the signature computation state is of a similar size to the internal hash state (only one is required at any...

> I am admittedly presuming here that we are using pure key agreement here, not chained with a derivation as the new interface seems to do. Yes, chaining is easy...