aboutsummaryrefslogtreecommitdiff
path: root/archive
diff options
context:
space:
mode:
Diffstat (limited to 'archive')
-rw-r--r--archive/2022-01-18-future-website-sketch97
-rw-r--r--archive/2022-01-18-proposal-author-reader-terminology41
-rw-r--r--archive/2022-01-18-proposal-log-url26
-rw-r--r--archive/2022-01-18-tree-head-endpoint-observations105
4 files changed, 269 insertions, 0 deletions
diff --git a/archive/2022-01-18-future-website-sketch b/archive/2022-01-18-future-website-sketch
new file mode 100644
index 0000000..c21a540
--- /dev/null
+++ b/archive/2022-01-18-future-website-sketch
@@ -0,0 +1,97 @@
+Sketch on an updated www.sigsum.org site, feedback wanted. The goal is to know
+roughly what content we want here eventually, and who that content should be
+for.
+
+We will use this as input for a web developer that will fix a Hugo template
+tailored for Sigsum. The resulting template should be free and open-source
+licensed.
+
+Target audience?
+---
+Somewhat prioritized list:
+ 1. New users, early adopters, and contributors
+ * "The why and how of Sigsum logging"
+ * "How to get started and/or involved"
+ 1. (Non-)technical decisions makers
+ * "We want there to be decisions to apply Sigsum in the real world"
+ 1. Journalists and bloggers
+ * "We want to make it easier to bring Sigsum into the conversation"
+ 1. Technical experts and academics
+ * "Point me to the stuff"
+ 1. Existing users and contributors
+ * "Mostly for reference and navigation to the right place"
+ * "Probably don't need to access our website that much"
+
+Aim for the overall feeling of "not so dense", "inclusive", and "community".
+
+Website content?
+---
+ * What is Sigsum, the technology?
+ * What is Sigsum useful for?
+ * How does it work?
+ * How can I try it out?
+ * How can I get involved?
+ * Who is behind Sigsum, the project?
+ * FAQ
+
+Top-most navigation?
+---
+A first take based on the above could be:
+ * Landing page
+ * Applications (of the technology)
+ * Documentation
+ * Ecosystem
+ * About
+
+Landing page
+ * One liner
+ * Example
+ * "A free and open source software project that brings transparency to
+ cryptographic key-usage"
+
+Applications
+ * An enumeration that provides an overview of several "items" containing
+ * Title
+ * Optional figure
+ * 1-3 lines summary
+ * Read more button
+ * Keep it short and down to the point
+ * What is the problem that Sigsum addresses
+ * What assumptions are required for the above
+ * (Not: "this is how it works in detail", just aim to gauge interest)
+ * Two examples of topics to be enumerated
+ * "Digital Signatures" / "Signature Transparency"
+ * "Executable Binaries" / "Binary Transparency"
+
+Documentation
+ * Same type of enumeration as for "Applications"
+ * Examples:
+ * "How it works"
+ * "Getting started"
+ * "Frequently asked questions"
+ * "Technical documentation", redirect/pointers to git's doc folder
+
+Ecosystem
+ * A paragraph of introtext, followed by an enumeration?
+ * "The great folks/orgs running logs, witnesses, monitors, etc"
+ * Credit: https://certificate.transparency.dev/ does this very nicely.
+
+About
+ * Team Sigsum, who are the core people driving the project forward
+ * Vision / values
+ * Sponsors (maybe "enumeration" as described above is appropriate)
+
+Misc
+---
+Eventually we might want a blog. Would that be blog.sigsum.org, linked from doc
+page?
+
+Have not worked in where the 'how to get in touch part' should be. Would be
+nice if the following are easily accessible / discoverable:
+ * irc
+ * matrix
+ * mailing list
+ * weekly Jitsi meets
+
+Would be nice if every page could have a natural "get involved button". Think
+"Add your use-case", "Add your sigsum log", etc.
diff --git a/archive/2022-01-18-proposal-author-reader-terminology b/archive/2022-01-18-proposal-author-reader-terminology
new file mode 100644
index 0000000..fb447d2
--- /dev/null
+++ b/archive/2022-01-18-proposal-author-reader-terminology
@@ -0,0 +1,41 @@
+Start using the terminology "author" and "reader" proposal
+
+Background
+---
+Figure 1 in doc/design.md refers to
+
+ a) the party producing a signed checksum as "Signer", and
+ b) the party verifying a signed checksum as "Verifier".
+
+This is fine in isolation, but less appropriate when looking at it from a
+broader Sigsum perspective. For example, a "Signer" may also be a "Submitter".
+It seems like we are mixing terminology for roles and concrete actors here.
+
+The above is also ambiguous. For example, logs and witnesses sign things;
+witnesses and monitors verify things.
+
+Proposal
+---
+1) Replace "Signer" with "Author" when we are talking about a concrete party.
+
+According to Wikipedia's definition (https://en.wikipedia.org/wiki/Author), an
+'author is "the person who originated or gave existence to anything" and whose
+authorship determines responsibility for what was created'. This seems
+appropriate for us.
+
+The term "author" has been used in academic litterature before us for similar
+purposes:
+ * "In the setting of transparency logging [18] as depicted in Fig. 1, the
+ author generates events intended for recipients that describe data
+ processing by the author as it takes place"
+ * Link to paper: https://link.springer.com/chapter/10.1007/978-3-319-45741-3_7
+
+2) Replace "Verifier" with "Reader" when we are talking about a concrete party.
+
+According to Wikipedia's definition (https://en.wikipedia.org/wiki/Reading),
+"[r]eading is the process of taking in the sense or meaning of letters, symbols,
+etc., especially by sight or touch". Although the latter is not a perfect
+description for us, the first part is quite close and we could argue that we are
+in the "etc" category.
+
+The main idea here is that it should feel intuitive that an author has readers.
diff --git a/archive/2022-01-18-proposal-log-url b/archive/2022-01-18-proposal-log-url
new file mode 100644
index 0000000..598fb43
--- /dev/null
+++ b/archive/2022-01-18-proposal-log-url
@@ -0,0 +1,26 @@
+Redefine "base URL" as "log URL" proposal
+
+Background
+---
+The current api.md specification requires that a log has a fixed unique "base
+URL". It is any valid HTTP(S) URL that can end with "/sigsum/v0/<endpoint>".
+
+Proposal
+---
+Remove the term "base URL" and instead define "log URL". A log URL is a valid
+HTTP(S) URL that ends with "/sigsum/v0/". Example of a valid log URL:
+
+ https://example.com:4711/opposum/sigsum/v0/
+
+This means that a named sigsum endpoint can be appended to a log's URL. For
+example, if the endpoint is "get-tree-head-quickly" the resulting "endpoint URL"
+would be:
+
+ https://example.com:4711/opposum/sigsum/v0/get-tree-head-quickly/
+
+And with input parameters for "get-leaves":
+
+ https://example.com:4711/opposum/sigsum/v0/get-leaves/42/4711/
+
+Note the final slash in all of the above URLs. Should that be enforced (?).
+ * XXX: Need to check in URL specification(s). Defer for now.
diff --git a/archive/2022-01-18-tree-head-endpoint-observations b/archive/2022-01-18-tree-head-endpoint-observations
new file mode 100644
index 0000000..f2d71d7
--- /dev/null
+++ b/archive/2022-01-18-tree-head-endpoint-observations
@@ -0,0 +1,105 @@
+Warning: there are no concrete proposed decisions based on the below yet, but
+see the concluding remarks at the end for some hints of what we should be
+discussing together.
+
+Observation about tree head endpoints
+---
+There are two ways to get cosigned tree heads:
+ * get-tree-head-quickly (dynamic list of cosignatures)
+ * get-tree-head-slowly (fixed list of cosignatures)
+ * See: https://git.sigsum.org/sigsum/commit/?h=rgdd/proposals&id=6032a39003a4f49710b60fe3087b01d58cadc837
+
+The idea is that the slow endpoint is updated once all cosignatures are
+available, thus moving "slowly" every five minutes. Cosignatures on the quick
+endpoint are in contrast added as soon as they become available, which means
+that it moves more "quickly".
+
+An interesting observation is that there is nothing in api.md that prevents a
+log from updating their get-tree-head-slowly endpoint every minute, for example.
+The only restriction that we impose is that witnesses will not cosign unfresh
+timestamps (5m), and we recommend (or plan to recommend) that witnesses poll the
+logs ~every minute.
+
+A smart log implementation (yes, scary, but hear the idea out) could notice that
+all witnesses that are likely to add their cosignatures already did so. This
+means that it would not be completely unreasonable to just rotate the log's tree
+head "early".
+
+This begs the question if we should consider dropping the get-tree-head-quickly
+endpoint. It would move logic "to be fast" into the log rather than into
+tooling.
+
+Or alternatively, if we should consider tighting up api.md to preclude the
+above. See below for examples of how the slow endpoint could be more rapid with
+today's spec.
+
+Example
+---
+Suppose a log configured a set of witness public keys. Also define a witness as
+active if any of the last 12 tree heads were cosigned. (The magic number 12 is
+an example.)
+
+A rotation policy could be:
+ 1. If there are no active witnesses, always wait the full five minutes.
+ 2. Otherwise
+ 2.1. Always wait at least one minute.
+ 2.2. Always wait at most five minutes.
+ 2.3. Rotate early if 90% of all active witnesses provided their
+ cosignatures. (The magic number 90% is an example.)
+
+Criteria 2.1. ensures that any witness that polls the log every minute is likely
+to get there cosignature into the next cosigned tree head.
+
+Criteria 2.2. ensures that a few erratic witnesses that only sometimes cosign
+will not slow down the overall pace of moving forward roughly ~every minute.
+
+Criteria 2.3. ensures that tree heads with too few cosignatures are not rotated
+prematurely.
+
+Example
+---
+Suppose a log configured a set of witness public keys.
+
+A rotation policy could be:
+ 1. If the last tree head did not get cosigned by anyone, always wait five
+ minutes.
+ 2. If the last tree head got cosigned by a non-empty set of witnesses W:
+ 2.1. Always wait at least one minute before rotating
+ 2.2. Always wait at most five minutes
+ 2.3. Rotate early if cosignatures were received from all witnesses in W.
+ 3. XXX: a criteria to exclude erratic witnesses, e.g., "if you're part of W
+ and don't provide a cosignature we will not wait for you during the next
+ hour" or similar.
+
+Concluding remarks
+---
+It is a fair assumption to assume that witnesses poke the log ~every minute. It
+is less clear if it is a good idea to also require proof fetching and signature
+operations that often. Maybe we have already struck a good balance if we say
+that logs SHOULD NOT rotate faster than five minutes, but collected cosignatures
+MUST BE available directly.
+
+If we accept more overhead for witnesses, this is a better solution than the
+above:
+ 1. Sigsum logs rotate tree heads every minute
+ 2. Witnesses are expected to cosign every minute
+
+It is a weak argument to say that the current five minute interval is about
+increasing the likelihood that a witness has time to add their cosignature in
+case of failure. One minute, or five minutes; both are sufficient to recover
+from easy "try again" errors, and none of them are sufficient to recover from
+errors involving the operator.
+
+The driving factor should be how cheap we want witness operations to be. We
+should probably account for a witness that witnesses ~100s of logs, as we want
+sigsum and other transparency log ecosystems to collaborate when it comes to
+witnes cosigning.
+
+rgdd is leaning towards keeping what we have right now and adding a "should"
+somewhere to recommend that Sigsum logs are not speeding up their tree head
+rotations as above. ln5 mentioned that it could be reasonable to allow it, but
+document the trade-off.
+
+rgdd is contemplating if it was a mistake to add the fast endpoint, and maybe it
+should be one of these things that we can consider for v1 if the need for it is
+more obvious. ln5 is thinking similarly; both rgdd and ln5 wants to think more.