aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/design.md28
1 files changed, 10 insertions, 18 deletions
diff --git a/doc/design.md b/doc/design.md
index e2c0f8d..1179489 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -185,7 +185,8 @@ less costly to bootstrap into a reliable log ecosystem.
## 3 - Design
We consider a _claimant_ that claims to distribute the _right_ opaque data with
cryptographic hash X. A claimant may add additional falsifiable claims.
-However, all claims must be digitally signed to ensure non-repudiation [\[CM\]](https://github.com/google/trillian/blob/master/docs/claimantmodel/CoreModel.md).
+However, all claims must be digitally signed to ensure non-repudiation
+ [\[CM\]](https://github.com/google/trillian/blob/master/docs/claimantmodel/CoreModel.md).
A user should only use the opaque data if there is reason to _believe_ the
claimant's claims. Therefore, users are called _believers_. A good first step
@@ -307,7 +308,7 @@ an inclusion proof leads up to. Sigsum logs have trustworthy tree heads due
to using a variant of witness cosigning. A believer can not be tricked into
accepting some opaque data that have yet to be publicly logged unless the
attacker controls more than a threshold of witnesses. In other words, witnesses
-are trust anchors that ensure verifiers see the same sigsum statements as
+are trust anchors that ensure verifiers see the same signed statements as
believers.
Sigsum logging can facilitate detection of attacks even if a believer fails open
@@ -316,10 +317,10 @@ repository mirror does not serve proofs of public logging could indicate that
there is an ongoing attack against a claimant's distributed infrastructure.
Interested parties can look for that.
-_Monitoring_ -- as in inspecting the log for sigsums that interest you -- can be
-viewed as a separate 4th step. A monitor implements the verifier role and is
-necessarily ecosystem specific. For example, it requires knowledge of public
-verification keys, what the opaque data is, and where the opaque data is
+_Monitoring_ -- as in inspecting the log for signed statements that interest you
+-- can be viewed as a separate 4th step. A monitor implements the verifier role
+and is necessarily ecosystem specific. For example, it requires knowledge of
+public verification keys, what the opaque data is, and where the opaque data is
located.
### 3.2 - Summary
@@ -332,18 +333,9 @@ tree head is correct before cosigning.
Claimants, verifiers, and witnesses interact with the log using an HTTP(S) API.
A claimant must prove that they own a domain name as an anti-spam mechanism.
Believers interact with the log _indirectly_ through their claimant's existing
-distribution mechanism. It is the claimant's job to log sigsums and distribute
-necessary proofs of public logging. It is the verifier's job to look for new
-statements in the log and alert an arbiter if any claim is false.
-
-An overview of the entire system is provided in Figure 2.
-```
-TODO: add complete system overview. See drafty figure in archive.
-- Make terminology consistent with Figure 1
-- E.g., s/Monitor/Verifier
-- E.g., s/leaves/statements
-- Add arbiter
-```
+distribution mechanism. It is the claimant's job to log signed statements and
+distribute necessary proofs of public logging. It is the verifier's job to look
+for new statements in the log and alert an arbiter if any claim is false.
### 4 - A peek into the details
Our bird's view introduction skipped many details that matter in practise. Some