aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLinus Nordberg <linus@nordberg.se>2021-10-12 14:18:55 +0200
committerLinus Nordberg <linus@nordberg.se>2021-10-12 14:18:55 +0200
commit8218cefd1b0789807208f01df3e2a382748cb371 (patch)
tree15c9527cbd09c2065b860796f1f52b5b4736838c
parent4912cd5813e1ce69c3d8c5a95d91a78f70d92172 (diff)
minor wording
-rw-r--r--doc/design.md12
1 files changed, 6 insertions, 6 deletions
diff --git a/doc/design.md b/doc/design.md
index 1117f02..0393a91 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -231,7 +231,7 @@ since the data structures being exchanged are primitive enough.
The signer submits their shard hint, checksum, signature, public verification
key and domain hint as ASCII key-value pairs. The log verifies that the public
verification key is present in DNS and uses it to check that the signature is
-valid, then hashes it to constructs the Merkle tree leaf as described in
+valid, then hashes it to construct the Merkle tree leaf as described in
Section 3.1.
When a submitted logging request is accepted, the log _tries_ to incorporate the
@@ -279,7 +279,7 @@ refers to the collection of an inclusion proof and a cosigned tree head.
#### 3.2.5 - Verification
A verifier should only accept the distributed data if the following criteria hold:
1. The data's checksum and shard hint are signed using the specified public key.
-2. The provided tree head can be reconstructed from the logged leaf and
+2. The provided tree head can be reconstructed from the logged leaf and
its inclusion proof.
3. The provided tree head is from a known log with enough valid cosignatures.
@@ -309,7 +309,7 @@ An often overlooked step is that transparency logging falls short if no-one
keeps track of what appears in the public logs. Monitoring is necessarily
use-case specific in sigsum. At a minimum, monitors need to locate relevant
public keys. They may also need to be aware of how to locate the data that
-found checksums represent.
+logged checksums represent.
### 3.3 - Summary
Sigsum logs are sharded and shut down at predefined times. A sigsum log can
@@ -357,7 +357,7 @@ set it as large as possible. If a verified timestamp is needed to reason about
the time of logging, you may use a cosigned tree head instead
[\[TS\]](https://git.sigsum.org/sigsum/commit/?id=fef460586e847e378a197381ef1ae3a64e6ea38b).
-A log operator that shuts down a completed shard will not effect verifiers. In
+A log operator that shuts down a completed shard will not affect verifiers. In
other words, a signer can continue to distribute proofs that were once
collected. This is important because a checksum does not necessarily expire.
@@ -369,7 +369,7 @@ to spam a log in any significant way if rate limits are not set too loose.
Notice that the effect of spam is not only about storage. It is also about
merge latencies. Too many submissions from a single party may render a log
-unusable for others. This kind of incident happened in the real-world already
+unusable for others. This kind of incident happened in the real world already
[\[Aviator\]](https://groups.google.com/a/chromium.org/g/ct-policy/c/ZZf3iryLgCo/m/rdTAHWcdBgAJ).
Using DNS as an anti-spam mechanism is not a perfect solution. It is however
@@ -382,7 +382,7 @@ management. Our work is about transparent _key-usage_.
We are considering if additional anti-spam mechanisms should be supported.
-#### 4.4 - Is witness cosigning done?
+#### 4.4 - Are you done with the witness cosigning design?
There are interesting policy aspects that relate to witness cosigning. For
example, what witnessing policy should a verifier use and how are trustworthy
witnesses discovered. This is somewhat analogous to a related policy question