From d543bd68ad5b5b885e9741584d7abb34652171f4 Mon Sep 17 00:00:00 2001 From: Rasmus Dahlberg Date: Wed, 17 Mar 2021 14:21:36 +0100 Subject: started polishing README --- README.md | 9 ++++----- 1 file 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 -- cgit v1.2.3