diff options
author | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-10-07 14:34:12 +0200 |
---|---|---|
committer | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-10-07 14:38:20 +0200 |
commit | acc5c838aa05ccfcd7bc7fd96a1342e803ebd88a (patch) | |
tree | 6f9edaeed7b4aca07a75bc74b11a02370614c10e /doc | |
parent | 5fc8464265c5ded36521504bf319753fac0d473d (diff) |
rephrased "the right data" pitch
There is a risk that "the right data" is confused with "what do you
mean, obviously it is the right data if there is a valid signature".
Tried just reword.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/claimant.md | 2 | ||||
-rw-r--r-- | doc/design.md | 4 |
2 files changed, 3 insertions, 3 deletions
diff --git a/doc/claimant.md b/doc/claimant.md index cfb6198..b11cd34 100644 --- a/doc/claimant.md +++ b/doc/claimant.md @@ -11,7 +11,7 @@ XXX: add more examples. System<sup>RB</sup> is about the claims made by a _software publisher_ that makes reproducible builds available. * **Claim<sup>RB</sup>**: - _I, software publisher, claim that the right opaque data_: + _I, software publisher, claim that the data_: 1. has cryptographic hash X 2. is the output of a reproducible build for which the source and relevant build-info information can be located in repository Y using X as an identifier diff --git a/doc/design.md b/doc/design.md index 4746e55..fca64ea 100644 --- a/doc/design.md +++ b/doc/design.md @@ -31,10 +31,10 @@ The signing party is called a _signer_. The user of the signed data is called a _verifier_. The problem with _just digital signing_ is that it is difficult to determine -whether the signed data is actually _the right data_. +whether the signed data is _actually the data that should have been signed_. How would we detect if a secret signing key got compromised? How would we detect if something was signed by mistake, or even worse, -if the signing party was forced to sign the wrong data against their will? +if the signing party was forced to sign malicious data against their will? Sigsum logs make it possible to answers these types of questions. The basic idea is to make a signer's _key-usage_ transparent. This is a powerful building |