aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-03-17 14:21:36 +0100
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-03-17 14:21:36 +0100
commitd543bd68ad5b5b885e9741584d7abb34652171f4 (patch)
tree063f1bbba235c1b668fcf0236e8dfa53140385ea
parent838e268e6563f9d361497ce7cab82545d69cff66 (diff)
started polishing README
-rw-r--r--README.md9
1 files changed, 4 insertions, 5 deletions
diff --git a/README.md b/README.md
index dfea8b9..6096bf0 100644
--- a/README.md
+++ b/README.md
@@ -20,10 +20,9 @@ never be two signed checksum entries with identical identifiers and namespaces
but different checksums.
The scope of STFE should not be confused with properties such as _prevention_ or
-even _recovery_ after detection. We are in the business of making things
-transparent and _that is it_.
+even _recovery_ after detection.
-## What does it take to make an artifact public?
+## Gossip-audit model
We glanced over the term _public trace_ a bit to quickly before. Simply adding
something into a transparency log serves a limited purpose unless (i) clients
_fail-close_ if an artifact does not appear in a log, and (ii) everyone observes
@@ -40,8 +39,8 @@ parties signed-off the log's cryptographic state, you can be pretty sure that
you see the same log (and thus the same artifacts) as everyone else. Moreover,
if you already rely on witness cosigning for security, all you need from your
software publisher is an artifact, a public verification key, a cosigned
-STH, and an inclusion proof that is based on it. Let me clarify why that is
-excellent: client-side verification becomes completely non-interactive!
+STH, and an inclusion proof that is based on it. That is excellent because
+client-side verification becomes completely non-interactive!
## What has been done?
STFE is in a proof-of-concept stage. We have a