4 ms·
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.
by wtbob 10y ago
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).
- bennofs 10y agoDoesn'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.
- evancordell 10y agoEvery 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