[delegations] Refresh/Update a delegation

[asraa]

Description

See https://github.com/theupdateframework/go-tuf/issues/330; delegation rolenames must not conflict, so there is currently no way through the go-tuf API to modify properties of a delegation. The workaround is to reset it, and then recreate it.

It would be good to test this, since I'm unsure whether resetting it and then recreating it would interfere with the delegation version numbers.

For e.g.

1. Add role1 at version 1 to top-level targets version 5.
2. Update role1 metadata to version 2.
3. Update the role1 delegation stub -> top-level targets becomes version 6.
4. What version is role1? Should it be 1 (because it's a "new delegation") or 3 (because the role name is the same and should always be monotonic)? I think 3. So then, resetting it and recreating may not hold state correctly.

cc @kommendorkapten @joshuagl @trishankatdatadog @mnm678

[mnm678]

4. What version is role1? Should it be 1 (because it's a "new delegation") or 3 (because the role name is the same and should always be monotonic)? I think 3. So then, resetting it and recreating may not hold state correctly.

The version should be 3 (as it is the same delegation, but a later version). I think the ideal solution here is to fix the upstream go-tuf library to allow for updates to delegations the same way other targets are updated.

[kommendorkapten]

@asraa I'm trying to understand what the real work needed are. With the current tooling we can:

1. Update the expiration. By running add-delegation the expiration is updated for the role's metadata file. This is updated even if the delegation exists.
2. To bump the version of a delegate's metadata file, we can rely on the existing sign -bump-version command.

[asraa]

This would be in case of rotating the delegation's signing key.

I don't see how current tooling can handle modifying properties of the delegation -- add-delegation calls this func which will error if the delegation already exists https://github.com/theupdateframework/go-tuf/blob/f0771105d2d374b71fb6a0b21bd70bbdcbdd4234/repo.go#L616

Update the expiration.

Isn't updating the expiration of the role's metadata file handled by just the role itself in its own repository (which includes a version bump - it seems the same as point 2).

[kommendorkapten]

Yes, changing the key is something I don't think can be done today, but we have ~1y to figure that out 😄

I should maybe clarify what I meant, for the immediate work, we have support for the following:

• adding a delegation
• changing the targets the delegation provides
• changing the expiration
• bumping the version Are covered by the existing tooling.

Isn't updating the expiration of the role's metadata file handled by just the role itself in its own repository (which includes a version bump - it seems the same as point 2).

Agreed, but I would prefer that we have tooling for this to avoid manually working on the JSON files, which we have.

[asraa]

Yes, changing the key is something I don't think can be done today, but we have ~1y to figure that out smile

Yes exactly! I just wanted to make sure we had a tracking issue.

And yep, agree with the current support (which I think is good enough to start with)

[kommendorkapten]

Great, sorry for not being clear on my intentions, I just wanted to make sure this is not a blocker for adding the delegation.

[kommendorkapten]

Should we remove this from this milestone and add it to root signing v8?

[asraa]

Should we remove this from this milestone and add it to root signing v8?

Yes! Will do - thanks.

[jku]

This should no longer be relevant with current tools