From a4e3d07eef114102310eb908b8e06d723d4c5b60 Mon Sep 17 00:00:00 2001 From: Aditya Sirish Date: Fri, 30 Apr 2021 13:08:41 -0400 Subject: [PATCH] Add draft of TAP-17 Signed-off-by: Aditya Sirish --- README.md | 1 + tap17.md | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 95 insertions(+) create mode 100644 tap17.md diff --git a/README.md b/README.md index 526cf53e..132a9374 100644 --- a/README.md +++ b/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 diff --git a/tap17.md b/tap17.md new file mode 100644 index 00000000..d3ca13cd --- /dev/null +++ b/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)