-
Notifications
You must be signed in to change notification settings - Fork 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
[TAP 8] Simplify rotate file names #167
[TAP 8] Simplify rotate file names #167
Conversation
Signed-off-by: Marina Moore <[email protected]>
For extra protection in the event of a key compromise, this recommends the use of hashes in snapshot, and the secure storage of previous keys. Signed-off-by: Marina Moore <[email protected]>
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.
Needs some help / clarification in a few places...
Signed-off-by: Marina Moore <[email protected]>
Thanks for this proposal. This indeed simplifies the proposal a lot. Now, thinking about "why did we use a hash initially", as far as I remember:
Would this still be possible with this simplification? From my memory, the reason to use a hash of the validity expression came from the observation that there's no distinct file for a delegation. But I've neither followed up closely with TUF development, nor am I certain that the scenario described above is worth considering in your use cases. For me, there is the question "who is part of a team?" and "where are signatures put?" -- and I want to minimize the amount of files that have the requirement to have multiple signatures (since that means the file has to be passed to multiple entities before being put (and being valid) into the repository). |
Signed-off-by: Marina Moore <[email protected]>
Signed-off-by: Marina Moore <[email protected]>
Yes, the team could create a rotate file for the role with the next version number (so 1 to start). The goal here is to replicate the file name uniqueness from the hash with a version number. The rotate files are still signed with the previously trusted set of keys, and so only the existing team can create a valid rotate file. |
Signed-off-by: Marina Moore <[email protected]>
Signed-off-by: Marina Moore <[email protected]>
Signed-off-by: Marina Moore <[email protected]>
Signed-off-by: Marina Moore <[email protected]>
Signed-off-by: Marina Moore <[email protected]>
This change ensures that if two parties delegate to the same role, there won't be a state where the two delegations have different keys, and the rotations only apply to one of these. It also simplifies finding rotate files after a delegation change Signed-off-by: Marina Moore <[email protected]>
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.
I really like the simplification here, nice. I made one minor suggestion to clarify rotate file names, otherwise this looks great.
Co-authored-by: Joshua Lock <[email protected]> Signed-off-by: Marina Moore <[email protected]>
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 set of changes LGTM. Other PRs need to merge before this TAP can move forward.
Simplify rotate files per the discussion in the related issue.