Address review comments

Be more explicit that each KEYID can only count one signature towards the
threshold.

Signed-off-by: Joshua Lock <[email protected]>

tuf-spec.md

@@ -550,7 +550,8 @@ All signed metadata objects have the format:
 Note: The "signatures" list SHOULD only contain one <a>SIGNATURE</a> per
 <a for="role">KEYID</a>. This helps prevent multiple signatures by the same key
 being counted erroneously towards the minimum <a>THRESHOLD</a> indicating valid
-metadata.
+metadata. <a>THRESHOLD</a> counting is further described in the relevant steps
+of [[#detailed-client-workflow]].
 
 ### Key objects ### {#file-formats-keys}
 
@@ -1331,11 +1332,14 @@ it in the next step.
   specified in the trusted root metadata file (version N), and (2) a
   <a>THRESHOLD</a> of keys specified in the new root metadata file being
   validated (version N+1).  When computing the <a>THRESHOLD</a> each
-  <a>KEY</a> must ONLY contribute one <a>SIGNATURE</a> towards the
-  <a>THRESHOLD</a>, even if the <a>KEY</a> is listed more than once in a role's
-  signatures field.  If version N+1 is not signed as required, discard it, abort
-  the update cycle, and report the signature failure.  On the next update cycle,
-  begin at step [[#update-root]] and version N of the root metadata file.
+  <a>KEY</a> MUST only contribute one <a>SIGNATURE</a>. That is, each
+  <a>SIGNATURE</a> which is counted towards the <a>THRESHOLD</a> MUST have
+  a unique <a>KEYID</a>. Even if a <a>KEYID</a> is listed more than once in the
+  "signatures" list a client MUST NOT count more than one verified
+  <a>SIGNATURE</a> from that <a>KEYID</a> towards the <a>THRESHOLD</a>.
+  If version N+1 is not signed as required, discard it, abort the update cycle,
+  and report the signature failure.  On the next update cycle, begin at step
+  [[#update-root]] and version N of the root metadata file.
 
 5. **Check for a rollback attack.** The version number of the new root
   metadata (version N+1) MUST be exactly the version in the trusted root
@@ -1381,12 +1385,15 @@ it in the next step.
   (e.g., timestamp.json).
 
 2. **Check for an arbitrary software attack.** The new timestamp
-  metadata file MUST have been signed by a <a>THRESHOLD</a> of keys specified in
-  the trusted root metadata file.  When computing the <a>THRESHOLD</a> each
-  <a>KEY</a> must ONLY contribute one <a>SIGNATURE</a> towards the
-  <a>THRESHOLD</a>, even if the <a>KEY</a> is listed more than once in a role's
-  signatures field.  If the new timestamp metadata file is not properly signed,
-  discard it, abort the update cycle, and report the signature failure.
+  metadata file MUST have been signed by a <a>THRESHOLD</a> of keys specified
+  in the trusted root metadata file.  When computing the <a>THRESHOLD</a> each
+  <a>KEY</a> MUST only contribute one <a>SIGNATURE</a>. That is, each
+  <a>SIGNATURE</a> which is counted towards the <a>THRESHOLD</a> MUST have
+  a unique <a>KEYID</a>. Even if a <a>KEYID</a> is listed more than once in the
+  "signatures" list a client MUST NOT count more than one verified
+  <a>SIGNATURE</a> from that <a>KEYID</a> towards the <a>THRESHOLD</a>.  If the
+  new timestamp metadata file is not properly signed, discard it, abort the
+  update cycle, and report the signature failure.
 
 3. **Check for a rollback attack.**
 
@@ -1439,11 +1446,13 @@ it in the next step.
 3. **Check for an arbitrary software attack**. The new snapshot
   metadata file MUST have been signed by a <a>THRESHOLD</a> of keys specified in
   the trusted root metadata file.  When computing the <a>THRESHOLD</a> each
-  <a>KEY</a> must ONLY contribute one <a>SIGNATURE</a> towards the
-  <a>THRESHOLD</a>, even if the <a>KEY</a> is listed more than once in a role's
-  signatures field.  If the new snapshot metadata file is not signed as
-  required, discard it, abort the update cycle, and report the signature
-  failure.
+  <a>KEY</a> MUST only contribute one <a>SIGNATURE</a>. That is, each
+  <a>SIGNATURE</a> which is counted towards the <a>THRESHOLD</a> MUST have
+  a unique <a>KEYID</a>. Even if a <a>KEYID</a> is listed more than once in the
+  "signatures" list a client MUST NOT count more than one verified
+  <a>SIGNATURE</a> from that <a>KEYID</a> towards the <a>THRESHOLD</a>.  If the
+  new snapshot metadata file is not signed as required, discard it, abort the
+  update cycle, and report the signature failure.
 
 4. **Check against timestamp role's snapshot version**. The version
   number of the new snapshot metadata file MUST match the version number listed
@@ -1491,12 +1500,15 @@ it in the next step.
   target metadata, abort the update cycle, and report the failure.
 
 3. **Check for an arbitrary software attack**. The new targets
-  metadata file MUST have been signed by a <a>THRESHOLD</a> of keys specified in
-  the trusted root metadata file.  When computing the <a>THRESHOLD</a> each
-  <a>KEY</a> must ONLY contribute one <a>SIGNATURE</a> towards the
-  <a>THRESHOLD</a>, even if the <a>KEY</a> is listed more than once in a role's
-  signatures field.  If the new targets metadata file is not signed as required,
-  discard it, abort the update cycle, and report the failure.
+  metadata file MUST have been signed by a <a>THRESHOLD</a> of keys specified
+  in the trusted root metadata file.  When computing the <a>THRESHOLD</a> each
+  <a>KEY</a> MUST only contribute one <a>SIGNATURE</a>. That is, each
+  <a>SIGNATURE</a> which is counted towards the <a>THRESHOLD</a> MUST have a
+  unique <a>KEYID</a>. Even if a <a>KEYID</a> is listed more than once in the
+  "signatures" list a client MUST NOT count more than one verified
+  <a>SIGNATURE</a> from that <a>KEYID</a> towards the <a>THRESHOLD</a>.  If the
+  new targets metadata file is not signed as required, discard it, abort the
+  update cycle, and report the failure.
 
 4. **Check against snapshot role's targets version**. The version
   number of the new targets metadata file MUST match the version number listed