Hacker News Reader

From the spec:

> Delegated trust can be revoked at any time by the delegating role signing new metadata that indicates the delegated role is no longer trusted.

This is a mistake, as it means that a client must receive the new metadata in order to be made aware of the revocation. The correct approach is either to delegate trust for a particular time period (determining how long is a risk-based decision), or to specify an online trust check (this fails safe).

View on HN

Every metadata file, including those that specify delegations, have an expiration. There are also higher-level expirations in the snapshot and timestamp files (a delegation won't be trusted if it's referenced by an out-of-date snapshot or timestamp)

I.e. there are multiple time-based controls in place

Doesn't the `snapshot.json` file protect against "not being aware of the revocation"? Since `snapshot.json` can be trusted to be up-to-date (due to being included by hash in `timestamp.json`), and `snapshot.json` has a hash of all metadata files, we can be sure that our metadata is up-to-date (or at most as old as the interval after which `timestamp.json` is considered out of date, which is as you say a risk-based decision). And our metadata includes the delegations, so if the metadata is up to date, then so is our delegation information.

Reply on news.ycombinator.com