diff --git a/docs/tuf-spec.txt b/docs/tuf-spec.txt index c0249ba5..f944bef1 100644 --- a/docs/tuf-spec.txt +++ b/docs/tuf-spec.txt @@ -949,14 +949,11 @@ Version 1.0 (Draft) 5.1. The client application - 0. **Load the previous root metadata file.** We assume that a good, trusted + 0. **Load the trusted root metadata file.** We assume that a good, trusted copy of this file was shipped with the package manager / software updater using an out-of-band process. - 0.1. **Check signatures.** The previous root metadata file MUST have been - signed by a threshold of keys specified in the previous root metadata file. - - 0.2. Note that the expiration of the previous root metadata file does not + 0.1. Note that the expiration of the trusted root metadata file does not matter, because we will attempt to update it in the next step. 1. **Update the root metadata file.** Since it may now be signed using @@ -965,7 +962,7 @@ Version 1.0 (Draft) do so, the client MUST download intermediate root metadata files, until the latest available one is reached. - 1.1. Let N denote the version number of the previous root metadata file. + 1.1. Let N denote the version number of the trusted root metadata file. 1.2. **Try downloading version N+1 of the root metadata file**, up to some X number of bytes (because the size is unknown). The value for X is set by @@ -975,27 +972,28 @@ Version 1.0 (Draft) available, then go to step 1.8. 1.3. **Check signatures.** Version N+1 of the root metadata file MUST have - been signed by: (1) a threshold of keys specified in the previous root + been signed by: (1) a threshold of keys specified in the trusted root metadata file (version N), and (2) a threshold of keys specified in the - current root metadata file (version N+1). + new root metadata file being validated (version N+1). - 1.4. **Check for a rollback attack.** The version number of the previous - root metadata file must be less than or equal to the version number of this - root metadata file. Effectively, this means checking that the version - number signed in the current root metadata file is indeed N+1. + 1.4. **Check for a rollback attack.** The version number of the trusted + root metadata file (version N) must be less than or equal to the version + number of the new root metadata file (version N+1). Effectively, this means + checking that the version number signed in the new root metadata file is + indeed N+1. - 1.5. Note that the expiration of the current (intermediate) root metadata + 1.5. Note that the expiration of the new (intermediate) root metadata file does not matter yet, because we will check for it in step 1.8. - 1.6. Set the previous to the current root metadata file. + 1.6. Set the trusted root metadata file to the new root metadata file. 1.7. Repeat steps 1.1 to 1.7. 1.8. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in the current root metadata file. + than the expiration timestamp in the trusted root metadata file. - 1.9. **If the the timestamp and / or snapshot keys have been rotated, then - delete the previous timestamp and snapshot metadata files.** This is done + 1.9. **If the timestamp and / or snapshot keys have been rotated, then + delete the trusted timestamp and snapshot metadata files.** This is done in order to recover from fast-forward attacks after the repository has been compromised and recovered. A _fast-forward attack_ happens when attackers arbitrarily increase the version numbers of: (1) the timestamp metadata, @@ -1011,15 +1009,17 @@ Version 1.0 (Draft) filename used to download the timestamp metadata file is of the fixed form FILENAME.EXT (e.g., timestamp.json). - 2.1. **Check signatures.** The timestamp metadata file must have been - signed by a threshold of keys specified in the root metadata file. + 2.1. **Check signatures.** The new timestamp metadata file must have been + signed by a threshold of keys specified in the trusted root metadata file. - 2.2. **Check for a rollback attack.** The version number of the previous + 2.2. **Check for a rollback attack.** The version number of the trusted timestamp metadata file, if any, must be less than or equal to the version - number of this timestamp metadata file. + number of the new timestamp metadata file. 2.3. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in this metadata file. + than the expiration timestamp in the new timestamp metadata file. If so, + the new timestamp metadata file becomes the trusted timestamp + metadata file. 3. **Download and check the snapshot metadata file**, up to the number of bytes specified in the timestamp metadata file. @@ -1032,31 +1032,34 @@ Version 1.0 (Draft) the client MUST write the file to non-volatile storage as FILENAME.EXT. - 3.1. **Check against timestamp metadata.** The hashes, and version number - of this metadata file MUST match the timestamp metadata. + 3.1. **Check against timestamp metadata.** The hashes and version number + of the new snapshot metadata file MUST match the hashes and version number + listed in timestamp metadata. 3.2. **Check signatures.** The snapshot metadata file MUST have been signed - by a threshold of keys specified in the previous root metadata file. + by a threshold of keys specified in the trusted root metadata file. 3.3. **Check for a rollback attack.** - 3.3.1. Note that the previous snapshot metadata file may be checked for + 3.3.1. Note that the trusted snapshot metadata file may be checked for authenticity, but its expiration does not matter for the following purposes. - 3.3.2. The version number of the previous snapshot metadata file, if any, - MUST be less than or equal to the version number of this snapshot metadata - file. + 3.3.2. The version number of the trusted snapshot metadata file, if any, + MUST be less than or equal to the version number of the new snapshot + metadata file. 3.3.3. The version number of the targets metadata file, and all delegated - targets metadata files (if any), in the previous snapshot metadata file, if - any, MUST be less than or equal to its version number in this snapshot + 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 metadata filename that was listed - in the previous snapshot metadata file, if any, MUST continue to be listed - in this snapshot metadata file. + in the trusted snapshot metadata file, if any, MUST continue to be listed + in the new snapshot metadata file. 3.4. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in this metadata file. + than the expiration timestamp in the new snapshot metadata file. If so, + the new snapshot metadata file becomes the trusted snapshot metadata + file. 4. **Download and check the top-level targets metadata file**, up to either the number of bytes specified in the snapshot metadata file, or some @@ -1072,20 +1075,21 @@ Version 1.0 (Draft) FILENAME.EXT. 4.1. **Check against snapshot metadata.** The hashes (if any), and version - number of this metadata file MUST match the snapshot metadata. This is - done, in part, to prevent a mix-and-match attack by man-in-the-middle + number of the new targets metadata file MUST match the trusted snapshot metadata. + This is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers. - 4.2. **Check for an arbitrary software attack.** This metadata file MUST - have been signed by a threshold of keys specified in the latest root + 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. - 4.3. **Check for a rollback attack.** The version number of the previous + 4.3. **Check for a rollback attack.** The version number of the trusted targets metadata file, if any, MUST be less than or equal to the version - number of this targets metadata file. + number of the new targets metadata file. 4.4. **Check for a freeze attack.** The latest known time should be lower - than the expiration timestamp in this metadata file. + than the expiration timestamp in the new targets metadata file. If so, + the new targets metadata file becomes the trusted targets metadata file. 4.5. **Perform a preorder depth-first search for metadata about the desired target, beginning with the top-level targets role.**