persisted pads from meeting minutes

6 files changed, 419 insertions, 0 deletions

diff --git a/archive/2021-06-21-how-we-work-together b/archive/2021-06-21-how-we-work-together
new file mode 100644
index 0000000..9e91ff5
--- /dev/null
+++ b/archive/2021-06-21-how-we-work-together
@@ -0,0 +1,75 @@
+Meeting agenda template.
+
+Agenda
+	* Hello
+	* Status round
+	* Discuss
+	* Next steps
+
+Hello
+	* <insert nick here>
+
+Status round
+	* <insert status report here>
+
+Discuss
+	* <insert discuss item here>
+
+Next steps
+	* <insert next step here>
+
+Other useful links
+	* <insert useful link here>
+
+Weekly process.
+	* Our conversations happen on irc
+	* Use etherpads if it is helpful, e.g., to summarize a discusison, conclusion, etc.
+		* Use 60 days expiry
+		* Add link to meeting agenda if it should be persisted ("status report")
+		* We keep the next meeting agenda etherpad in our irc channel topic
+	* Tuesday
+		* Open video/voice meeting
+			* Jitsi
+			* 1300-1400 CEST
+			* We keep the meeting link in the announced meeting pad
+		* After the meeting
+			* Meeting chair persists all etherpad links that were added to the agenda as is
+			* Meeting chair cleans up the resulting meeting minutes if need be
+			* Meeting chair persists the meeting minutes etherpad
+			* Meeting chair posts the link to the next week's meeting agenda / minutes on irc.
+
+fixme: think about git process, issues, PRSs, etc., based on where we move.
+	* CONTRIBUTING.md?
+	* defer until after vaccay, stay on github for now
+	* create new repos there as we see fit
+
+fixme: do we need a mailing list?
+	* defer until after vaccay
+
+Repos
+	* sigsum, sigsum-project?
+		* redirect sigsum.org here for now?
+		* example structure below
+
+$ tree
+.
+├── archive
+│   ├── 2021-06-22--minutes
+│   ├── 2021-06-22-sketch-on-how-we-work-together
+│   └── 2021-06-22-witness-timestamp-verification
+├── doc
+│   ├── api.md
+│   ├── claimant.md
+│   └── design.md
+├── LICENCE.md
+├── README.md
+└── website
+
+	* sigsum-lib-go
+		* cmd: sigsum-format
+		* cmd: sigsum-verify
+	* sigsum-log-go
+		* Trillian personality
+	* sigsum-witness-py
+
+
diff --git a/archive/2021-06-21-project-name b/archive/2021-06-21-project-name
new file mode 100644
index 0000000..0411a4c
--- /dev/null
+++ b/archive/2021-06-21-project-name
@@ -0,0 +1,87 @@
+Background
+	* ST != ST Logging
+	* This distincion is not evident for a newcomer.
+	* The same log personality is applicable for other use-cases than ST.
+	* We need a better name in order to minimize confusion
+
+Parameters to keep in mind
+1. What is it that we are trying to abbreviate. Is it a good full name?
+2. Is the abbreviation easy and convenient to use in documentation?
+3. Is the abbreviation easy to prunounce, work into to sentences, etc.?
+4. Is the abbreviation easily confused with something else?
+
+What are we providing - full names and possible abbreviations?
+	* Something sensible that can replace the CT piggyback hack, where a checksum is inserted into a signed certificate.
+	* Checksum Logging, Checksum Transparency
+		* CL, CT
+		* checksumlog, checksumtrans
+		* sumlog, sumtrans
+		* checklog, checktrans
+	* Signature Logging, Signature Transparency
+		* SL, ST
+		* siglog, sigtrans
+		* sigl
+	* Signed Checksum Logging, Signed Checksum Transparency
+		* SCL, SCT
+		* sigsum
+			* sigsumlog, sigsum-log, sigsuml
+			* sigsumtrans, sigsum-trans, sigsumt
+		* sigcheck
+			* sigchecklog, sigcheck-log
+			* sigchecktrans, sigcheck-trans
+
+[rgdd]
+	* The start of three words feels too verbose for an abbreaviation to be useful.
+	* It might be good if the short version does not contain "log".  It makes the abbreaviation more difficult to use in speach and text.
+		* "A siglog log", "siglog logging", etc.
+		* Cf. "a sigtrans log", "sigtrans logging", etc.
+	* Checksum Logging, Checksum Transparency
+		* I am not that worried about someone starting to say "CT" (or mix it up).
+		* I am worried about confusion with Go's checksum database.
+			* "Why do we need another checksum database".  Well, things are signed too.
+		* I don't like any of the proposed abbreviations.  Not sure why, subjective.
+	* Signature Logging, Signature Transparency
+		* If we talk about System Transparency and abbreaviate it ST, I think it is probable that an unfamiliar reader will mix up the meaning of "S".
+		* Sigstore brands Rekor as "Signature Transparency".
+			* Using the same full name is not helpful for anyone. Big no-go for me.
+			* To be fair Rekor is more about signature transparency than we are. E.g., there are many signature schemes and formats that we will never support.
+	* Signed Checksum Logging, Signed Checksum Transparency
+		* I like this because it is descriptive and distinct
+			* It is consistent with how we talk about the log in text and speach
+			* No other tlog project uses the exact same wordings (as far as I know anyway)
+		* An obvious abbreaviation is SCT.  That could lead to confusion.
+			* I think most tlog people would know that "SCT" is not a good idea though.
+			* The short abbreaviation has to be introduced clearly, and be convenient. If that is the case, using SCT as an abbreaviation would not cross your mind?
+		* I tried playing with "sigsum" below.
+			* "Sigsum - a free and open source project that brings transparency to signed checksums".
+			* Repos
+				* sigsum-server-go / sigsum-log-go
+				* ...
+			* irc channel, or channels if we start thinking ahead
+				* #sigsum
+				* #sigsum-dev
+				* #sigsum-meet
+				* #sigsum-{log,server}
+				* #sigsum-witness
+				* ...
+			* Website
+				* sigsum.org
+
+=== Start of a README.md example ===
+# Sigsum Logging
+_Sigsum_ logging brings transparency to **sig**ned check**sum**s.  What a checksum represents is up to you.  For example, it could be the cryptographic hash of
+a provenance metadata file](https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html), a [Firefox binary](https://wiki.mozilla.org/Security/Binary_Transparency), or a text document.
+
+Sigsum logging can be used to:
+1. Discover which checksum signatures were produced by what secret signing keys.
+2. Be sure that everyone observes the same signed checksums.
+==== end of example ===
+
+[rgdd, ln5, FredrikStrmberg]
+	* Decision: "Signed Checksum Logging" (full version)
+	* Decision: "sigsum" (short version, what we use to brand the project)
+		* "A sigsum log, "sigsum logging", etc.
+	* Decision: sigsum.org
+		* Con: we don't get domain locking as with .se
+			* Doesn't affect security of logs though.
+		* Pro: less risk of being perceived as a local project in Sweden
diff --git a/archive/2021-06-21-self-hosted-services b/archive/2021-06-21-self-hosted-services
new file mode 100644
index 0000000..4413aec
--- /dev/null
+++ b/archive/2021-06-21-self-hosted-services
@@ -0,0 +1,119 @@
+This document investigates possibilities for self hosting all online
+services needed for the development and management of the Sigsum
+project.
+
+The goal is to host all the services we're using ourselves. The
+primary driving force for this is to avoid forcing contributors to
+sign up for and expose their online habits to centralised services
+like GitHub, Google, Slack and similar.
+
+An overarching goal for the development process is openness both with
+regards to transparency of project governance and opportunity to
+influence decisoins.
+
+
+## tl;dr
+
+TODO summary of recommendations
+
+
+## Considerations
+
+### Stable references -- URL's that survive
+
+Stable references, i.e. URL's, are valuable for long lived data like
+code repositories, presentations, project guidelines and such with an
+archiving function. Less persistent data, like online chat, have less
+need for stable references.
+
+### Functionality
+
+* git repos
+* ticketing system
+* text publishing
+* direct communication
+  between users, developers, administrators, sponsors
+
+### Availability -- uptime guarantees
+
+### Cost -- agony, time, money
+
+
+## Possible steps forward
+
+Moving from something to something else.
+
+### Sigsum current situation, June 2021
+
+Here's where we are at.
+
+- Meeting minutes in Google docs
+- Code and issues on GitHub
+- Code review available on GitHub, not currently used
+- Web site: missing
+- Mailing list: missing
+- Video meetings: Jitsi @ friends
+- Chat on OFTC (IRC) and matrix.org (Matrix), bridged
+- Pads: wherever, mostly on riseup
+- Pastebin: wherever
+
+### Potentially useful software packages and services
+
+- [GitLab](https://about.gitlab.com/) is a company and software
+  package with features like what GitHub has
+
+  The full thing, with CI runners and all that jazz. There's a
+  considerable amount of systems administration to take into account
+  when chosing GitLab.
+
+- [Codeberg](https://codeberg.org/) is a non-profit organisation,
+  hosting a [gitea](https://gitea.io/en-us/) server
+
+  The GitLab replacement for skeptics of GitLab the company or the
+  Ruby monster (?). It might be easier to keep upgraded and running
+  than GitLab but to what extent is unclear.
+
+  Paying for hosting:
+  - https://hostedgitea.com/ $24/month
+  - https://www.stellarhosted.com/gitea/#pricing $49..$249/month
+
+- [cgit](https://git.zx2c4.com/cgit/about/) is a software package (by
+  Jason, coincidentally)
+
+  Lean, no frills, no(*) dependencies easy to upgrade and keep
+  running.
+
+  Lacks a ticketing system and code review. This is typically handled
+  in mail, chat and pads instead.
+
+  (*) libzip, openssl
+
+### Sigsum future
+
+Here's where we want to get to during the fall of 2021.
+
+- Meeting minutes in an archive
+  - Contenders: a git repo, a mailing list archive
+- Code: GitLab/gitea/cgit at git.sigsum.org
+- Issues: TBD
+- Code review: TBD
+- Web site: www.sigsum.org
+- Mailing list: mlmmj or Mailman @ lists.sigsum.org
+- Video meetings: Jitsi @ meet.sigsum.org
+- Chat: OFTC bridged to #Sigsum@matrix.sigsum.org
+- Pastebin: paste.sigsum.org
+- Pads: pads.sigsum.org
+
+
+#### TBD possible more services
+
+- Nextcloud can help with
+  - Shared documents
+    - Markdown out of the box
+    - "Office documents" with some extra work and with some user
+      quirks
+  - Shared calendars
+  - Shared task lists
+  - Kanban-like boards for project tracking
+  - A [million more things](https://apps.nextcloud.com/)
+
diff --git a/archive/2021-06-21-system-overview-ascii b/archive/2021-06-21-system-overview-ascii
new file mode 100644
index 0000000..2d1f19e
--- /dev/null
+++ b/archive/2021-06-21-system-overview-ascii
@@ -0,0 +1,26 @@
+                          +----------+                           
+               +----------| Claimant |-------+                   
+            [1]|          +----------+       |Data               
+            [2]|                |            |Proofs             
+            [3]|                |H(vk)       |                   
+               v                v            v                   
+          +---------+  H(vk) +-----+      +------------+         
+          |   Log   |<-------| DNS |      | Repository |         
+          +---------+        +-----+      +------------+         
+             ^    |                           | |                
+          [4]|    |leaves                     | |Data            
+          [5]|    |costh   +---------+   Data | |Proofs          
+          [6]|    +------> | Monitor | <------+ |         policy 
+             v             +---------+          v           |    
+          +---------+                       +----------+    |    
+          | Witness |                       | Believer |<---+    
+          +---------+                       +----------+         
+                                                                 
+   # Claimant                Log    # Witness                Log 
+ [1]|---------add-leaf--------->| [4]|--get-tree-head-to-sign-->|
+    |<-----------OK-------------|    |<----------sth------------|
+    |    ...wait inclusion...   | [5]|--get-consistency-proof-->|
+ [2]|--get-tree-head-cosigned-->|    |<---------proof-----------|
+    |<----------costh-----------|    |      ...cosign sth...    |
+ [3]|-----get-proof-by-hash---->| [6]|-----add-cosignature----->|
+    |<-------index+proof--------|    |<----------OK-------------|
diff --git a/archive/2021-06-21-tree-head-format b/archive/2021-06-21-tree-head-format
new file mode 100644
index 0000000..a0abb90
--- /dev/null
+++ b/archive/2021-06-21-tree-head-format
@@ -0,0 +1,79 @@
+https://github.com/system-transparency/stfe/compare/refactor-tree-heads
+	* link will become broken during repo migration
+
+Summary of proposed changes
+	* Leaf (Trunnel serialized)
+		* The name "message" for shard_hint+checksum is misleading. It is the core of our transparency log, and it is not called "message transparency". 
+		* Present leaf as we do on slides. Four fields.
+			* shard_hint
+			* checksum
+			* signature
+			* key_hash
+		* Signature is computed over the bytes that preceded it.
+	* Tree head (Trunnel serialized)
+		* No changes
+	* Signed tree head (Trunnel serialized, we did not need that before!)
+		* tree_head
+		* signature
+			* Singular, only computed by the log.
+			* This simplifies parsing and makes it explicit where the log's signature is located. Implementations will need to distinguish between log and witness, and our structures should make that distinction as easy as possible.
+			* Note that there is no corresponding key_hash, it is implicit that the signature is produced by the log that you are talking to.
+				* Q: Is this going to become an annoyance for:
+					* Witness?
+						* Seems fine after looking at Linus code
+					* Monitor
+						* Probably fine too, you fetch cosigned tree heads yourself
+					* Data publisher, end-user?
+						* Assumes that the retrieved ASCII blob is repackaged in a way that the end-user knows which log a cosigned tree head + proof refers to.
+						* I don't think it is enough to fix this by adding the log identifier though. You would also need versioning, which is also implicit now.
+							* E.g., st/v0 prefix is on endpoints
+						* Key question: is the above assumption what we want? Because when we designed this format it was not supposed to be a disk format. Just the simplest possible way to talk with the log.
+							* [rgdd] I think we should make explicit that this is not necessarily a suitable "on-the-fly" or "storage format". To use it it for that, information from the url need to be conveyed somehow.
+								* st/v0 (determine protocol version)
+								* which log (determine log public key)
+								* what is it (determine how to parse)
+									* signed tree head
+									* cosigned tree head
+									* inclusion proof
+									* consistency proof
+									* leaf list
+	* Cosigned tree head
+		* Witnesses sign signed_tree_head
+		* This is in contrast to the log, which signs tree_head.
+		* This separation of messages ensures that a log signature can not be confused with a witness cosignature.
+
+Naming of ASCII keys / behavior of log endpoints
+	* Leaf
+		* shard_hint (same)
+		* checksum (same)
+		* signature (modified, was before signature_over_message)
+		* key_hash (same)
+	* Signed tree head
+		* timestamp (same)
+		* tree_size (same)
+		* root_hash (same)
+		* signature (modified)
+			* exactly one
+			* no corresponding key_hash because it is always created by the log
+	* Cosigned tree head
+		* timestamp (same)
+		* tree_size (same)
+		* root_hash (same)
+		* signature (modified, same as above)
+		* cosignature (new)
+			* List of cosignatures, cf. "signature" before but now only for witnesses.
+		* key_hash (modified)
+			* List of key hashes. Used to identify which witnesses produces the above cosignatures.  Cf. "key_hash" before, but now only for witnesses.
+		* Error
+			* The log returns an error if there are no cosignatures available
+	* add-cosignature
+		* cosignature (was signature)
+		* key_hash (same)
+
+Other
+	* Maybe should present get-tree-head-latest first because it is simpler, then get-tree-head-cosigned, then tree-head-to-sign with input/output comment "same formatting as get-tree-head-latest"
+	* Look at, e.g., get-tree-head-cosigned. When we describe what "signature" and "cosignature" are computed over, I think it is more clear if we just refer to serialized tree_head and signed_tree_head.
+		* I think I made this inconsistent now btw.
+	* I realized that our Trunnel usage right now is 100% compatible with TLS record serialization. We don't have any variable length buffers anymore.
+	* Log ID (= public key?) must be unique.
+		* If log is shutdown -> cannot reuse key when a new shard is opened.
diff --git a/archive/2021-06-21-witness-timestamp-verification b/archive/2021-06-21-witness-timestamp-verification
new file mode 100644
index 0000000..51a90bc
--- /dev/null
+++ b/archive/2021-06-21-witness-timestamp-verification
@@ -0,0 +1,33 @@
+According to api.md witnesses must only cosign a tree head if it is not backdated or future-dated more than 12 hours.
+	* https://github.com/system-transparency/stfe/blob/c8400f98809fbc245f040598e8471fd833e5c1a5/doc/api.md#merkle-tree-head
+
+Discussion raised by ln5
+	* Why +- 12 hours, and in particular why so much forward drift
+	* Initial thoughts were:
+		* Symmetry, easy to implement
+		* The point is not that it should be a precicely verified timestamp. Time moves forward roughly for liveliness.
+		* If we set this interval too short, say, 5m, then we would make it difficult to use a larger cosigning interval like an hour.  Witnesses would have to do all of their signing the first 5 minutes. So with 12 hours we basically tried to set it "sufficiently large".
+		* Another related "threat" is that witnesses would stop signing because of a clock that is a little off. So by having a very flexible interval -> "reduced threat"
+
+	* Highlights of discussion
+		* Allowing large clock drift might not be helpful. It might not even be helpful to specify it is a strict implementation criteria. E.g., there is probably a distinction between "warning: time to look at your clock" and "error: we cannot sign this because timestamp is unfresh or someone's clock is wrong".
+			* Comments on clock drift is probably better as a recommendation, best practise, implementation hint, or similar in an Appendix or witness README.
+		* How unfresh timestamps should a witness sign?
+			* Right now we tried the "sufficiently large" approach
+			* Maybe it should be a configuration parameter, declared as log metadata.
+			* Catch: are we really envisioning an ecosystem where someone is going to say "we really want to run the log with a large cosigned tree head freauency".
+				* Probably not. Point is we want independent logs that behave the same.
+			* From UX perspective: cosigned tree head frequency F should be "short"
+				* After a leaf is merged in the tree, it takes [F,2F] time units before an inclusion proof can lead up to a cosigned tree head.
+			* From other perspective: cosigned tree head frequency should not be too short
+				* Witnesses need to poke the log more often to discover all tree heads
+					* More work and overhead, both for the log and witnesses
+				* Reliability of cosigning will be poor if witnesses miss signed tree heads
+
+	* Conclusion (ln5, rgdd)
+		* Set a fixed cosigned tree head frequency in api.md that all logs should use.
+			* 5 minutes to start with
+			* We can reconsider if it should be lower. It should probably not be higher.
+			* We can reconsider if it should be a configuration parameter. But a different design is needed for "much lower latency", like Syte et al. approach.  The reason why we are not doing that is because of added complexities and costs.
+		* Don't consider clock drift considerations as an integral part of api.md. It is something that we should talk about in "implementation hints" or similar.
+		* A witness must not cosign a signed tree head that is older than the log's cosigned tree head frequency.  As stated above, it is always 5 minutes.