TAP 5: mark as rejected

TAP 5 was designed to fulfil two primary use-cases:
1. restricting trust in a community repository to a single project
2. trusting a mirror only for snapshot and targets metadata

TAP 5 addresses both of these use-cases on the repository, effectively by
setting up an intermediary repository to filter/restrict the upstream
repository configuration.

This design is problematic for the second use-case, as this means that a
party with a threshold of root keys can no longer affect changes on the
Timestamp and Snapshot roles. TUF is designed with the Root role as the
locus of trust, removing that control is antithetical to the design of
the system.

The first use-case, restricting trust to a single project, is unwieldy
as it requires setting up an in-house repository in order to filter the
views on the upstream repository. This use-case is better suited by the
proposal "User Selection of the Top-Level Target Files Through Mapping
Metadata" (#118), which
extends the map file in TAP 4 to put control for selecting trusted
targets in the hands of users who can configuring the client (such as
the end user, a system adminstrator or client developer).

Signed-off-by: Joshua Lock <jlock@vmware.com>

README.md

@@ -12,13 +12,13 @@
 
 ## Draft
 
-* [TAP 5: Setting URLs for roles in the root metadata file](tap5.md)
 * [TAP 8: Key rotation and explicit self-revocation](tap8.md)
 * [TAP 11: Using POUFs for Interoperability](tap11.md)
 * [TAP 12: Improving keyid flexibility](tap12.md)
 
 ## Rejected
 
+* [TAP 5: Setting URLs for roles in the root metadata file](tap5.md)
 * [TAP 7: Conformance testing](tap7.md)
 
 

tap5.md

@@ -1,10 +1,10 @@
 * TAP: 5
 * Title: Setting URLs for roles in the root metadata file
 * Version: 1
-* Last-Modified: 22-Jan-2018
+* Last-Modified: 20-Jul-2020
 * Author: Trishank Karthik Kuppusamy, Sebastien Awwad, Evan Cordell,
           Vladimir Diaz, Jake Moshenko, Justin Cappos
-* Status: Draft
+* Status: Rejected
 * Content-Type: text/markdown
 * Created: 24-Sep-2016