Backwards Compatibility (TAPs 3, 4, 5) about taps

[vladimir-v-diaz]

@ecordell

This TAP can be made backwards compatible with the previous implementation of TUF by treating metadata with a name field the same as a metadata with a names field containing one entry.

I'd like to verify the wording here. The quoted text in bold is unclear to me. Do you mean to say that current implementations (compliant with the pre-TAP3 specification) can be made backwards compatible by doing this and that? Or are you proposing that backwards-compatibility be built into the TAP? In other words, that a TAP3-compliant implementation be forced to recognize previous formats. If this is indeed what you intend, then TAP3 must be updated to list the supported formats of a delegation (i.e., "names" and "names" are valid attributes).

I am implementing TAP3 and would like to verify the wording before taking a deep dive.

[ecordell]

@vladimir-v-diaz The way the TAP is currently written changes the specification to use the names key instead of the name key. So the proposal of supporting both is technically invalid against the current spec.

I mostly wrote it that way to signal that some small changes to the rest of the TAP are necessary to make the backwards compatibility section correct. I.e. if this were a PR instead of a discussion, I would've changed the part of TAP3 that defines the file format to allow name and names to be optional, and the wording in the backwards compatibility section would've been "This TAP is backwards compatible..."

Would it be helpful to issue PRs for these three sections to have TAP-specific discussions? I opened this because I think this requires careful consideration to ensure no security implications.

[awwad]

I think the modified text you (@ecordell) provide is much better, but I say that with the same understanding Vlad indicated: that a particular implementation can provide backward compatibility by doing what you've indicated. I'm still not clear on whether or not you're suggesting that TAP 3 should require that TUF support both the old and new formats (which differ not only in the contents of name/names, but must also in the presence of keyids and thresholds outside of name/names).

If the suggestion is that implementations can support pre- and post-TAP3 TUF formats by doing what you've mentioned, then I think that makes sense.

If, instead, the suggestion is that TAP 3 should propose that both schemes be acceptable, so that the TUF reference implementation supports both, then I'm less sure about that: it seems confusing.

[vladimir-v-diaz]

Would it be helpful to issue PRs for these three sections to have TAP-specific discussions? I opened this because I think this requires careful consideration to ensure no security implications.

We'd welcome pull requests. It can certainly help us reason about the proposed changes.

[trishankkarthik]

Love it --- thanks for raising this issue! Let me read it carefully, and get back to you :)

[trishankkarthik]

Looks good to me! What do you think @JustinCappos ?

[JustinCappos]

I need to spend some time thinking deeply about whether there are any security issues lurking here, but I appreciate the suggestion and agree we should merge these sections in.

…

On Thu, Dec 8, 2016 at 11:55 AM, Trishank Karthik Kuppusamy < ***@***.***> wrote: Looks good to me! What do you think @JustinCappos <https://github.com/JustinCappos> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XD9kNa8RP_zQA-avulyRxLS13b73Cks5rGDaPgaJpZM4LH5ba> .

[vladimir-v-diaz]

Note that the TAP 3 proposal (as it is currently exists on the repository) does more than just change "name" to "names". It also moves around the keyids, threshold, etc. attributes. Please compare the formats below:

current format:

"roles": [
    {
     "keyids": [
      "a0650f29dde63403cc4eec28a1c66f2262d6339434a01c63a881a48bedd9bca9"
     ],
     "name": "role1",
     "paths": [
      "/file3.txt"
     ],
     "terminating": false,
     "threshold": 1
    }
]

proposed format:

{
roles: [{          
          // Both roles must sign the same hashes and length of the following targets.
          "paths": ["baz/*.pkg"],
          "names": {
            ROLENAME-1: {
              "keyids": [KEYID-1],
              "threshold": THRESHOLD-1
            },
            ROLENAME-2: {
              "keyids": [KEYID-2],
              "threshold": THRESHOLD-2
            }
          },
          ...
        ]