aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-03-19 11:58:49 +0100
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-03-19 11:58:49 +0100
commit9a6407c0a96ee3b6f2915dab8ea333eb3f6c46f8 (patch)
tree86772cef2c1f774984831d03abe943d89754f394
parentb8e467f8533b9c0c73679b3569eae7cd28d20d41 (diff)
minor edits
-rw-r--r--README.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/README.md b/README.md
index 68533e6..e9a4713 100644
--- a/README.md
+++ b/README.md
@@ -53,13 +53,13 @@ Simply adding something into a transparency log is a great start that has merit
on its own. But, to make the most of a transparency log we should keep the
following factors in mind as the ecosystem bootstraps and develops:
1. Clients should verify that the signed checksums appear in a log. This
-requires inclusion proof verification. STFE forces this by never issuing
-so-called _promises to log_ as in [Certificate
+requires inclusion proof verification. STFE forces inclusion proof verification
+by not issuing _promises to log_ as in [Certificate
Transparency](https://tools.ietf.org/html/rfc6962).<sup>[2](#footnote-2)</sup>
2. Clients should verify that the log is append-only. This requires consistency
proof verification.
-3. Clients should verify they see the _same_ append-only log as everyone else.
-This requires a well-defined gossip-audit model.
+3. Clients should verify that they see the _same_ append-only log as everyone
+else. This requires a well-defined gossip-audit model.
The third point is often overlooked. While transparency logs are verifiable in
theory due to inclusion and consistency proofs, _it is paramount that the