Skip to content

Checking version after verifying signatures #112

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

Merged
merged 1 commit into from
Oct 30, 2020
Merged

Checking version after verifying signatures #112

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
60 changes: 36 additions & 24 deletions tuf-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

Last modified: **30 September 2020**

Version: **1.0.9**
Version: **1.0.10**

We strive to make the specification easy to implement, so if you come across
any inconsistencies or experience any difficulty, do let us know by sending an
Expand Down Expand Up @@ -1191,19 +1191,25 @@ of the form VERSION_NUMBER.FILENAME.EXT (e.g., 42.snapshot.json), where
VERSION_NUMBER is the version number of the snapshot metadata file listed in
the timestamp metadata file.

* **5.3.1**. **Check against timestamp metadata.** The hashes and version
number of the new snapshot metadata file MUST match the hashes, if any, and
version number listed in the trusted timestamp metadata. If hashes and
version do not match, discard the new snapshot metadata, abort the update
cycle, and report the failure.
* **5.3.1**. **Check against timestamp role's snapshot hash.** The hashes
of the new snapshot metadata file MUST match the hashes, if any, listed in
the trusted timestamp metadata. This is done, in part, to prevent a
mix-and-match attack by man-in-the-middle attackers. If the hashes do not
match, discard the new snapshot metadata, abort the update cycle, and report
the failure.

* **5.3.2**. **Check for an arbitrary software attack.** The new snapshot
metadata file MUST have been signed by a threshold of keys specified in the
trusted root metadata file. If the new snapshot metadata file is not signed
as required, discard it, abort the update cycle, and report the signature
failure.

* **5.3.3**. **Check for a rollback attack.** The version number of the targets
* **5.3.3**. **Check against timestamp role's snapshot version.** The version
number of the new snapshot metadata file MUST match the version number listed
in the trusted timestamp metadata. If the versions do not match, discard the
new snapshot metadata, abort the update cycle, and report the failure.

* **5.3.4**. **Check for a rollback attack.** The version number of the targets
metadata file, and all delegated targets metadata files, if any, in the
trusted snapshot metadata file, if any, MUST be less than or equal to its
version number in the new snapshot metadata file. Furthermore, any targets
Expand All @@ -1212,13 +1218,14 @@ the timestamp metadata file.
these conditions are not met, discard the new snapshot metadata file, abort
the update cycle, and report the failure.

* **5.3.4**. **Check for a freeze attack.** The latest known time MUST be
* **5.3.5**. **Check for a freeze attack.** The latest known time MUST be
lower than the expiration timestamp in the new snapshot metadata file. If
so, the new snapshot metadata file becomes the trusted snapshot metadata
file. If the new snapshot metadata file is expired, discard it, abort the
update cycle, and report the potential freeze attack.

* **5.3.5**. **Persist snapshot metadata.** The client MUST write the file to

* **5.3.6**. **Persist snapshot metadata.** The client MUST write the file to
non-volatile storage as FILENAME.EXT (e.g. snapshot.json).

**5.4**. **Download the top-level targets metadata file**, up to either the
Expand All @@ -1231,51 +1238,56 @@ of the form VERSION_NUMBER.FILENAME.EXT (e.g., 42.targets.json), where
VERSION_NUMBER is the version number of the targets metadata file listed in the
snapshot metadata file.

* **5.4.1**. **Check against snapshot metadata.** The hashes and version
number of the new targets metadata file MUST match the hashes, if any, and
version number listed in the trusted snapshot metadata. This is done, in
part, to prevent a mix-and-match attack by man-in-the-middle attackers. If
the new targets metadata file does not match, discard it, abort the update
cycle, and report the failure.
* **5.4.1**. **Check against snapshot role's targets hash.** The hashes
of the new targets metadata file MUST match the hashes, if any, listed in the
trusted snapshot metadata. This is done, in part, to prevent a mix-and-match
attack by man-in-the-middle attackers. If the new targets metadata file does
not match, discard the new target metadata, abort the update cycle, and
report the failure.

* **5.4.2**. **Check for an arbitrary software attack.** The new targets
metadata file MUST have been signed by a threshold of keys specified in the
trusted root metadata file. If the new targets metadata file is not signed
as required, discard it, abort the update cycle, and report the failure.

* **5.4.3**. **Check for a freeze attack.** The latest known time MUST be
* **5.4.3**. **Check against snapshot role's targets version.** The version
number of the new targets metadata file MUST match the version number listed
in the trusted snapshot metadata. If the versions do not match, discard it,
abort the update cycle, and report the failure.

* **5.4.4**. **Check for a freeze attack.** The latest known time MUST be
lower than the expiration timestamp in the new targets metadata file. If so,
the new targets metadata file becomes the trusted targets metadata file. If
the new targets metadata file is expired, discard it, abort the update cycle,
and report the potential freeze attack.

* **5.4.4**. **Persist targets metadata.** The client MUST write the file to
* **5.4.5**. **Persist targets metadata.** The client MUST write the file to
non-volatile storage as FILENAME.EXT (e.g. targets.json).

* **5.4.5**. **Perform a pre-order depth-first search for metadata about the
* **5.4.6**. **Perform a pre-order depth-first search for metadata about the
desired target, beginning with the top-level targets role.** Note: If
any metadata requested in steps 5.4.5.1 - 5.4.5.2 cannot be downloaded nor
any metadata requested in steps 5.4.6.1 - 5.4.6.2 cannot be downloaded nor
validated, end the search and report that the target cannot be found.

* **5.4.5.1**. If this role has been visited before, then skip this role
* **5.4.6.1**. If this role has been visited before, then skip this role
(so that cycles in the delegation graph are avoided). Otherwise, if an
application-specific maximum number of roles have been visited, then go to
step 5.5 (so that attackers cannot cause the client to waste excessive
bandwidth or time). Otherwise, if this role contains metadata about the
desired target, then go to step 5.5.

* **5.4.5.2**. Otherwise, recursively search the list of delegations in
* **5.4.6.2**. Otherwise, recursively search the list of delegations in
order of appearance.

* **5.4.5.2.1**. If the current delegation is a multi-role delegation,
* **5.4.6.2.1**. If the current delegation is a multi-role delegation,
recursively visit each role, and check that each has signed exactly the
same non-custom metadata (i.e., length and hashes) about the target (or
the lack of any such metadata).

* **5.4.5.2.2**. If the current delegation is a terminating delegation,
* **5.4.6.2.2**. If the current delegation is a terminating delegation,
then jump to step 5.5.

* **5.4.5.2.3**. Otherwise, if the current delegation is a
* **5.4.6.2.3**. Otherwise, if the current delegation is a
non-terminating delegation, continue processing the next delegation, if
any. Stop the search, and jump to step 5.5 as soon as a delegation
returns a result.
Expand Down