-
Notifications
You must be signed in to change notification settings - Fork 98
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
Make key ids global and define their range #104
Make key ids global and define their range #104
Conversation
Record what key ids have been used in a test case and purge them. The cleanup code no longer requires the key identifiers used in the tests to be in a certain small range.
Change the scope of key identifiers to be global, rather than per lifetime. As a result, you now need to specify the lifetime of a key only when creating it.
Define a range of key identifiers for use by the application (0..2^30-1), a range for use by implementations (2^30..2^31), and a range that is reserved for future use (2^31..2^32-1).
Only allow creating keys in the application (user) range. Allow opening keys in the implementation (vendor) range as well. Compared with what the implementation allowed, which was undocumented: 0 is now allowed; values from 0x40000000 to 0xfffeffff are now forbidden.
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 decision to permit key id zero is not discussed anywhere - not sure if this is deliberately to leave that decision to the application?
In keeping with other integral types, declare 0 to be an invalid key identifier. Documented, implemented and tested.
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.
LGTM
CI failure is ABI job (known to fail until Mbed-TLS/mbedtls#2636 lands in the development branch) and |
Make key ids global: you no longer need to specify a key's lifetime when you open it, the key id is enough. This is the “global model” of key ids, as opposed to the former “drive letter” model. Internal ref: https://github.com/ARMmbed/psa-crypto/issues/138
Carve the range of possible key ids into 3 sub-ranges: one for the application, one for the implementation and one reserved for future use. Internal ref: https://github.com/ARMmbed/psa-crypto/issues/136