Update TUF threshold information and editor details (#314)

* Update TUF threshold information and editor details

I'm proposing a patch spec update to make it clearer that a threshold of 0 (or less) is not allowed.  See: GHSA-fphv-w9fq-2525 for more details.

I've also updated people's affiliation and suggested that slack is the best way to contact us.

Signed-off-by: Justin Cappos <justincappos@gmail.com>

* Update tuf-spec.md

Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com>
Signed-off-by: Justin Cappos <justincappos@gmail.com>

* Demote THRESHOLD "definition tag" in tuf-spec.md to fix lint

Signed-off-by: Justin Cappos <justincappos@gmail.com>

---------

Signed-off-by: Justin Cappos <justincappos@gmail.com>
Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com>

Author: JustinCappos

tuf-spec.md

@@ -5,24 +5,23 @@ Status: LS
 Abstract: A framework for securing software update systems.
 Date: 2026-01-22
 Editor: Justin Cappos, NYU
-Editor: Trishank Karthik Kuppusamy, Datadog
+Editor: Trishank Karthik Kuppusamy, Apple
 Editor: Joshua Lock, Verizon
-Editor: Marina Moore, NYU
-Editor: Lukas Pühringer, NYU
+Editor: Marina Moore, Edera
+Editor: Lukas Pühringer, Eclipse
 Repository: theupdateframework/specification
 Mailing List: https://groups.google.com/forum/?fromgroups#!forum/theupdateframework
 Indent: 2
 Boilerplate: copyright no, conformance no
 Local Boilerplate: header yes
 Markup Shorthands: css no, markdown yes
 Metadata Include: This version off, Abstract off
-Text Macro: VERSION 1.0.33
+Text Macro: VERSION 1.0.34
 </pre>
 
 Note: We strive to make the specification easy to implement, so if you come
 across any inconsistencies or experience any difficulty, do let us know by
-sending an email to our [mailing list](
-  https://groups.google.com/forum/?fromgroups#!forum/theupdateframework),
+messaging us on the [CNCF slack](https://communityinviter.com/apps/cloud-native/cncf) channel #tuf,
 or by reporting an issue in the [specification repo](
   https://github.com/theupdateframework/specification/issues).
 
@@ -750,10 +749,9 @@ The "signed" portion of <a>root.json</a> is as follows:
     <a for="role">KEYID</a> represented in this key list and in other files,
     only one unique key has that <a for="role">KEYID</a>.
 
-  : <dfn>THRESHOLD</dfn>
-  ::
-    An integer number of keys of that role whose signatures are required in
-    order to consider a file as being properly signed by that role.
+    As before the THRESHOLD must be a positive integer number of keys (>=1) of 
+    that role whose signatures are required in order to consider a file as being 
+    properly signed by that role.
 
 <div class='example' id='example-root.json'>
 A <a>root.json</a> example file:
@@ -1040,6 +1038,12 @@ format:
     The rolename MUST be unique in the delegations object: multiple roles with
     the same rolename are not allowed within a <a>DELEGATIONS</a>.
 
+  : <dfn>THRESHOLD</dfn>
+  ::
+    A positive integer number of keys (>=1) of that role whose signatures are required in
+    order to consider a file as being properly signed by that role.  See the notes on 
+    <a>THRESHOLD</a> counting in the relevant steps of [[#detailed-client-workflow]].
+
   : <dfn>TERMINATING</dfn>
   ::
     A boolean indicating whether subsequent delegations should be considered
@@ -1108,6 +1112,7 @@ that of the third one, etc. In order to accommodate prioritized
 delegations, the "roles" key in the <a>DELEGATIONS</a> object above points to an array
 of delegated roles, rather than to a hash table.
 
+
 The metadata files for delegated target roles has the same format as the
 top-level <a>targets.json</a> metadata file.