Fix inconsistency in root key migration paragraph

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.

Author: lukpueh

tuf-spec.md

@@ -1292,22 +1292,23 @@ non-volatile storage as FILENAME.EXT.
    role.  When replacing root keys, an application will sign the new root.json
    file with both the new and old root keys. Any time such a change is
    required, the root.json file is versioned and accessible by version number,
-   e.g., 3.root.json. Clients update the set of trusted root keys by requesting
-   the current root.json and all previous root.json versions, until one is
-   found that has been signed by a threshold of keys that the client already
-   trusts. This is to ensure that outdated clients remain able to update,
-   without requiring all previous root keys to be kept to sign new root.json
-   metadata.
-
-   In the event that the keys being updated are root keys, it is important to
-   note that the new root.json must at least be signed by the keys listed as
-   root keys in the previous version of root.json, up to the threshold listed
-   for root in the previous version of root.json. If this is not the case,
-   clients will (correctly) not validate the new root.json file.  For example,
-   if there is a 1.root.json that has threshold 2 and a 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 2.root.json. See step 1 in
-   Section 5.1 for more details.
+   e.g., 3.root.json.
+
+   Clients that have outdated root keys can update to the latest set of trusted
+   root keys, by incrementally downloading all intermediate root metadata
+   files, and verifying that each root metadata at a given version is signed by
+   a threshold of keys defined in the previous version of root, and a threshold
+   of keys defined in that given version of root.
+   For example, if there is a 1.root.json that has threshold 2 and a
+   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 2.root.json.
+   The client starts the root keys update update process with the latest
+   version of root metadata available on the client, and stops when no newer
+   root metadata is available from the repository. This ensures that an
+   outdated client can always correctly re-trace the chain of trust across
+   multiple root key updates, even if the latest set of root keys on the client
+   dates back multiple root metadata versions. See step 1 of the client
+   application workflow in Section 5 for more details.
 
    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