Repository workflows: document how a repository recovers from compromise

[joshuagl]

trafficstars

This may be in secondary literature #91 or it may belong as part of the specification, but either way, we should capture more guidance for repository operators (and repository tooling implementers).

Specifically for this issue, what should a repository do to recover from compromise?

For fast forward attacks, the Mercury paper makes some suggestions in section 5.3 and there's some more thoughts in https://github.com/theupdateframework/specification/pull/150/files#r710834950 and #150 more generally.

[jku]

In addition (not sure if this is another issue as it's not strictly about compromise), I don't think the key rotation strategies are spelled out anywhere:

• root rotation typically requires two root versions: First an intermediate one that changes roles keys and signs with "old" and "new" keys, then a final one that signs with new keys only
• other rotations do not require this but there is a slightly similar case with online keys: if uncompromised keys are being rotated (because maybe policy says so) without urgency, the snapshot/metadata files could first be signed with both new and old keys and then (significantly later) a new root version would add the new key and remove the old key to the role. This process would give clients the possibility to actually do rollback checks for next timestamp and snapshot: if keys are changed without adding signatures beforehand, that would mean the local snapshot/timestamp cannot be valid and cannot be used for rollback checks).

The second item is a bit obscure and not massively important but it is something I've only realised after a year and a half so :shrug: ...

[joshuagl]

This comment from @jku in #150 is especially relevant to this discussion.