diff --git a/tuf-spec.md b/tuf-spec.md
index f039cd5..e4e8ef4 100644
--- a/tuf-spec.md
+++ b/tuf-spec.md
@@ -528,11 +528,11 @@ where:
: KEYID
::
- the identifier of the key signing the ROLE dictionary.
+ the identifier of the key signing the ROLE dictionary.
: SIGNATURE
::
- a hex-encoded signature of the canonical form of the metadata for ROLE.
+ a hex-encoded signature of the canonical form of the metadata for ROLE.
All keys have the format:
@@ -594,7 +594,7 @@ The "rsa" format is:
{
- "keytype" : "rsa",
+ "keytype" : "rsa",
"scheme" : "rsassa-pss-sha256",
"keyval" : {
"public" : PUBLIC
@@ -612,7 +612,7 @@ The "ed25519" format is:
{
- "keytype" : "ed25519",
+ "keytype" : "ed25519",
"scheme" : "ed25519",
"keyval" : {
"public" : PUBLIC
@@ -630,7 +630,7 @@ The "ecdsa-sha2-nistp256" format is:
{
- "keytype" : "ecdsa-sha2-nistp256",
+ "keytype" : "ecdsa-sha2-nistp256",
"scheme" : "ecdsa-sha2-nistp256",
"keyval" : {
"public" : PUBLIC
@@ -650,7 +650,7 @@ the canonical form of the key.
Metadata date-time follows the ISO 8601 standard. The expected
format of the combined date and time string is "YYYY-MM-DDTHH:MM:SSZ". Time is
always in UTC, and the "Z" time zone designator is attached to indicate a
-zero UTC offset. An example date-time string is "1985-10-21T01:21:00Z".
+zero UTC offset. An example date-time string is "1985-10-21T01:21:00Z".
## File formats: root.json ## {#file-formats-root}
@@ -855,7 +855,7 @@ where:
: METAPATH
::
A string giving the file path of the metadata on the repository relative to
- the metadata base URL. For snapshot.json, these are top-level targets
+ the metadata base URL. For snapshot.json, these are top-level targets
metadata and delegated targets metadata.
: VERSION
@@ -956,7 +956,7 @@ where:
: TARGETS
::
- Each key of the TARGETS object is a TARGETPATH.
+ Each key of the TARGETS object is a TARGETPATH.
: TARGETPATH
::
@@ -998,16 +998,16 @@ where:
{
"keys" : {
- KEYID : KEY,
+ KEYID : KEY,
...
},
"roles" : [
{
"name": ROLENAME,
- "keyids" : [ KEYID, ... ] ,
+ "keyids" : [ KEYID, ... ] ,
"threshold" : THRESHOLD,
- ("path_hash_prefixes" : [ HEX_DIGEST, ... ] |
- "paths" : [ PATHPATTERN, ... ]),
+ ("path_hash_prefixes" : [ HEX_DIGEST, ... ] |
+ "paths" : [ PATHPATTERN, ... ]),
"terminating": TERMINATING,
},
...
@@ -1084,7 +1084,7 @@ over the second one, the second delegation is trusted more than the third
one, and so on. Likewise, the metadata of the first delegation will override that
of the second delegation, the metadata of the second delegation will override
that of the third one, etc. In order to accommodate prioritized
-delegations, the "roles" key in the DELEGATIONS object above points to an array
+delegations, the "roles" key in the DELEGATIONS object above points to an array
of delegated roles, rather than to a hash table.
The metadata files for delegated target roles has the same format as the
@@ -1171,10 +1171,10 @@ The "signed" portion of timestamp.json is as follows:
}
-SPEC_VERSION, VERSION and EXPIRES are the same as is described for the root.json file.
+SPEC_VERSION, VERSION and EXPIRES are the same as is described for the root.json file.
METAFILES is the same as described for the snapshot.json file. In the case
-of the timestamp.json file, this MUST only include a description of the
+of the timestamp.json file, this MUST only include a description of the
snapshot.json file.
@@ -1224,7 +1224,7 @@ The "signed" portion of
mirrors.json is as follows:
"mirrors" : [
{ "urlbase" :
URLBASE,
"metapath" :
METAPATH,
- "targetspath" : TARGETSPATH,
+ "targetspath" :
TARGETSPATH,
"metacontent" : [
PATHPATTERN ... ] ,
"targetscontent" : [
PATHPATTERN ... ] ,
("custom" : { ... }) }
@@ -1335,13 +1335,13 @@ it in the next step.
8. **Persist root metadata.** The client MUST write the file to
non-volatile storage as FILENAME.EXT (e.g. root.json).
-9. Repeat steps 5.3.1 to 5.3.8
+9. Repeat steps 5.3.2 to 5.3.9
10. **Check for a freeze attack.** The expiration timestamp in the
trusted root metadata file MUST be higher than the fixed update start time.
If the trusted root metadata file has expired, abort the update cycle,
report the potential freeze attack. On the next update cycle, begin at step
- 5.1 and version N of the root metadata file.
+ [[#update-root]] and version N of the root metadata file.
11. **If the timestamp and / or snapshot keys have been rotated, then delete the
trusted timestamp and snapshot metadata files.** This is done
@@ -1488,7 +1488,7 @@ it in the next step.
1. If this role has been visited before, then skip this role
(so that cycles in the delegation graph are avoided). Otherwise, if an
application-specific maximum number of roles have been visited, then go to
- step 5.6 (so that attackers cannot cause the client to waste excessive
+ step [[#fetch-target]] (so that attackers cannot cause the client to waste excessive
bandwidth or time). Otherwise, if this role contains metadata about the
desired target, then go to step [[#fetch-target]].
@@ -1564,7 +1564,7 @@ the latest trusted version) of the root metadata is available from the
repository. This ensures that an outdated client can always correctly
re-trace the chain of trust across multiple root key updates, even if the
latest set of root keys on the client dates back multiple root metadata
-versions. See step 5.2 of the client application workflow for more details.
+versions. See step [[#update-root]] of the client application workflow for more details.
Note that an attacker, who controls the repository, can launch freeze
attacks by withholding new root metadata. The attacker does not need to
@@ -1643,7 +1643,7 @@ so that outdated clients can update to the latest available root.
## Reading consistent snapshots ## {#reading-consistent-snapshots}
-See section 5 (The client application) for more details.
+See [[#detailed-client-workflow]] for more details.
# Future directions and open questions # {#future-directions-and-open-questions}