aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLinus Nordberg <linus@nordberg.se>2021-03-18 12:24:01 +0100
committerLinus Nordberg <linus@nordberg.se>2021-03-18 12:24:17 +0100
commitd67790456b9e11365795c912c3422fe250c3e5e6 (patch)
tree05571f05c0b672f9c61cfc1f4654cc0aa2a6354f
parentbddcc3d712c211418c6cb77584251273a2ba2181 (diff)
feedback not yet communicated elsewhere
-rw-r--r--README.md30
1 files changed, 15 insertions, 15 deletions
diff --git a/README.md b/README.md
index 896bea5..c5b65ba 100644
--- a/README.md
+++ b/README.md
@@ -15,13 +15,13 @@ secret signing key.
The log verifies that the entry is signed for the specified namespace but
nothing more than that. A client that wishes to enforce transparency logging
could require that, say, a valid Debian package is only used if its checksum
-appeared in the log with a correct identifier and namespace. Such a use-case
+appears in three logs with a correct identifier and namespace. Such a use-case
scenario enables us to:
1. **Facilitate detection of compromised signing keys**, e.g., a software
publisher can inspect the log to see if there are any unexpected checksums in
their own signing namespace(s).
2. **Ensure that everyone observe the same checksums**, e.g., there should never
-be two log entries with identical identifiers and namespaces but different
+be two log entries with identical identifiers and namespaces but with different
checksums.
## What has been done?
@@ -33,15 +33,15 @@ incomplete and subject to major revisions. For example, we are currently
thinking about data formats and which parsers are reasonable to (not) force onto
client-side tooling as well as server-side implementers and operators.
-There is a basic client (warning: _basic_) that can be used to interact with the
-log, e.g., to add-entries and verify inclusion proofs against an STH. We have
+There is a (very) basic client which can be used to interact with the
+log, e.g., to add entries and verify inclusion proofs against an STH. We have
yet to add client-side support for STFE's witness cosigning APIs. Witness
cosigning is part of the log's _gossip-audit model_, which must be well-defined
to keep the log honest.<sup>[1](#footnote-1)</sup>
-In the near future we will setup a public STFE prototype with zero promises of
+In the near future we will set up a public STFE prototype with zero promises of
uptime, stability, etc. In the meantime you may get your hands dirty by running
-things locally. Rough documentation is available
+STFE locally. Rough documentation is available
[here](https://github.com/system-transparency/stfe/blob/main/server/README.md).
## What should be considered?
@@ -50,17 +50,17 @@ 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. Client-side tooling should ultimately fail-close if a signed checksum is not
transparency logged. This requires a reliable and available log ecosystem.
-It is easier to achieve if there are multiple independent log operators.
-2. Client-side tooling should verify that the signed checksums appeared in the
-log. This requires inclusion proof verification. STFE forces it by never
+This is easier to achieve if there are multiple independent log operators.
+2. Client-side tooling should verify that the signed checksums appears in one
+or more logs. This requires inclusion proof verification. STFE forces this by never
issuing so-called _promises to log_ as in [Certificate
Transparency](https://tools.ietf.org/html/rfc6962).<sup>[2](#footnote-2)</sup>
3. Client-side tooling should verify that the log is append-only. This requires
consistency proof verification.
-4. Client-side tooling should be convinced that they see the same append-only
+4. Client-side tooling should convince themselves that they see the same append-only
log as everyone else. This requires a well-defined gossip-audit model.
-The final factor is often overlooked. While transparency logs are verifiable in
+That last point is often overlooked. While transparency logs are verifiable in
theory due to inclusion and consistency proofs, _it is paramount that the
different parties interacting with the log see the same entries and
cryptographic proofs_. Therefore, we built a proactive gossip-audit model
@@ -72,7 +72,7 @@ checksums) as everyone else.
Moreover, if you already rely on witness cosigning for security, all you need
from, say, a software publisher, is an artifact, a public verification key, a
-cosigned STH, and an inclusion proof that is based on it. That is excellent
+cosigned STH, and an inclusion proof up to that STH. That is excellent
because client-side verification becomes completely non-interactive!
##
@@ -85,9 +85,9 @@ Certificate Transparency. See, for example, the work of
<a name="footnote-2">2</a>:
So-called SCTs are signed promises that the log will merge a submitted entry
-within a Maximum Merge Delay (MMD), e.g., 24 hours. It is a significant system
-complexity because either the client needs to verify that these promises were
-honored after the MMD passed, or the client needs to trust that the logs are
+within a Maximum Merge Delay (MMD), e.g., 24 hours. This adds significant system
+complexity because the client needs to either verify that these promises were
+honored after the MMD has passed, or the client must trust that the log is
honest.
<a name="footnote-3">3</a>: