taps
taps copied to clipboard
Discussion of TAP-17: Remove signature wrapper from TUF spec
This is a place to discuss removal of the signature wrapper from the TUF spec, introduced in #138.
Link to implementation: To Do
Outstanding issues and questions relating to the TAP:
- Should the spec recommend/suggest/mention a format which implements the proposed properties? i.e., DSSE
- what should the pedagogical examples look like after the spec is updated per this TAP? do we continue to use JSON for file format examples?
- should we include guidance on payload type, particularly given this is a motivation for the TAP?
- what recommendations should the spec make about capturing implementation details in a POUF, especially payload type (how to identify the implementation)?
Should the spec recommend/suggest/mention a format which implements the proposed properties? i.e., DSSE
ITE-5 recommends DSSE while leaving the door open for other options. The reason the TAP currently doesn't is because it (by my interpretation) falls to the POUFs to do so, especially since POUF-1 is the "reference POUF" since it covers the canonical implementation. I'm very open to naming DSSE as one option after we've listed the properties in TAP-17 though.
what should the pedagogical examples look like after the spec is updated per this TAP? do we continue to use JSON for file format examples?
I think the language needs some updates to acknowledge the changes here, but it already indicates that it's using JSON as an example, and it can be other formats. I think we can just extend that warning and keep using JSON? The metaformat stuff can be replaced by the guidelines in TAP-17, and each role's example can just be in JSON.
should we include guidance on payload type, particularly given this is a motivation for the TAP?
Linked to https://github.com/theupdateframework/taps/pull/138#discussion_r751351550.
what recommendations should the spec make about capturing implementation details in a POUF, especially payload type (how to identify the implementation)?
I think some of this may be a modification to TAP-11 rather than TAP-17, if we're calling for additions to the POUF structure. IMO, POUFs should list one or more payload types that are applicable, and enumerate the instances (with links).
what should the pedagogical examples look like after the spec is updated per this TAP? do we continue to use JSON for file format examples?
I think the language needs some updates to acknowledge the changes here, but it already indicates that it's using JSON as an example, and it can be other formats. I think we can just extend that warning and keep using JSON? The metaformat stuff can be replaced by the guidelines in TAP-17, and each role's example can just be in JSON.
Agreed.
should we include guidance on payload type, particularly given this is a motivation for the TAP?
Linked to #138 (comment).
what recommendations should the spec make about capturing implementation details in a POUF, especially payload type (how to identify the implementation)?
I think some of this may be a modification to TAP-11 rather than TAP-17, if we're calling for additions to the POUF structure. IMO, POUFs should list one or more payload types that are applicable, and enumerate the instances (with links).
Agree that this should be modifications to TAP 11, just tracking the need as a pre-condition of moving TAP 17 to accepted.
Just opened https://github.com/theupdateframework/go-tuf/issues/176 to track implementing DSSE in go-tuf.