-
Notifications
You must be signed in to change notification settings - Fork 96
Don't require a type and size when creating a key slot #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't require a type and size when creating a key slot #19
Conversation
Remove the type and bits arguments to psa_allocate_key() and psa_create_key(). They can be useful if the implementation wants to know exactly how much space to allocate for the slot, but many implementations (including ours) don't care, and it's possible to work around their lack by deferring size-dependent actions to the time when the key material is created. They are a burden to applications and make the API more complex, and the benefits aren't worth it. Change the API and adapt the implementation, the units test and the sample code accordingly.
@@ -350,16 +341,14 @@ void many_transient_handles( int max_handles_arg ) | |||
psa_key_policy_t policy = PSA_KEY_POLICY_INIT; | |||
uint8_t exported[sizeof( size_t )]; | |||
size_t exported_length; | |||
size_t max_bits = PSA_BITS_TO_BYTES( sizeof( exported ) ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a typo, but isn't present anywhere else in the test suite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API simplification itself as well as its implementation look good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
(I have one question about the surrounding documentation, but that is unrelated to this PR.)
@@ -124,14 +124,6 @@ psa_status_t psa_get_key_lifetime(psa_key_handle_t handle, | |||
* application calls psa_close_key() or psa_destroy_key() or until the | |||
* application terminates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can we detect that the application has terminated and we can free the allocated key slot?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That depends on the integration. For a library integration, when the application terminates, this frees all the runtime resources held by the crypto library. For a service integration, the access control layer in the service knows who each handle belongs to and should close a handle if it loses contact with the owner of that handle.
Includes PRs ARMmbed#6, ARMmbed#18, ARMmbed#19.
Remove the type and bits arguments to psa_allocate_key() and
psa_create_key(). They can be useful if the implementation wants to
know exactly how much space to allocate for the slot, but many
implementations (including ours) don't care, and it's possible to work
around their lack by deferring size-dependent actions to the time when
the key material is created. They are a burden to applications and
make the API more complex, and the benefits aren't worth it.
Change the API and adapt the implementation, the units test and the
sample code accordingly.