diff options
| author | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-03-17 14:21:36 +0100 |
|---|---|---|
| committer | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-03-17 14:21:36 +0100 |
| commit | d543bd68ad5b5b885e9741584d7abb34652171f4 (patch) | |
| tree | 063f1bbba235c1b668fcf0236e8dfa53140385ea | |
| parent | 838e268e6563f9d361497ce7cab82545d69cff66 (diff) | |
started polishing README
| -rw-r--r-- | README.md | 9 |
1 files changed, 4 insertions, 5 deletions
@@ -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 |