Add draft of TAP-17

Signed-off-by: Aditya Sirish <[email protected]>

Author: adityasaky

README.md

@@ -18,6 +18,7 @@
 * [TAP 14: Managing TUF Versions](tap14.md)
 * [TAP 15: Succinct hashed bin delegations](tap15.md)
 * [TAP 16: Snapshot Merkle Trees](tap16.md)
+* [TAP 17: Replace signature envelope with SSL signing-spec](tap17.md)
 
 ## Rejected
 

tap17.md

@@ -0,0 +1,94 @@
+* TAP: 17
+* Title: Remove Signature Wrapper from the TUF Specification
+* Version: 0
+* Last-Modified: 22/06/2021
+* Author: Aditya Sirish A Yelgundhalli, Marina Moore
+* Type: Standardization
+* Status: Draft
+* Content-Type: markdown
+* Created: 30/04/2021
+* +TUF-Version:
+* +Post-History:
+
+# Abstract
+
+This TUF Augmentation Proposal (TAP) proposes removing the definition of a
+specific signature wrapper and key definitions, and instead defines certain
+properties a wrapper must have. Further, it suggests POUF-1 as an example
+implementors can refer to when choosing to generate TUF metadata.
+
+# Specification
+
+The TUF specification currently, as of June 2021, uses a custom signature
+wrapper. At the time of authoring this document, the primary reference
+implementation written in Python also generates TUF metadata using the same
+signature wrapper.
+
+However, TUF does not mandate the use of this signature wrapper, nor any
+specific metaformat. Indeed, TAP-11, "Using POUFs for Interoperability" enables
+adopters to make their own decisions for their implementations, and provides a
+mechanism for them to document their decisions. POUF-1 is the POUF for the
+official reference implementation, and it seems like the obvious choice for this
+information to be specified.
+
+Section 4.2 of the TUF specification, titled "File formats: general principles"
+may be replaced by a description of the properties that any signature wrapper used
+by a TUF implementation must provide. Some important properties:
+
+* SHOULD include an authenticated payload type
+* SHOULD avoid depending on canonicalization for security
+* SHOULD NOT require the verifier to parse the payload before verifying
+* SHOULD NOT require the inclusion of signing key algorithms in the signature
+* MUST support the inclusion of multiple signatures in a file
+* SHOULD support a hint indicating what signing key was used, i.e., a KEYID
+
+The presence of an authenticated payload type can be valuable for a project like TUF,
+with multiple implementations and derivatives. Indeed, every POUF that describes an
+implementation MUST choose a unique payload type, ensuring that there is no confusion
+about which implementation generated some piece of metadata.
+
+# Motivation
+
+TAP-11 introduced the concept of POUFs but the TUF specification continues to
+specify example formats, namely those used by the reference implementation as
+of June 2021. These definitions are essentially replicated in POUF-1, which is
+meant to be the authoritative source for information about the reference
+implementation. By replacing these definitions with *properties* that a wrapper
+must possess, the specification can aid adopters with the development of their
+implementations and the POUF can serve as an example. In this scenario, both
+documents are serving the purpose originally envisioned for them.
+
+Further, the examples used in the specification are from the old signature
+wrapper that includes certain side effects:
+* it requires canonicalization before signature verification
+* it does not allow for distinguishing different implementations that may have slightly different formats, i.e., it's missing a payload type
+
+# Rationale
+
+Moving the signature wrapper details out of the specification, and instead
+requiring adopters to refer to POUFs for examples ensures a clean separation
+between implementation details and the TUF specification. Indeed, it also
+ensures that the focus of the reader is on only the TUF primitives rather
+than burdening them with the specifics of the signature wrapper.
+
+# Security Analysis
+
+Any implementations that build on the properties listed in this document
+will have their security enhanced.
+
+# Backwards Compatibility
+
+No backwards incompatibility.
+# Augmented Reference Implementation
+
+See POUF-1 for details about the reference implementation.
+
+# Copyright
+
+This document has been placed in the public domain.
+
+# References
+
+* [TAP-11](https://github.com/theupdateframework/taps/blob/master/tap11.md)
+* [File formats in TUF Specification](https://theupdateframework.github.io/specification/latest/index.html#file-formats-general-principles)
+* [POUF-1](/POUFS/reference-POUF/pouf1.md)