Describe and delineate "trusted metadata"

[joshuagl]

The detailed client workflow refers to trusted metadata, or a specific role's trusted metadata, several times. However, it doesn't explain what trusted metadata is, except implicitly during 5.3.7 where we "Set the trusted root metadata file".

This is particularly surprising when discussing the use of trusted metadata when checking for rollback attacks in 5.4.3 and 5.5.5

Furthermore, we should explicitly refer to the initial trusted root metadata that is loaded in 5.2 by a distinct name. This metadata that is delivered out-of-band should be lifecycle managed differently to other trusted metadata and a distinct name makes it easier to discuss in ancillary materials.

[joshuagl]

When/how trusted metadata is loaded for non-root roles is also not part of the current specification.

[jku]

My current thinking is that we should define two levels of trusted metadata:

• trusted in the interim: metadata that fulfills all requirements for being trusted (as now defined in their specific update workflow) except A) it may be expired and B) as a special rule for snapshot, it does not have to match the version/length/hashes in current timestamp meta. This definition is sort of already used for intermediate root, we should expand it to timestamp and snapshot
• fully trusted: the previous category plus expiry is checked and snapshot version/length/hashes are checked

Then we use these definitions so that we allow "trusted in the interim" metadata to be

• saved to disk (after all it has been verified valid by threshold of correct sigs: we also already do this for root)
• used when checking newer versions of that same metadata: e.g. interim snapshot can be used to do rollback checks on new snapshot

but "trusted in the interim" metadata can never be used to progress to the workflow for "next" metadata: we cannot do targets validation before we have a "fully trusted" snapshot.

I think a definition like that makes defining the "load trusted local metadata" and "rollback checks" steps fairly easy, or at least possible? Something that might not be trivial is deciding when to do those steps: I've been involved with ngclient so I think trusted metadata should only be loaded once the "previous" metadata is "fully trusted" -- in other words before we can load local snapshot, we should have updated root and timestamp through their full workflows, aka they should be "fully trusted". I can see how there are other viewpoints considering the legacy updater does not work like this :) but I also don't want the spec to prevent me from doing the process I mention above as I consider it correct (as it prevents loading local metadata that is no longer signed by current threshold of current keys) and easier to implement without bugs.

[jku]

Just to document the issues with rollback checks: the intent seems to be that

• expired timestamp can be used to do rollback checks on new timestamp
• expired snapshot can be used to do rollback checks on new snapshot
• snapshot can be used to do rollback checks on new snapshot even if the current snapshot does not match the meta information (version/hashes/length) in current timestamp

None of these are explicitly mentioned in the spec. I'll include the last one for completeness, but this one is in the spec:

• expired root can be saved to disk and can be used to verify next root version (which may also be expired)