Expand on the TUF client update workflow, per popular demand.

docs/tuf-spec.txt

@@ -1,6 +1,6 @@
  The Update Framework Specification
 
-18 May 2017
+23 May 2017
 Version 1.0 (Draft)
 
 1. Introduction
@@ -1108,10 +1108,19 @@ Version 1.0 (Draft)
  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 keys 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.
-
+ 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.
 
  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