athoelke
commented
1 year ago These key formats provide key type and size information, but can vary in the key policy attributes that are encoded. An API to import the data as a key would require that the caller provide some optional key policy attributes, as well as the key location and identifier (if persistent).
This suggests that the API should take an input psa_key_attributes_t parameter to provide this information. Should the unused attributes (type and size) be ignored, or required to match if provided? - the latter is consistent with the existing psa_import_key() and psa_copy_key().
Given that the key type is probably unknown to the caller, should the API also return the imported key attributes? - or is it acceptable to require the application to call psa_get_key_attributes() for this information?
The Crypto API currently only supports importing a key where the caller specifies the key type. The required format for the key is typically just the key value itself.
There are numerous applications where a key is provided to the application, embedded in data that also provides key type and usage information. Providing a standard API to decode data from common key formats into a key would benefit application developers. Both by removing the effort to implement, or integrate, code that does this; and reducing the risk of incorrect (vulnerable) implementations of this code.
Key formats that are worth considering for such an API include those defined in:
Are there any others?