You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
X.509
COSE (CBOR Object Signing and Encryption): see RFC 8152 §13
Are there any others?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: