Review error handling in key destruction

[ionut-arm]

When the Parsec service reports that a key destruction is successful, all is well and we have a common outcome across the providers - the key is gone from both the backend and all Parsec caches. On the other hand, when an error occurs the exact sequence of events is somewhat inconsistent. This issue is only meant for investigating the possible paths that could be taken due to errors, and where the state of the service ends up from there. If changes are required (either to the service or to the documentation of PsaDestroyKey), a new issue should be created.

An example of discrepancy:

• in the TPM provider we store encrypted keys in the KIM, so the backend does not have any traces of the key. Thus, all we have to do is delete the KIM entry. So we rely on the KIM to do everything for us, there's nothing else to delete, therefore consistency isn't an issue.
• in the PKCS11 provider, for asymmetric keys, we get identifiers for 2 objects and attempt to remove them sequentially. If the first operation succeeds but the 2nd fails, we're stuck, because (1) we leave our KIM entry intact (since we failed), so it appears we still have the object; (2) if we try to remove it again after the failure, now the first part will fail because the object isn't there anymore. This is on top of the fact that we don't really know whether an error code coming from PKCS11 means the object is still there or not (it might not be defined by the spec)

[hug-dev]

Maybe this is somewhat related with having consistency in key creation/deletion algorithms as expressed in #149

[ionut-arm]

Just realised something, though - we shout definitely say in the PsaDestroyKey documentation that sometimes when an error is returned, the key might still be accessible in the provider. This is to cover our asses for future providers - maybe there'll be cases where we cannot tell or guarantee that the key was deleted, so even if we'd generally want to delete our metadata, maybe that won't be a good idea for all providers.

[hug-dev]

when an error is returned, the key might still be accessible in the provider.

It is actually nicely described in the PSA Crypto API, and our docs:

however, it might be impossible to guarantee that the key material is not recoverable in such cases.

More generally, the PSA Crypto API says:

Implementations must make a best e�ort to ensure that that the key material cannot be recovered.

Which I think is what we are trying to do.

I checked the flows of key creation/deletion for all of our providers.

For creation what we should do is:

1. Generate a unique key ID
2. Try the backend key creation
3. If success, store the mappings

For deletion:

1. Get the key ID from the key name
2. Destroy the mappings
3. Try to do the backend key deletion

Steps 2 and 3 are inverted for Mbed Crypto and the PKCS11 provider. I will try to address that in a new PR. I don't think we need to change the documention of PsaDestroyKey as it is pretty clear currently.

For DeleteClient, we can go through all keys on all providers and delete them all without checking the Result but logging if an error happens. Either we set that operation to never fail, or we return a PsaGenericError, or one of the errors encountered?

[ionut-arm]

For DeleteClient, we can go through all keys on all providers and delete them all without checking the Result but logging if an error happens. Either we set that operation to never fail, or we return a PsaGenericError, or one of the errors encountered?

I think this should go in the issue for DeleteClient, but yeah - probably return PsaGenericError or something like that, don't think it makes sense to return one of the errors encountered (I mean, which one would you return if more than one happened...)