Add signature threshold computation advice

Several implementations have made similar errors -- counting multiple signatures by the same keyid -- when implementing signature threshold computation, for example the reference implementation: GHSA-pwqf-9h7j-7mv8 theupdateframework/python-tuf@83ac7be Add some extra description to the detailed client workflow to further explain that a threshold of signatures should only count one signature per key. Signed-off-by: Joshua Lock <[email protected]>
theupdateframework · May 28, 2021 · 24ca081 · 24ca081
1 parent b6aee74
commit 24ca081
Showing 1 changed file with 27 additions and 16 deletions.
diff --git a/tuf-spec.md b/tuf-spec.md
@@ -1285,12 +1285,15 @@ it in the next step.
   example, Y may be 2^10.
 
 4. **Check for an arbitrary software attack.** Version N+1 of the root
-  metadata file MUST have 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 new root metadata file being validated (version N+1).  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.
+  metadata file MUST have been signed by: (1) a <a>THRESHOLD</a> of keys
+  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.
 
 5. **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
@@ -1340,10 +1343,12 @@ 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 threshold of keys specified in the
-  trusted root metadata file.  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> 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.
 
 3. **Check for a rollback attack.**
 
@@ -1388,9 +1393,12 @@ it in the next step.
   the failure.
 
 3. **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
+  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.
 
 4. **Check against timestamp role's snapshot version**. The version
@@ -1437,9 +1445,12 @@ it in the next step.
   report the failure.
 
 3. **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.
+  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.
 
 4. **Check against snapshot role's targets version**. The version
   number of the new targets metadata file MUST match the version number listed