aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/design.md71
1 files changed, 34 insertions, 37 deletions
diff --git a/doc/design.md b/doc/design.md
index 494604f..c9659d5 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -148,49 +148,47 @@ attacks. A log operator can at best deny service with these assumptions.
An overview of sigsum logging is shown in Figure 1. Before going into detail
we give a brief primer below.
```
- +----------+
-checksum +----------| Signer |-----------+ data
-metadata | +----------+ | metadata
- | ^ | proof
- v | v
- +---------+ proof | +--------------+
- | Log |----------+ | Distribution |
- +---------+ +--------------+
- ^ | checksum | |
- | | metadata | |data
- | | proof +---------+ data | |metadata
- | +---------->| Monitor |<-------+ |proof
- v +---------+ v
- +---------+ | +----------+
- | witness | | false | Verifier |
- +---------+ | claim +----------+
- v
- investigate
-
- Figure 1: system overview
+ +----------+
+ checksum +----------| Signer |-----------+ data
+ metadata | +----------+ | metadata
+ | ^ | proof
+ v | v
+ +-----+ H(vk) +---------+ proof | +--------------+
+ | DNS |------>| Log |----------+ | Distribution |
+ +-----+ +---------+ +--------------+
+ ^ | checksum | |
+ | | metadata | |data
+ | | proof +---------+ data | |metadata
+ | +---------->| Monitor |<-------+ |proof
+ v +---------+ v
+ +---------+ | +----------+
+ | witness | | false | Verifier |
+ +---------+ | claim +----------+
+ v
+ investigate
+
+ Figure 1: system overview
```
A signer wants to make their key-usage transparent. Therefore, they sign a
statement that sigsum logs accept. That statement encodes a checksum of some
data. Minimal metadata must also be logged, such as the checksum's signature
-and a hash of the public verification key. This ensures that every signed
-checksum can be attributed to the signing party if you know their key.
+and a hash of the public verification key. A hash of the public verification
+key is configured in DNS as a TXT record to help log operators combat spam.
-The signing party waits for their submission to be included in the log. When
-there is an inclusion proof available that leads up to a cosigned Merkle tree
-head, the checksum's data is ready for distribution with proofs of logging.
+The signing party waits for their submission to be included in the log. When an
+inclusion proof is available that leads up to a trustworthy Merkle tree head,
+the signed checksum's data is ready for distribution with proofs of public
+logging. A sigsum log does not help the signer with any data distribution.
-These proofs are convincing for a verifier without any outbound network
-connections if a threshold of witnesses followed a basic cosigning protocol.
-Additional detail is provided in Section 3.2.3.
+Verifiers use the signer's data if it is accompanied by proofs of public
+logging. Monitors look for signed checksums and data that correspond to public
+keys that they are aware of. Any falsifiable claim that a signer makes about
+their key-usage can now be verified because no signing operation goes unnoticed.
-Asynchronously, use-case specific monitors look for signed checksums that
-correspond to public keys that they are aware of. Monitors and verifiers
-rely on witness cosigning to be sure that they see the same append-only logs.
-
-Use-case specific monitors may verify the underlying data further by looking it
-up in the same way that a verifier does. If the data cannot be found or if a
-claimed property is false, that can be detected and investigated. Excellent!
+Verifiers and monitors can be convinced that public logging happened without
+additional outbound network connections if a threshold of witnesses followed a
+cosigning protocol. More detail is provided in Section 3.2.3.
### 3.1 - Merkle tree
A sigsum log maintains a public append-only Merkle tree. Independent witnesses
@@ -229,8 +227,7 @@ replayed in a non-overlapping shard by a good Samaritan.
The signer also has to do a one-time DNS setup. As outlined below, logs will
check that _some domain_ is aware of the signer's verification key. This is
-part of a defense mechanism that helps us combat log spam. It was not shown in
-Figure 1 to avoid it from being overly cluttered. XXX: should be added?
+part of a defense mechanism that helps us combat log spam.
#### 3.2.2 - Submit request
Sigsum logs implement an HTTP(S) API. Input and output is human-readable and