How to deal with metadata with similar expiration time

[kommendorkapten]

In some deployments, such as Sigstore trust root management, both root and targets have the same expiration and signers. This means that root and targets are always signed at the same time, by the same group of people. With the current operational model for tuf-on-ci, this use-case would require two signing events, one for root and one for targets, and so each signer would need to run the command for signing twice.

Although not the biggest issue in the world, it can a bit annoying. Lets propose some ideas for how this can be improved. The ideas may not be code changes, but can also be changes to the documentation so it can simplify the operation.

1 - Let TUF-on-CI figure this out

The automation can detect if multiple metadata files are expiring in the similar timeframe and have the same signers. If so, a new event (branch) can be prepared to sign all metadata files in the same command.

The bad thing is that this would lead to more corner-case code being added to TUF-on-CI which is not desired.

2 - Merge the branches

When the events (one for each role) is created, they are pushed as branches. A maintainer can merge those branches, and so creating a single event that can be used to sign all the changes.

This would not require any code changes, but maybe some clarification in the documentation, but puts more work on the tuf repo maintainer.

3 - Force an update of other metadata in an event

Consider the scenario when root and targets are about to expire the same time. From the root signing event, a maintainer can force an update (bump version and expiration) of the targets role, commit and push that. Then the two metadata roles can be signed in a single go. This would require a new verb or option to the cli for bumping a metadata version and expiration.

If any target is to be changed, that can be done as normal in the root signing event, as this will trigger an update for the targets metadata, the existing tooling already supports this. Not a big deal, but with the current implementation the signer has to provide the PIN code twice (once for each metadata role).

Way forward

As option 3 is partially solved (when modifying targets), a simpler way forward for the scenario when no changes to the artifact is required is desired.

I would prefer to skip option 1, as that code is quite a corner case. Option 2 puts more load on the maintainer, which I think we should avoid. So my preferred option is to add an option for tuf-on-ci-delegate to just bump the version for a specific role. This is a good compromise of amount of custom code and tuf repo maintainer work. This would also require some documentation changes to clarify this flow.

Thoughts? @jku @joshuagl @lukpueh

[jku]

I don't mind adding documentation for this case (or maybe even code although I would rather avoid it) but I would like to discuss the premise, the initial problem statement:

root and targets are always signed at the same time, by the same group of people.

I think this setup has a somewhat cyclical reasoning (as I think it was originally configured this way to make maintenance easier to manage and understand)...

I would like to challenge whether this is a good setup:

• what if instead we recommend setting targets expiry very long (like 6 years instead of 6 months): only root is periodically signed in this model
• key ownership is still verified (root is signed periodically and root and targets have the same keys and threshold)
• even if there was a mistake and e.g. targets keys are not the same same as root keys and after some time there is a surprising lack of quorum of targets keys, this would not be fatal as root signers can change targets delegation
• it seems to me that my suggestion has the same security properties but leads to fewer metadata changes overall (which is a good thing because signer/reviewer fatigue is probably a thing)

Am I missing something? Is there an advantage to making targets expire every 6 months (assuming root already does)?

CC @haydentherapper for possible knowledge of root-signing hysterical raisins,

[jku]

oh, forgot to add the conclusion: if my logic above is solid, then I would prefer option 2 (with the recommendation to not use the same expiry times) as it does not require code changes.

(I don't oppose adding the "bumping" mechanism in option 3, I just don't think it's much less work for maintainers: the extra signing event is still going to be there and needs closing, the only difference is that instead of git merge you run tuf-on-ci-delegate to "combine" the two events...)

[kommendorkapten]

what if instead we recommend setting targets expiry very long (like 6 years instead of 6 months): only root is periodically signed in this model

Yes, this is a valid question. I think it's easy to get "stuck in what you are used too". The schedule of 6 months for both root and targets was set before I joined the root signing maintenance team.

If the root and targets signer are exactly the same, and configuring the targets to a long expiration, and only resign root twice a year. I think it's a good solution. Then we can modify targets during the root signing when needed.

I have a hard time seeing that there is a security concern with this. We get frequent verification of possession and functionality of the keys. Root is refreshed frequently. One possible concern I can see is that a long expiration time for targets can pop out, but it's sort of fictive as root which governs the trust over targets is actually signed frequently.

So with that I think we can solve this with only documentation, and when updating the targets just do it on-demand, or do it during a root signing event.

[jku]

Sounds good: while we discuss this proposal of different expiries with others, we can use your option 2 in root-signing

[haydentherapper]

There is no historical context for the decision to have the same target and root expiration beyond just keeping them the same since it was the same set of keyholders.

One thing to consider is that it would be nice if we could make target updates without needing a new root too. For example we might do a log sharding in the middle of the root validity period. Given we are gathering all key holders together, we might just want to rotate the root too, but given it's easier to orchestrate signing events with TUF-on-CI than with root-signing, maybe we don't need to.

To confirm, is the target validity largely irrelevant, because once the timestamp has expired, the TUF client will fetch the latest snapshot which should reference the current targets file? Having it be such a long expiration makes me a little nervous that a client wouldn't fetch the latest target, but I don't think this is a valid concern.

[kommendorkapten]

Sounds good @haydentherapper

It seems that we are in agreement that we can:

• have the target's metadata expiry time extended.
• resign target when needed (i.e added a new content), without require a root signing event
• If needed, we can resign targets during a regular root signing event

As long as the time stamping runs on a frequent basis, any client will always be using the latest snapshot, and so the correct targets (and other delegations) versions. So from a security concern I would say we are good.

[jku]

Agreed then: process wise this should be good:

• now root signing does not happen in a complicated signing event with lots of changes: should be easier to review
• likewise actual artifact changes will only have those artifact changes, nothing else
• there might be a small increase in the number of signing events but the easier review should make that acceptable

Let's keep kommendorkaptens list in previous comment as the plan -- but there's no rush to do these changes.

Confirming some things from haydens comment:

• target updates without modifying root are indeed the norm for tuf-on-ci
• "is the target validity largely irrelevant..." yes, if root and targets signers are the same there is IMO no functional need to have both expire frequently
  • the core reason to sign frequently at all is to verify key possession -- either role is good for that
  • if signers for the two roles are the same, then they can at any signing event change one or both roles as they want
  • if on the other hand there was a mistake (and the groups of signers become somehow different), then root signers can always fix the issue -- this is the main reason for choosing to do frequent signing with root signers instead of targets