Rotate root (offline) keys

In the even of a root key being compromised, or when a root key approaches its expiry date, we need to be able to rotate the old key(s) out of use to be replaced with a newly-generated one.

As with your initial deployment, you must ensure you have reviewed and executed the Ceremony preparation steps to ensure the resulting TUF repository is trustworthy.

The process of rotating a root key is very similar to that for generating root keys during the initial deployment. The important difference is that because the TUF repository is already in operation, care must be taken to retain the integrity of the system, respecting the threshold of root key signatures required by your configuration.

For example, if your root key threshold is 2 (the default), and you need to rotate both keys, you should perform the ceremony below at least twice: first to add the new root keys (deploying n+1.root.json), and then a second time to remove the old ones (deploying n+2.root.json). This ensures that the TUF repository remains valid throughout. If we were to remove all the existing keys at the same time as adding new ones, this would break the integrity of the chain of root metadata files, and thus the validity of the TUF repository itself.

Overview

Having prepared a secure environment and created a ceremony branch to hold the resulting artifacts, the high-level steps are:

  1. Generate new root key(s) to replace the compromised or expiring ones.
  2. Update and sign new root metadata to incorporate the new root keys and fresh signatures in the metadata.
  3. Deploy new root metadata to actually put the updated root keys and signatures into operation.

Generate new root key(s)

This part of the process is exactly as it was during the initial deployment, where the relevant keyholders will use a ceremony computer (again, this is ideally an airgapped workstation) to generate a fresh root keypair, and then share the verification key with the ceremony coordinator.

Update and sign new root metadata

Once the ceremony coordinator has collected any new root verification keys from keyholders, we can prepare and sign the next version of the root metadata for the TUF repository (eg. 2.root.json). This process consists of:

  • Initializing partial root metadata, leveraging rugged commands to add and remove verification keys, and prepare a new “signable” partial root metadata file to be signed by keyholders.
  • Signing the new partial root metadata, in which keyholders produce a signature with their new signing key for the updated root metadata, and send that signature back to the ceremony coordinator.
  • Completing the new root metadata, where the ceremony coordinator adds the keyholders’ signatures to the update root metadata, resulting in a completed N+1.root.json, the next version of the live root metadata file.

Deploy new root metadata

As before, once the ceremony coordinator has created the updated root metadata file, they need to deploy it into the TUF repository. This requires pausing Rugged’s processing of new targets temporarily, then deploying the updated root metadata and triggering the re-signing of the other metadata roles, before resuming processing.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Rugged TUF Server is a trademark of Consensus Enterprises.