aboutsummaryrefslogtreecommitdiff
path: root/doc/design.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/design.md')
-rw-r--r--doc/design.md52
1 files changed, 41 insertions, 11 deletions
diff --git a/doc/design.md b/doc/design.md
index 401ba2e..2723ae8 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -334,13 +334,7 @@ The signing format for logs, witnesses, and signers is based on a subset of
what is supported by OpenSSH. Ed25519 and SHA256 must be used as primitives.
### 4 - Frequently Asked Questions
-#### 4.1 - What parts of the design are up for debate?
-A brief summary appeared in our archive on
- [2021-10-05](https://git.sigsum.org/sigsum/tree/archive/2021-10-05-open-design-thoughts?id=5c02770b5bd7d43b9327623d3de9adeda2468e84).
-It may be incomplete, but covers some details that are worth thinking more
-about. We are still open to remove, add, or change things.
-
-# 4.2 - Why use the OpenSSH signing format?
+#### 4.1 - Why use the OpenSSH signing format?
Our main criteria for a signing format is that it can express signing contexts
without any complex parsers. A magic preamble is good for overall hygiene
as well. We sketched on such a format using Trunnel. We realized that by
@@ -348,7 +342,7 @@ tweaking a few constants it would be compatible with SSH's signing format. If
it is possible to share format with an existing reliable and widely deployed
ecosystem, great!
-#### 4.3 - What is the point of submitting a checksum's preimage?
+#### 4.2 - What is the point of submitting a checksum's preimage?
Logging arbitrary bytes can poison a log with inappropriate content. While a
leaf is already light-weight in Sigsum, a stream of leaves could be made to carry more
meaning. Disallowing checksums to contain arbitrary bytes, by having logs compute
@@ -360,7 +354,7 @@ is `H(D)`. The resulting checksum would be `H(H(D))`. The log will not be in a
position to observe the data `D`, thereby removing power in the form of trivial
data mining while at the same time making the overall protocol less heavy.
-#### 4.4 - What is the point of having a domain hint?
+#### 4.3 - What is the point of having a domain hint?
Domain hints help log operators combat spam. By verifying that every signer
controls a domain name that is aware of their public key, rate limits can be
applied per second-level domain. You would need a large number of domain names
@@ -387,7 +381,7 @@ that added this criteria.
We are considering if additional anti-spam mechanisms should be supported in v1.
-#### 4.5 - What is the point of having a shard hint?
+#### 4.4 - What is the point of having a shard hint?
Unlike TLS certificates which already have validity ranges, a checksum does not
carry any such information. Therefore, we require that the signer selects a
shard hint. The selected shard hint must be within a log's shard interval.
@@ -414,7 +408,7 @@ A log operator that shuts down a completed shard will not affect end-users. In
other words, a signer can continue to distribute proofs that were once
collected. This is important because a checksum does not necessarily expire.
-#### 4.6 - What parts of witness cosigning are not done?
+#### 4.5 - What parts of witness cosigning are not done?
There are interesting policy aspects that relate to witness cosigning. For
example, what witnessing policy should an end-user use and how are trustworthy
witnesses discovered. This is somewhat analogous to a related policy question
@@ -435,6 +429,42 @@ the original proposal by
[Syta et al.](https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7546521),
which puts an authority right in the middle of a slowly evolving witnessing policy.
+#### 4.6 - What parts of the design are up for debate?
+Several parts are under consideration for the v1 design. Any feedback on what
+we have now or might (not) have in the future would be appreciated. We are not
+in any particular rush to bump the version and want to experiment more with v0.
+
+A list of some debated topics:
+
+ - Support any additional cryptographic algorithms? For example, is it a
+ worth-while complexity trade-off to add a NIST curve? Note that this question
+ is about cryptographic primitives; not additional signature formats like PGP.
+ - Accept or reject the [checkpoint format][] that the TrustFabric team uses
+ for (co)signed tree heads? It is also a relatively simple ASCII format, and
+ we support it as an experimental endpoint (`<log URL>/checkpoint`). The main
+ differences from our current cosigned tree head format are:
+ - The signed blob is not based on SSH
+ - Base64 instead of hex
+ - Extensibility in an "other data" section
+ - No timestamp verification without defining an extension
+ - A signature-line format that is less minimal
+ - Keep or remove tree head timestamps? A monitor can convince itself of
+ freshness by submitting a leaf request, observing that it gets merged by a
+ cosigned tree head. There are pros and cons, see [timestamp reflections][].
+ - Is it a worthwhile complexity trade-off to have a "quick" cosigned tree head
+ endpoint that provides cosignatures as fast as possible? Right now there is a
+ "slow" cosigned tree head endpoint that makes all cosignatures available at
+ once. The motivation for this is that a ["quick" endpoint adds complexity][]
+ while only giving _lower latency_; not _low latency_. The "slow" cosigned
+ tree head endpoint could also be implemented to just rotate a bit faster.
+ - Should there be support for any alternative rate-limiting mechanism? A
+ domain hint could be viewed as a subset of several possible _ownership hints_.
+ - Should there be any IANA registration for the future `_sigsum_v1` DNS label?
+
+[checkpoint format]: https://github.com/google/trillian-examples/blob/master/formats/log/README.md
+["quick" endpoint adds complexity]: https://git.sigsum.org/sigsum/tree/doc/proposals/2022-01-no-quick-tree-head-endpoint
+[timestamp reflections]: https://git.sigsum.org/sigsum/tree/archive/2022-02-08-timestamp-reflections.md
+
#### 4.7 - More questions
- What are the privacy concerns?
- Add more questions here!