Add timeserver key rotation

[awwad]

Motivation

In implementations of Uptane employing a timeserver, the ability to update the timeserver key is required. Since the reference implementation uses a timeserver, timeserver key rotation is required.

For discussion of timeserver key rotation as a fast-forward attack mitigation, and to see the portions of the Uptane standard dealing with this process, see uptane-standard PR 41.

Changes Required

PRs in Progress

The PRs in progress addressing this requirement are (check off when merged):

• upTUF PR 22: allow custom override of system clock
• Uptane PR 170: timeserver times override use of system clock
• an upTUF PR implementing metadata support in Root and Targets for timeserver key listing
• Uptane PR 171: implement timeserver key rotation

Direct requirements

• Root metadata on the Director repository must include the additional 'timeserver' role, specifying its keys.
• Targets metadata on the Director repository must include an additional entry to specify timeserver keys (if partial verification secondaries are supported).
• primary.py and secondary.py must employ the above, using Root for full verification and using Targets for partial verification.

Indirect requirements

• Uptane's current TUF implementation (upTUF) requires several changes in formats.py, repository_lib.py, conf.py, repository_tool.py, and updater.py in order to (1) support overriding use of the system clock and (2) support timeserver key listing.
• After the Uptane reference implementation's migration from using a custom TUF implementation (upTUF) to using the TUF reference implementation, after the fix to TUF Issue 660 is deployed, there should be no code changes in TUF itself required to handle timeserver key rotation support: the Uptane code should be able to achieve this transparently through use of the new roledb interface.

The latter point is because the 660 rewrite involves a lot of generalization of repository_lib and repository_tool, and a removal of the intermediate metadata format currently in roledb. That makes it much easier to construct custom metadata (since generating/writing metadata will basically just be dumping the contents of roledb, instead of the current weird reconstruction with implicit rules about what roles exist).

So for now, upTUF will use Uptane-specific timeserver key code... but post-merge, I don't think a fork persists: the Uptane repository-side interface will just add some info to roledb and then write the metadata in the usual TUF way.