Fix inconsistency in root key migration paragraph #61
Conversation
Updates an outdated paragraph in section 6.1 that explained how root keys are rotated by backwards-verifying signatures from the latest root file available on the repository back to the latest root file available on the client. The correct (new) workflow, which is also described in step 1 of the client application workflow of section 5, performs verification in a forward-directed manner, i.e. starting at the latest root on the client and going forward to the latest root on the repo.
lukpueh
force-pushed
the
fix-root-migration-inconsistency
branch
from
f76b923
to
9da1787
Compare
There was a problem hiding this comment.
LGTM provisional on a few minor changes; thanks, Lukas!
I wonder if we might want to add a short note that this does not stop an attacker who is controlling the repository (but w/o any root keys) from launching freeze attacks, but that those attacks are limited by the earliest expiration timestamp of the versioned root metadata files being served.
lukpueh
force-pushed
the
fix-root-migration-inconsistency
branch
from
9a6a3a3
to
8ffbfaa
Compare
|
Thanks for your typo fix and rewordings, @mnm678 and @trishankatdatadog. I squashed them into one commit and added another one that mentions the possibility and limits of a freeze attack. Let me know what you think. |
|
@lukpueh Sorry, I have one more suggestion. Other than that, it's great, thank you so much! |
|
It's a fine suggestion, @trishankatdatadog, thanks! Let me quickly re-fold the lines, squash the UI commit and force push. |
Co-Authored-By: mnm678 <[email protected]> Co-Authored-By: Trishank Karthik Kuppusamy <[email protected]>
lukpueh
force-pushed
the
fix-root-migration-inconsistency
branch
from
8750443
to
890b383
Compare
Fixes #56
Updates an outdated paragraph in section 6.1 that explained how root keys are rotated by backwards-verifying signatures from the latest root file available on the repository back to the latest root file available
on the client.
The correct (new) workflow, which is also described in step 1 of the client application workflow of section 5, performs verification in a forward-directed manner, i.e. starting at the latest root on the client and going forward to the latest root on the repo.