Tighten thread safety requirements

We shouldn't violate the requirement that the key identifier can be
reused. In practice, a key manager may destroy a key that's in use by
another process, and the privileged world containing the key manager and
the crypto service should not be perturbed by an unprivileged process.

With respect to blocking, again, a key manager should not be blocked
indefinitely by an unprivileged application.

These are desirable properties even in the short term.

Signed-off-by: Janos Follath <janos.follath@arm.com>

docs/architecture/psa-thread-safety.md

@@ -71,11 +71,11 @@ We may want to go directly to a more sophisticated approach because when a syste
 
 #### Summary of guarantees when `psa_destroy_key` returns
 
-* The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier.
-* The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible.
-* The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system.
+1. The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier.
+2. The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible.
+3. The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system.
 
-As noted above in [“Correctness out of the box”](#correctness-out-of-the-box), destroying a key while it's in use is undefined behavior. The only guarantee in this case is that it won't cause data corruption or read-after-free inside the key store. In particular, any or all the listed guarantees may be violated when `psa_destroy_key` is called on a key that is in use.
+When `psa_destroy_key` is called on a key that is in use, guarantee 2. might be violated. (This is consistent with the requirement [“Correctness out of the box”](#correctness-out-of-the-box), as destroying a key while it's in use is undefined behavior.)
 
 ### Key destruction long-term requirements
 
@@ -88,7 +88,7 @@ The [PSA Crypto API specification](https://armmbed.github.io/mbed-crypto/html/ap
 * The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system.
 * No copy of the key material exists. Rationale: this is a security requirement. We do not have this requirement yet, but we need to document this as a security weakness, and we would like to become compliant.
 
-As opposed to the short term requirements, the above guarantees hold even if `psa_destroy_key` is called on a key that is in use.
+As opposed to the short term requirements, all the above guarantees hold even if `psa_destroy_key` is called on a key that is in use.
 
 ## Resources to protect