diff options
| author | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-03-23 17:21:09 +0100 | 
|---|---|---|
| committer | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-03-23 17:21:09 +0100 | 
| commit | ca89938c9f72ed189a85b7de10f677aa85dd16d5 (patch) | |
| tree | 99346b2f0f5845b87995e30bcecca384cd3f930a | |
| parent | 7c08fc4667a56f1e630e382d7fa45b4edd5c2f0f (diff) | |
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.
| -rw-r--r-- | README.md | 14 | 
1 files changed, 7 insertions, 7 deletions
| @@ -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). | 
