Inconsistent wording for the trusted Root file in spec's detailed workflow and unneeded subsection about taps

[awwad]

One option we discussed is to write at the end of 1.3 something like "Version N+1 is now the trusted root metadata file." and then use "trusted root file" in all cases.

Alternatively, we could update them all to "current root metadata file". This is somewhat less clear on careful reading, but perhaps clearer to someone skimming.

(As for 0 and 0.1: 0.1 is unnecessary for TUF's security and possibly confusing. 1.3(2) performs the same check. See comments starting here.)

[vladimir-v-diaz]

I have moved this issue to the TUF repository. The TAPs repo isn't the place for this issue.

[jhdalek55]

If I can weigh in here, I think "trusted root metadata file," probably works better than "current" as a "standardized" term for the document as a whole.

[vladimir-v-diaz]

@awwad Feel free to repost your comment here:
theupdateframework/python-tuf#458

[trishankkarthik]

Although I don't have a preference, I don't think "trusted root metadata file" always works better than "current root metadata file."

Consider the following context: "a threshold of keys specified in the current root metadata file (version N+1)."

It's a little strange to say "trusted" here instead of "current", because we haven't trusted it yet, we're still checking it.

I'll leave this up to you all.

[awwad]

@trishankkarthik In 1.3 and 1.4, the root versions are numbered and the currently trusted file is actually N, so we can be even clearer. I'd probably put 1.3 and 1.4 this way: (Changes are bracketed [].)

1.3. **Check signatures.** Version N+1 of the root metadata file MUST have
been signed by: (1) a threshold of keys specified in the currently trusted root
metadata file (version N), and (2) a threshold of keys specified in the
[new] root metadata file [being validated] (version N+1).

1.4. **Check for a rollback attack.** The version number of the [currently
trusted] metadata file [(N)] must be less than or equal to the version number of [the
new] root metadata file [(N+1)]. Effectively, this means checking that the version
number signed in the [new] root metadata file is indeed N+1.

There's a bit of hand waving in 1.4 where we sort of imply that the new file doesn't have to have had version N+1 after all, even though we've been calling it N+1. If people think that's confusing, which I can imagine, it could be rewritten with versions identified as X and Y and given example values 6 and 7, say, in parentheticals. NBD, though.