[root v11] online-signing tweaks

[jku]

Assuming the migration in #1323 goes as planned, the timestamp expiry period in root v10 is 7 days and the signing period is 4 days meaning we sign a new timestamp every three days. We should consider signing timestamp more often (maybe daily?):

• clients that follow the spec will always download timestamp.json: whether the timestamp is new or not does not change the bandwidth or time requirements
• signing more often makes the repository less likely to break (as it means we will have 6 days to react to any issues rather than 4)

[jku]

related: #1347 -- we should change the incorrect KMS key id

[haydentherapper]

I'd be supportive of reducing to a day, but we should try to get community input on this given it would increase the frequency of online queries during verification.

[jku]

it would increase the frequency of online queries during verification

That's the thing:

• if the clients operate as tuf spec requires, it's the same number of requests: once every startup
• even if they use an "old" but valid timestamp (against tuf spec but seems like a possible choice too), the expiry time remains the same, so should not lead to more requests

[haydentherapper]

if the clients operate as tuf spec requires

This is the issue, at least for the Go client, it allows for configuration that doesn't follow the spec. In Cosign, we would cache targets up to the timestamp validity and then refresh only once the timestamp as expired. In the new sigstore-go TUF client, the default behavior is to follow the TUF spec, but it can be configured. I'm not sure what other clients are doing.

[haydentherapper]

Oh sorry, I re-read, you're saying to keep the timestamp validity the same but just up the frequency of signings. Gotcha, that seems good!

Though I think we should think about decreasing the timestamp validity as well, to let us handle key rotations faster.

[jku]

decreasing the timestamp validity as well

I'm not sure about this, the main reason I suggest this change (signing more often) is to increase the time we would have to deal with failures -- current 4 days feels very, very tight to me:

• shorter timestamp expiry only protects clients that are not spec compliant -- this feels like the wrong focus
• in practice the current expiry/signing periods mean two working days to fix issues. This is not a lot for root causing, potentially fixing and releasing tuf-on-ci and upgrading root-signing
• there are failure scenarios (like some sort of KMS disaster) where we need to fix something and then need signatures from 3 root signers. This is not reasonable in two days

[jku]

This change is now live in root-signing-staging sigstore/root-signing-staging#171