diff options
| author | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-03-19 11:58:49 +0100 |
|---|---|---|
| committer | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-03-19 11:58:49 +0100 |
| commit | 9a6407c0a96ee3b6f2915dab8ea333eb3f6c46f8 (patch) | |
| tree | 86772cef2c1f774984831d03abe943d89754f394 | |
| parent | b8e467f8533b9c0c73679b3569eae7cd28d20d41 (diff) | |
minor edits
| -rw-r--r-- | README.md | 8 |
1 files changed, 4 insertions, 4 deletions
@@ -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 |