persisted pads from meeting minutes

2 files changed, 81 insertions, 0 deletions

diff --git a/archive/2022-02-08-timestamp-reflections.md b/archive/2022-02-08-timestamp-reflections.md
new file mode 100644
index 0000000..9cd4c46
--- /dev/null
+++ b/archive/2022-02-08-timestamp-reflections.md
@@ -0,0 +1,60 @@
+# Timestamp reflections
+## Introduction
+Sigsum logs sign tree heads that contain timestamps.  Witnesses must not cosign
+a tree head unless the timestamp is fresh.  The original motivation to have a
+timestamp was to ensure that monitors could be convinced of freshness.  This
+document provides some of our latest insights on the why (not) of timestamps.
+
+## Background
+A witness must only cosign a tree head if it is fresh and append-only.  The
+freshness criteria is defined as "not older than five minutes".  This means that
+logs and witnesses are assumed to be configured with some kind of rough time.
+
+Simply removing the freshness check would introduce the risk of slow-down
+attacks against monitors.  See [past documentation][] on how that works.
+
+[past documentation]: https://git.sigsum.org/sigsum/tree/archive/2021-08-24-checkpoint-timestamp
+
+## Freshness without timestamps
+Assume that a witness only cosigns a tree head if the current tree size is
+larger or equal to the previous tree size.  A different way to approach
+freshness for monitors without appealing to reactive gossip is as follows.
+
+ 1.  Every X time units, submit an entry for logging.
+ 2.  Check that the submitted entry gets merged in the next cosigned tree head,
+ and that the cosigned tree head has enough cosignatures to be trusted.
+
+A monitor can conclude that at the time its latest entry got merged into the
+log, there cannot be any other outstanding entries unless there is a split-view.
+A split-view is not possible unless the witnessing assumptions is wrong.  So,
+within our threat model this can prevent a slow-down attack without timestamps.
+
+The downside is that monitors must submit entries periodically to repeatedly
+convince themselves of freshness.  It does not preclude the idea, but does not
+necessarily work if the same cosigned tree head format is used elsewhere.  For
+example, a [serverless transparency log][] might not want to allow write-access
+to each and every monitor.  A different approach towards freshness is needed.
+
+[serverless transparency log]: https://github.com/google/trillian-examples/blob/master/serverless/README.md
+
+## Other timestamping arguments
+An interesting property from having witness-verified timestamps is that a clock
+can be set roughly by doing the above submission trick once at start-up.  A
+system that already relies on witnesses for append-only logs can get rough time.
+
+An interesting side-effect of witness-verified timestamps is that the setup as a
+whole results in a distributed timestamping service.  It is easy to get excited
+about this property.  It is not a strict Sigsum criteria, however.
+
+ 1. Get the current cosigned tree head `X`.
+ 2. Log an entry `E`.  Leaf index will be larger or equal to `X.tree_size`.
+ 3. Get inclusion proof to a newer cosigned tree head `Y`.
+ 4. Now a third-party that be convinced that `E` was logged in the interval
+ `[X.timestamp, Y.timestamp]`.
+
+(A bit-for-bit duplicated entry should be considered log misbehavior.)
+
+Some policy aspects could become easier with timestamps, such as "witness W
+should not be trusted for timestamps after time T".  The same statement can be
+stated without time though: "witness W should not be trusted after tree size N".
+The difference is that a timestamp works for all logs; tree sizes are per-log.
diff --git a/doc/proposals/2022-02-end-user-terminology.md b/doc/proposals/2022-02-end-user-terminology.md
new file mode 100644
index 0000000..9b6df79
--- /dev/null
+++ b/doc/proposals/2022-02-end-user-terminology.md
@@ -0,0 +1,21 @@
+# Background
+We are not entirely happy with the terminology "signer" and "verifier", see
+[earlier proposal][] and [meeting minutes][].  At a first glance "author" seemed
+like a good abstract description.  More work was needed to replace "verifier".
+
+[earlier proposal]: https://git.sigsum.org/sigsum/tree/doc/proposals/2022-01-author-reader-terminology
+[meeting minutes]: https://git.sigsum.org/sigsum/tree/archive/2022-01-18--meeting-minutes
+
+# Proposal
+1. Keep the terminology "signer".
+2. Replace "verifier" with "end-user"
+
+The motivation for keeping "signer" is that it feels natural when we have
+conversations about Sigsum.  The other natural term for the party which will use
+the signed data in the end is "user".  We often say "end-user" for emphasis.
+
+# Notes
+Signer will continue to be overloaded.  We should be upfront about this where
+there is risk for confusion (logs and witnesses are also signers of tree heads).
+
+Not introducing abstract terminology unless it is needed is likely a win.