Can delegated targets public keys be found in the root metadata?

[erickt]

In section 4.4.5, is it allowed for TUF clients to find the public keys in the root metadata, or is it required that the keys only be found in the targets (or delegated targets) metadata?

[trishankatdatadog]

Only the keys for the top-level roles (root, timestamp, snapshot, and targets) are to be trusted from the root role metadata. The rest of the keys come from targets and delegated friends.

Does this answer your question, Eric? Also, what is the context here, please?

[erickt]

@trishankatdatadog Thanks! This came from rust-tuf's implementation of resolving a key id to a public key structure. I wanted to see if we should be incorporating the keys listed in the root metadata when trying to find a key. I wasn't sure what we should do if some delegated foo role was signed with a root metadata key, but the key wasn't listed in the targets other intermediate delegated metadata. It sounds like this should be treated as an error, rather than accepting the metadata has a valid signature.

[trishankatdatadog]

Yeah, it definitely sounds like an error to me.

Ideally, the keys used to verify a metadata file should be scoped. What I mean is that there shouldn't internally be a global map of keys. So even if the root metadata file and some other delegated targets metadata file shared the same keyids, it really shouldn't matter. All top-level role metadata should be scoped to trust only pubkeys from the root metadata, and any delegated targets role metadata should be scoped to trust only pubkeys from the originating delegation in the graph being traversed.

Does this make sense?

[lukpueh]

IMO the spec makes it quite clear that the keys in root.json are for the top-level roles. However, it never mentions explicitly where keys for delegated targets roles are defined.

I have a pending PR that adopts the TAP 3 (multi-role delegation) metadata format, where I describe the keys field of a delegating targets role. @erickt do you think that is sufficient to close this issue?

Alternatively/Additionally, we could add a sentence to 3.1.2.1 Metadata files for targets delegation, that makes it clear that delegated target roles are authorized by the keys listed in the directly delegating target role.

[erickt]

@lukpueh Adding a sentence to 3.1.2.1 would be helpful. It might be a little redundant with your TAP 3, but I don't think it hurts to re-state how this should work. I can whip up a sentence for consideration. Thanks!