Delegation tracking issue

[asraa]

Description

I'm making an executive decision to remove delegations until a further root-signing event. The reasoning is that there are many issues in using delegations practically and we are still making a final change to target name-spacing in this next root (by namespacing targets by usage).

I think if we rotate Rekor or need to rotate a target, it's easiest to set up a new signing.

I propose we add back delegations in a future root once the following is complete: (1) Client-side: All cross-language ecosystems are at least supporting top-level targets, and understand how to identify their usage. (2) Repository-side: We have a staging root we test the new delegations changes on (3) Repository-side: We have GitHub workflows created for managing the delegations (4): Client-side: We have ways of searching for targets in namespaces through delegations: https://github.com/theupdateframework/go-tuf/issues/378, https://github.com/theupdateframework/python-tuf/issues/1995 (5): Repository-side: We properly handle updating delegations: https://github.com/theupdateframework/go-tuf/issues/330

This is not to say client ecosystems cannot begin using delegations and custom roots ahead of time: I just would like to separate this from the current changes (target namespacing, consistent snapshotting, and key format migration), because it's now a lot of changes.

Continuing to support delegations in this next root means I need to fix (5) and (4) ASAP, and I want to be more thorough about that.

[joshuagl]

I think this is a smart move. Let's not rush delegations in, let's take the time to do them right. Targeting v6 sounds good to me!

[kommendorkapten]

Agree with @joshuagl. As I understand it, none of the delegations (rekor, revocation) are critical now, the Rekor keys are already defined as top-level targets. We could add the revocation list if needed as a top-level target, with a new signing as suggested by @asraa.

[dlorenc]

sgtm

[mnm678]

I agree that waiting until the next root will help avoid potential complications with the signing.

I'd also like to propose a follow-up to the delegations (either in the next root or the one after) that allows sigstore to create namespaced delegations to Fulcio identities so that users can determine which identities should be used to verify particular signatures.

[asraa]

that allows sigstore to create namespaced delegations to Fulcio identities so that users can determine which identities should be used to verify particular signatures.

Cool, thank you! Could you open a separate issue so we can discuss format? I think we decided on a new namespaced usage like verification_material/*

[haydentherapper]

LGTM

[jku]

Update on this:

• tuf-on-ci supports one level of delegations, repository tooling is adequate
• delegations get a targetpath "{rolename}/*" (and a few more directories underneath)
• there is one npmjs delegation currently

Personally I think root-signing should be very careful about accepting new delegations: maintaining a "generic open source TUF repo" requires a different level of support than "sigstore root of trust". I'm not entirely convinced we have the resources or interest for the former: at least this requires a discussion on the goals of root-signing as a project.

Can we close this or is there something to do here?

[kommendorkapten]

Personally I think root-signing should be very careful about accepting new delegations

I strongly agree and think we can close this issue.