From ca89938c9f72ed189a85b7de10f677aa85dd16d5 Mon Sep 17 00:00:00 2001 From: Rasmus Dahlberg Date: Tue, 23 Mar 2021 17:21:09 +0100 Subject: fixed README.md nits (#2) Tried to emphasize that an entry's checksum and identifier are signed, and that we are really referring to a cryptographic signature. --- README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 7389acb..2d5ba5c 100644 --- a/README.md +++ b/README.md @@ -6,16 +6,16 @@ the submitter. For example, it could be a Firefox update, a Debian package, or a document. A log leaf contains: - A _checksum_ that represents a data item of opaque type. - An _identifier_ that is tied to what the checksum represents. -- A _signature_ that covers `checksum` and `identifier` using the submitter's -secret signing key. +- A _signature_ over `checksum` and `identifier` using the submitter's secret +signing key. - A _namespace_ that is tied to the submitter's verification key, e.g., think of it as a hashed public 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 -appears in the log with a correct namespace and identifier. Such a use-case -scenario enables us to: +The log only verifies that an entry's checksum and identifier are +cryptographically signed based on the specified namespace. A client that wishes +to enforce transparency logging could require that, say, a valid Debian package +is only used if its checksum appears in the log with a correct namespace and +identifier. This allows 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). -- cgit v1.2.3