Skip to content

spec: s6.1: recommend aggressive timestamp key rotation #316

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
cyphar wants to merge 2 commits into
base: master
Choose a base branch
from
+15 −8
Draft

spec: s6.1: recommend aggressive timestamp key rotation #316

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1ce5556
spec: s6.1: add links for root.json
cyphar Mar 27, 2026
81f82b9
spec: s6.1: recommend aggressive timestamp key rotation
cyphar Mar 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 15 additions & 8 deletions tuf-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ Title: The Update Framework Specification
Shortname: TUF
Status: LS
Abstract: A framework for securing software update systems.
Date: 2026-01-22
Date: 2026-03-28
Editor: Justin Cappos, NYU
Editor: Trishank Karthik Kuppusamy, Apple
Editor: Joshua Lock, Verizon
Expand Down Expand Up @@ -1588,11 +1588,11 @@ should be encrypted and stored, and so it is left to implementers of
this document to decide how best to secure them.

To replace a compromised root key or any other top-level role key, the root
role signs a new root.json file that lists the updated trusted keys for the
role. When replacing root keys, an application will sign the new root.json
file with both the new and old root keys. Any time such a change is
required, the root.json file is versioned and accessible by version number,
e.g., 3.root.json.
role signs a new <a>root.json</a> file that lists the updated trusted keys for
the role. When replacing root keys, an application will sign the new
<a>root.json</a> file with both the new and old root keys. Any time such a
change is required, the <a>root.json</a> file is versioned and accessible by
version number (e.g., 3.root.json).

Clients that have outdated root keys can update to the latest set of trusted
root keys, by incrementally downloading all intermediate root metadata
Expand All @@ -1612,8 +1612,15 @@ versions. See step [[#update-root]] of the client application workflow for more

Note that an attacker, who controls the repository, can launch freeze
attacks by withholding new root metadata. The attacker does not need to
compromise root keys to do so. However, these freeze attacks are limited by
the expiration time of the latest root metadata available to the client.
compromise root keys to do so.
Such freeze attacks are limited by the expiration time of the latest root
metadata available to the client, but given the expiration time of the root
metadata is usually set to be very long (in order to limit the usage of such
important keys) this is not a large hurdle for attackers.
In order to make such attacks detectable by clients, repository operators
should always replace all timestamp keys each time a new version of the root
metadata is created. Doing this will narrow the window of a root metadata
freeze attack to the expiry of timestamp.EXT (which is usually very short).

To replace a delegated developer key, the role that delegated to that key
just replaces that key with another in the signed metadata where the
Expand Down