From 5bc4f16f2fc367eb2758f258ccc50e6b0d84ee18 Mon Sep 17 00:00:00 2001
From: Rasmus Dahlberg <rasmus.dahlberg@kau.se>
Date: Tue, 20 Oct 2020 12:37:43 +0200
Subject: 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.
---
doc/api.md | 20 +++++---------------
1 file 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
--
cgit v1.2.3