aboutsummaryrefslogtreecommitdiff
path: root/doc/design.md
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-05-01 19:39:45 +0200
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-05-01 19:39:45 +0200
commite61bd2fb0e845eeef11b1825fdbc5e5c52fb2ec5 (patch)
tree409cb09976d0caef628aca18661a73bccb74db95 /doc/design.md
parentf649f2715dc6c4c7f45116b83a6347a08d7193b4 (diff)
added context regarding the supported cryptographic primitives
Diffstat (limited to 'doc/design.md')
-rw-r--r--doc/design.md49
1 files changed, 28 insertions, 21 deletions
diff --git a/doc/design.md b/doc/design.md
index 2836364..91de288 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -183,32 +183,39 @@ question-answer format is helpful because it is easily modified and extended.
#### What cryptographic primitives are supported?
The only supported hash algorithm is SHA256. The only supported signature
-scheme is Ed25519. Not having any cryptographic agility makes the protocol
-less complex and more secure.
-
-An immediate follow-up question is how that is supposed to work with existing
-and future signature tooling. The key insight is that _additional tooling is
-already required to verify Merkle tree proofs. That tooling should use SHA256.
-That tooling should also verify all Ed25519 signatures that logs, witnesses, and
-data publishers create_.
-
-For example, suppose that an ecosystem uses `gpg` which has its own incompatible
-signature format and algorithms. The data publisher could _cross-sign_ using
-Ed25519 as follows:
-1. Sign the opaque data as you normally would with `gpg`.
+scheme is Ed25519. Not having any cryptographic agility makes the protocol less
+complex and more secure.
+
+We can be cryptographically opinionated because of a key insight. Existing
+signature tools like `gpg`, `ssh-keygen -Y`, and `signify` cannot verify proofs
+of public logging. Therefore, _additional tooling must already be installed by
+end-users_. That tooling should verify hashes using the log's hash function.
+That tooling should also verify signatures using the log's signature scheme.
+Signed messages include tree heads as well as tree leaves.
+
+#### Why not let the data publisher pick their own signature scheme and format?
+Agility introduces complexity and difficult policy questions. For example,
+which algorithms and formats should (not) be supported and why? Picking Ed25519
+is a current best practise that should be encouraged if possible.
+
+There is not much we can do if a data publisher _refuses_ to rely on the log's
+hash function or signature scheme.
+
+#### What if the data publisher must use a specific signature scheme or format?
+You may _cross-sign_ the data as follows.
+1. Sign the opaque data as you normally would.
2. Hash the opaque data and use that as the leaf's checksum. Sign the leaf
-using Ed25519.
+using the log's signature scheme.
-First the end-user verifies that the `gpg` signature is valid. This is the
-old verification process. Then the end-user uses the additional tooling to
-verify proofs of logging, which involves SHA256 hashing and Ed25519 signatures.
-
-The downside is that the data publisher may need to manage an Ed25519 key _as
-well_. TODO: motivate why that is a suboptimal but worth-while trade-off.
+First the end-user verifies that the normal signature is valid. Then the
+end-user lets the additional tooling (that is already required) verify the rest.
+Cross-signing should be a relatively comfortable upgrade path that is backwards
+compatible. The downside is that the data publisher may need to manage an
+additional key-pair.
#### What (de)serialization parsers are needed?
-#### Why witness cosigning?
#### What policy should be used?
+#### Why witness cosigning?
#### TODO
Add more key questions and answers.