aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-04-30 12:11:40 +0200
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-04-30 12:11:40 +0200
commit6cae1445318e22ce909b0211fc405dbeb6db7c44 (patch)
tree671df815a25f6f91cc6bbe415f33a9344619f78d
parent94fea7a3c993686d26efbf7ca9b73d598222a272 (diff)
fixed typos
-rw-r--r--doc/design.md14
1 files changed, 7 insertions, 7 deletions
diff --git a/doc/design.md b/doc/design.md
index 9fcf4b6..cb379e5 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -1,6 +1,6 @@
# System Transparency Logging: Design v0
We propose System Transparency logging. It is similar to Certificate
-Transparency, expect that cryptographically signed checksums are logged as
+Transparency, except that cryptographically signed checksums are logged as
opposed to X.509 certificates. Publicly logging signed checksums allow anyone
to discover which keys produced what signatures. As such, malicious and
unintended key-usage can be _detected_. We present our design and conclude by
@@ -31,7 +31,7 @@ is to facilitate detection of unwanted key-usage.
We consider a powerful attacker that gained control of a target's signing and
release infrastructure. This covers a weaker form of attacker that is able to
sign data and distribute it to a subset of isolated users. For example, this is
-essentially what FBI requested from Apple in the San Bernardino case [\[FBI-Apple\]](https://www.eff.org/cases/apple-challenges-fbi-all-writs-act-order).
+essentially what the FBI requested from Apple in the San Bernardino case [\[FBI-Apple\]](https://www.eff.org/cases/apple-challenges-fbi-all-writs-act-order).
The fact that signing keys and related infrastructure components get
compromised should not be controversial these days [\[SolarWinds\]](https://www.zdnet.com/article/third-malware-strain-discovered-in-solarwinds-supply-chain-attack/).
@@ -57,7 +57,7 @@ independent parties are adversarial.
It is a non-goal to disclose the data that a checksum represents. For example,
the log cannot distinguish between a checksum that represents a tax declaration,
an ISO image, or a Debian package. This means that the type of detection we
-support is more _course-grained_ when compared to Certificate Transparency.
+support is more _coarse-grained_ when compared to Certificate Transparency.
## Design
We consider a data publisher that wants to digitally sign their data. The data
@@ -69,7 +69,7 @@ signature tooling. The ecosystem at large can continue to use `gpg`, `openssl`,
We _have to assume_ that additional tooling can be installed by end-users that
wish to enforce transparency logging. For example, none of the existing
-signature tooling support verification of Merkle tree proofs. A side-effect of
+signature tooling supports verification of Merkle tree proofs. A side-effect of
our design is that this additional tooling makes no outbound connections. The
above data flows are thus preserved.
@@ -78,7 +78,7 @@ A central part of any transparency log is the data. The data is stored by the
leaves of an append-only Merkle tree. Our leaf structure contains four fields:
- **shard_hint**: a number that binds the leaf to a particular _shard interval_.
Sharding means that the log has a predefined time during which logging requests
-will be accepted. Once elapsed, the log can be shutdown.
+will be accepted. Once elapsed, the log can be shut down.
- **checksum**: a cryptographic hash of some opaque data. The log never
sees the opaque data; just the hash.
- **signature**: a digital signature that is computed by the data publisher over
@@ -166,7 +166,7 @@ benign witness will only sign the log's tree head if it is consistent with prior
history.
#### Summary
-The log is sharded and will shutdown at a predefined time. The log can shut
+The log is sharded and will shut down at a predefined time. The log can shut
down _safely_ because end-user verification is not interactive. The difficulty
of bypassing public logging is based on the difficulty of controlling a
threshold of independent witnesses. Witnesses cosign tree heads to make them
@@ -178,7 +178,7 @@ End-users interact with the log _indirectly_ via a data publisher. It is the
data publisher's job to log signed checksums, distribute necessary proofs of
logging, and monitor the log.
-### A peak into the details
+### A peek into the details
Our bird's view introduction skipped many details that matter in practise. Some
of these details are presented here using a question-answer format. A
question-answer format is helpful because it is easily modified and extended.