Skip to content

added root key migration details #445

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

added root key migration details #445

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions docs/tuf-spec.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1008,6 +1008,23 @@ Version 1.0 (Draft)
ensure that outdated clients remain able to update, without requiring all
previous root keys to be kept to sign new root.json metadata.

The exact steps to perform the root.json migration should be as follows:

1. The client starts at version N of root.json

2. The client downloads version N + 1 of root.json

3. The client uses the keys and threshold defined in version N to
validate the signatures of N + 1

4. The client flushes all knowledge of root.json verion N then uses the
updated keys and threshold to validate the signatures of N + 1
Copy link
Contributor

@awwad awwad May 18, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Should this be N + 2?)

Either way, I this this is probably slightly wrong, and may leave you in a state where you have no trusted root metadata. Once N + 1 is validated per N, it must also be validated per N + 1, before you can discard N's metadata and fully trust N + 1.

In other words, I would say that 4 should be removed and replaced by these two:
4. The client uses the keys and threshold defined in version N + 1 to validate the signatures on N + 1.
4.5. If both validations have succeeded, then flush all knowledge of root.json version N and heretofore use N + 1's keys and thresholds to validate further versions.

Copy link
Contributor

@vladimir-v-diaz vladimir-v-diaz May 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think heartsucker's use of N + 1 in (4) is correct, it matches your (4). Nevertheless, I do think version N of root.json should only be flushed once N + 1 has been validated against itself and the previous version's keys and threshold.

Copy link
Author

@heartsucker heartsucker May 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vladimir-v-diaz You're right. I should say the flush happens after the validation.


5. Repeat until the client has reached the latest version of root.json

That is, if there is 1.root.json that has threshold 2 and 2.root.json that has
threshold 3, 2.root.json MUST be signed by at least 2 keys defined in
1.root.json and at least 3 keys defined in 3.root.json.
Copy link
Contributor

@awwad awwad May 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this example is a good one to include.


To replace a delegated developer key, the role that delegated to that key
just replaces that key with another in the signed metadata where the
Expand Down