aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2020-10-20 12:37:43 +0200
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2020-10-20 12:37:43 +0200
commit5bc4f16f2fc367eb2758f258ccc50e6b0d84ee18 (patch)
tree52a09ed12ec47471e51315c62f2a21b54ffc0d5b /doc
parent2b317e65c193071e700297c6cdd3dcaecd479d38 (diff)
removed timestamp complexity
The metrics that one could derive can also be exported by the operator. It is probably good enough and does not justify complexity right now.
Diffstat (limited to 'doc')
-rw-r--r--doc/api.md20
1 files changed, 5 insertions, 15 deletions
diff --git a/doc/api.md b/doc/api.md
index 3118652..5347959 100644
--- a/doc/api.md
+++ b/doc/api.md
@@ -65,7 +65,7 @@ struct {
case signed_debug_info_v1: SignedDebugInfoV1;
case consistency_proof_v1: ConsistencyProofV1;
case inclusion_proof_v1: InclusionProofV1;
- case leaf_checksum_v1: LeafChecksumV1;
+ case checksum_v1: ChecksumV1;
} message;
} Item;
```
@@ -74,18 +74,16 @@ An `Item` can be serialized into an `ItemList` as described in RFC 6962/bis, see
[ยง6.2](https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis-34#section-6.2).
### Merkle tree leaf types
-In the future there will likely be several types of leaves. Say, one for
-operating system packages, another one for Debian packages, and a third one for
+In the future there might be several types of leaves. Say, one for operating
+system packages, another one for Debian packages, and a third one for
general-purpose checksums. For now we only define the latter.
#### Checksum
-A checksum entry contains a timestamp that corresponds to `UTC.now()`, a package
-identifier such as `foobar-1.2.3`, and an artifact hash that uses the log's
-configured hash function.
+A checksum entry contains a package identifier such as `foobar-1.2.3` and an
+artifact hash that uses the log's configured hash function.
```
struct {
- uint64 timestamp; // format defined by RFC 6962/bis, added by submitter
opaque package<0..2^8-1>; // package identifier
opaque checksum<32..2^8-1>; // artifact hash that used the log's hash func
} LeafChecksumV1;
@@ -97,14 +95,6 @@ update](https://wiki.mozilla.org/Security/Binary_Transparency). It is assumed
that the entities relying on the checksum type know how to find the artifact
source (if not already at hand) and then reproduce the logged hash from it.
-Note that the entry timestamp allows anyone to derive rough statistics on the
-time between submission and merge into the log's Merkle tree. Base such a diff
-on the first STH (timestamp) that incorporated a given entry.
-
-TODO: move timestamp outside of the (signed) structure that is submitted? It is
-less error-prone if the log does the time-stamping at its own discretion. E.g.,
-a `leaf_v1` that then switches onto a `checksum_v1`?
-
### Signed Debug Info
RFC 6962 uses Signed Certificate Timestamps (SCTs) as promises of public
logging within a time known as the Maximum Merge Delay (MMD). We provide no