diff options
| -rw-r--r-- | README.md | 30 |
1 files changed, 15 insertions, 15 deletions
@@ -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>: |