diff options
Diffstat (limited to 'archive')
| -rw-r--r-- | archive/2022-01-18-future-website-sketch | 97 | ||||
| -rw-r--r-- | archive/2022-01-18-proposal-author-reader-terminology | 41 | ||||
| -rw-r--r-- | archive/2022-01-18-proposal-log-url | 26 | ||||
| -rw-r--r-- | archive/2022-01-18-tree-head-endpoint-observations | 105 |
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. |