Fix and add information around policies #110
Conversation
Specifically for signing/verifying hashes/messages. Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
| operation, if otherwise permitted by the key’s type and policy. The flag must be present on keys | ||
| used when calling PsaSignHash. | ||
|
|
||
| This flag automatically sets `sign_message`: if an application sets the flag `sign_hash` when |
There was a problem hiding this comment.
This and next paragraph might mean that we need to change/adapt our checks in the Parsec interface. Either modify the checks for sign_message or have private fields on the usage flags and setters that do the correct thing.
There was a problem hiding this comment.
So do we do the fixes in the service first before merging this, or is it irrelevant between releases?
Also, on a similar note, did we ever decide what happens with "versions" of the book? I mean, some parts in the book might change in a way that isn't consistent with version 0.6.0 of the service. How would someone know what the book looked like back then, and how it changed since?
There was a problem hiding this comment.
So do we do the fixes in the service first before merging this, or is it irrelevant between releases?
I think it's ok to merge this but we should create the relevent issues on the various repos. I think mostly psa-crypto and then import the changes upwards.
Also, on a similar note, did we ever decide what happens with "versions" of the book? I mean, some parts in the book might change in a way that isn't consistent with version 0.6.0 of the service. How would someone know what the book looked like back then, and how it changed since?
Good point, not sure if we want to have a mapping between service version and book version but that sounds like a good idea. I guess for now they can still browse the git history 🤡 We only publish the main branch of the book anyway...
There was a problem hiding this comment.
We only publish the main branch of the book anyway...
Yeah, I know, but someone would have to go through the release history of the service, align it with the changes here and then rebuild it from source. I suggest creating releases of the book for some milestones (e.g. version 0.7.0 of the service) and attaching a built version of the book. That can just be downloaded, unzipped and opened in a browser from disk.
An unfortunate issue is that we track both service and clients in the book (and much more, actually), so we have to decide what we create new "releases" for.
| operation, if otherwise permitted by the key’s type and policy. The flag must be present on keys | ||
| used when calling PsaSignHash. | ||
|
|
||
| This flag automatically sets `sign_message`: if an application sets the flag `sign_hash` when |
There was a problem hiding this comment.
So do we do the fixes in the service first before merging this, or is it irrelevant between releases?
Also, on a similar note, did we ever decide what happens with "versions" of the book? I mean, some parts in the book might change in a way that isn't consistent with version 0.6.0 of the service. How would someone know what the book looked like back then, and how it changed since?
Specifically for signing/verifying hashes/messages.
Signed-off-by: Hugues de Valon hugues.devalon@arm.com