Discussion of TAP 6: Include specification version in metadata about taps

[vladimir-v-diaz]

An issue with TAP 6 was raised here (it forces parsing of untrusted metadata).

[JustinCappos]

So @heartsucker raised a good point. @endophage, what are your thoughts?

[JustinCappos]

The other point we need to define is how clients are supposed to deal with metadata of different versions. Are they supposed to only accept exactly the version they were written for? Should they have rules about what to ignore and what to use?

[endophage]

Yeah, I don't know how to address the need to parse at least some of the JSON. I don't think putting it in the URL/path is the right solution for two reasons:

1. That should be reserved for potential changes to how pathing is performed (i.e. the API to access the TUF files).
2. The version should be signed to ensure an attacker can't change the version and for example, set it to an older mode that causes some newer piece of verification to not be performed.

It's an imperfect solution but maybe we can have the spec_version only apply to the signed component and be included in there? Then it can be parsed like the expires, and version fields after signature verification. My instinct is that the signed section will be the location of most spec changes while signatures will see very little iteration.

[JustinCappos]

Yes, I tend to agree that a URL / path isn't the right way to handle this. The version number clearly needs to be protected. How concerned are we all about the need to parse at least some JSON? I don't feel this is a deal breaker. Does anyone feel is it adequate to just make implementers aware of this issue?

…

On Fri, Aug 18, 2017 at 4:05 PM, David Lawrence ***@***.***> wrote: Yeah, I don't know how to address the need to parse at least some of the JSON. I don't think putting it in the URL/path is the right solution for two reasons: 1. That should be reserved for potential changes to how pathing is performed (i.e. the API to access the TUF files). 2. The version should be signed to ensure an attacker can't change the version and for example, set it to an older mode that causes some newer piece of verification to not be performed. It's an imperfect solution but maybe we can have the spec_version only apply to the signed component and be included in there? Then it can be parsed like the expires, and version fields after signature verification. My instinct is that the signed section will be the location of most spec changes while signatures will see very little iteration. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XD2adguRNWTgMJQT7HeK-lbWFwJStks5sZe5_gaJpZM4NsGRX> .

[vladimir-v-diaz]

I also feel that the "signed" portion of metadata is the best place to store "spec_version." Parsing untrusted JSON/metadata is a separate issue in my opinion, and we should deal with it in a separate TAP/issue. Parsing untrusted data is a problem for all of the other keys in "signed," as well. Perhaps the solution is signing the "signed" portion as it is written to disk/file, or maybe the base64 string is the best option... Nevertheless, we should discuss this issue elsewhere.

Does anyone not agree? May I go ahead and accept TAP 6 if there is no other disagreement?

[heartsucker]

How concerned are we all about the need to parse at least some JSON?

This should be fine as the signature verification would happen first, and then we'd check the spec_version field like we check the expires and other fields. I agree with @endophage that the signatures portion is unlikely to see iteration after TAP 9. With that change, each signature object contains the absolute minimum amount of data necessary to check a signature, so it (hopefully) won't change again.

[JustinCappos]

Okay, I've proposed a PR to accept this TAP. Justin

…

On Fri, Aug 25, 2017 at 11:46 AM, heartsucker ***@***.***> wrote: How concerned are we all about the need to parse at least some JSON? This should be fine as the signature verification would happen first, and then we'd check the spec_version field like we check the expires and other fields. I agree with @endophage <https://github.com/endophage> that the signatures portion is unlikely to see iteration after TAP 9. With that change, each signature object contains the absolute minimum amount of data necessary to check a signature, so it (hopefully) won't change again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XD1Sk3s2jRTDxZvQLumGx8JdXqG-dks5sbuxDgaJpZM4NsGRX> .

[vladimir-v-diaz]

PR has been merged. Closing this issue now that TAP 6 has been accepted!