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,

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...)

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.

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

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.

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.

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