Update Root and Targets

[github-actions]

Initializes a new root and targets

[asraa]

Note: Requires #408

TO VERIFY

See https://github.com/sigstore/root-signing/blob/main/VERIFIER.md

GITHUB_USER=${GITHUB_USER} ./scripts/verify.sh 407

Please check any of the following that you can:

• We have 10 placeholder signatures on staged/root.json They should be both the [new] and [deprecated] IDs in the verify output.
• We have 5 placeholder signatures on staged/targets.json. They should match the [new] IDs in the verify output.
• We have 5 keys designated for root and targets roles in staged/root.json. These should match the keys in the verify output marked as [new]
• Verify some of the key ID pairs that they identify the same public key value. See the output "To match pubkey values of..."
• We have no delegations designated in staged/targets.json
• The targets added in staged/targets.json contains custom metadata designating fulcio, rekor, CTFE URI's if applicable.
• Old existing targets are present, and targets are also moved into sub-directories per usage.
• The thresholds for root and targets role is 3 in staged/root.json
• The expirations are in 6 months.
• Consistent snapshot is enabled in staged/root.json
• The versions of staged/root.json and staged/targets.json is 5.

[mnm678]

One concern about the expiration, otherwise lgtm

Please check any of the following that you can:

* We have 10 placeholder signatures on `staged/root.json` They should be both the `[new]` and `[deprecated]` IDs in the verify output.

yes!

* We have 5 placeholder signatures on `staged/targets.json`. They should match the `[new]` IDs in the verify output.

yes!

* We have 5 keys designated for `root` and `targets` roles in `staged/root.json`. These should match the keys in the verify output marked as `[new]`

yes!

* Verify some of the key ID pairs that they identify the same public key value. See the output "To match pubkey values of..."

* We have no delegations designated in `staged/targets.json`

yes!

* The targets added in `staged/targets.json` contains custom metadata designating fulcio, rekor, CTFE URI's if applicable.

yes!

* Old existing targets are present, and targets are also moved into sub-directories per usage.

yes!

* The thresholds for `root` and `targets` role is 3 in `staged/root.json`

yes!

* The expirations are in 6 months.

I actually see December 27 in targets (3 months)

* Consistent snapshot is enabled in `staged/root.json`

yes!

* The versions of `staged/root.json` and `staged/targets.json` is 5.

yes!

[SantiagoTorres]

Same, all verified but I see that targets set to expire in Dec 27 (3 months)

[bobcallaway]

Same, all verified but I see that targets set to expire in Dec 27 (3 months)

same

[haydentherapper]

Is this correct, to have no signatures to mark a delegation as no longer used? Or should we just not include the delegated metadata?

[haydentherapper]

Given this isn't referenced in the metadata, i assume deleted?

[asraa]

It is deleted! i think go-tuf never gets rid of the file in the store: you still are required to forever persist delegation versions (to prevent rollbacks), and I think that's the reasoning @mnm678 @trishankatdatadog

[trishankatdatadog]

Not necessarily. You can use the root to rotate the timestamp and/or snapshot keys, which will require clients to reset any previous snapshot metadata (see 5.3.11), and so you can use this opportunity to completely delete this delegation.

[haydentherapper]

To confirm, this is correct, that we want the targets duplicated under top level and nested under a folder?

[asraa]

I don't want to immediately break sigstore-rs: sigstore/sigstore-rs#134

but with the updated paths we can allow them to migrate and deprecate the old regexes

[asraa]

I have a feeling I know why the expiration changed: likely due to the reset delegations not passing our custom expiration