persisted pads from meeting minutes

3 files changed, 156 insertions, 0 deletions

diff --git a/archive/2021-06-29-claimant-model-thoughts b/archive/2021-06-29-claimant-model-thoughts
new file mode 100644
index 0000000..e7df860
--- /dev/null
+++ b/archive/2021-06-29-claimant-model-thoughts
@@ -0,0 +1,57 @@
+Claimant model thoughts for claimant.md and beyond
+==================================================
+
+We have
+
+checksum claim: I, data publisher, claim that the data:
+	1. has cryptographic hash X
+	2. is produced by no-one but myself
+
+statement: signed checksum
+
+checksum-rb claim: I, software publisher, claim that the data:
+	1. has cryptographic hash X
+2. is the output of a reproducible build for which the source can be located using X as an identifier
+	
+Qs:
+	* Why is 2. from the checksum claim missing in the checksum-rb claim?
+	* Why do we have 2. in the data publisher case anyway. Think about me publishing a music video on my website (it's just data, too!): why should that be produced by me?
+		* The example we were trying to make is that even without any formal claim about where the data is located, it is possible to generate value out of logging. It would be less useful yes, but the claimant would see all signing ops if those that rely on the signatures enforced logging (i.e., rejected if no proofs).
+		* Reading this again weeks later, I don't like claim #2 tbh. We should drop it.
+		* And instead actually add a claim about publishing data in a repository, which is in the overview figure that we drafted.  If we think there is a special use-case where that may be omitted, it is probably best as "Appendix stuff".
+	* Claims need to be creatable from Statements without any additional context. How do we do that for 2. in each case above?
+		* It isn't
+		* I am not sure that is satisified for other claimant model examples either.  See, e.g., FT: "is functionally correct, and without known attack vectors".
+		* I think I mentioned that to one of the Trillian folks, but should poke again.
+			* Martin will refactor claimant requirement wording, see below.
+
+* **Verifier<sup>CHECKSUM</sup>**: data publisher<br>
+    Only the data publisher can verify the above claims.
+
+Qs:
+	* Why can only the data publisher check whether "has cryptographic hash X" actually holds?
+		* Answer: because it is the only party who is in an *authoritative* position to do so (see: https://docs.google.com/presentation/d/e/2PACX-1vTKbm7Atsgp4FzXVSpBpL8TFg1BT2MogTYGF2o8D0CFS2k9jVwff4m5p2zWxVBEozOHjfX26ZquQo67/pub#slide=id.ga23a1950f6_2_258) BUT: then the claim is a different one!? (in the presentation it is one about a hash value of a *genuine* release) No, just a stronger one which one makes as well implicitly.
+		* It might be good to separate both, though, conceptually because the verifiers of both are different and potential attackers, too:
+			* has cryptographic hash X: anybody can check whether an attacker modified the data (it's like GPG signature checking today)
+			* has *right* cryptographic hash X: only the publisher may know (think about an attacker replacing a newer data/sig combination (e.g. my-cat-video-2021-05-01.webm) with an older (e.g. my-cat-video-2021-04-01.webm) claiming it's the newer one
+		*  One of the cool things with RB is that this verifier requirement gets relaxed: we don't need someone in an authoritative position anymore for verification in an RB context, or better: anybody can be authoritative.
+
+=== End of discussion ===
+Martin Hutchinson
+12:27  Perhaps looking at this from the variables case is the better way of looking at it
+12:27 I can print a static string without any context, right. That's what "hello world" is
+12:28 These claims are sometimes what we've called implicit, but we try to make them explicit.
+12:28 You've convinced me that phrasing this through the lens of variables/placeholders in the claim is a better way of phrasing my semantics here
+12:31 Going back to the FT claim, what this means is that X device class version must all be extractable from the statement
+12:32 In your case, it's totally fine to say that whoever signs this will host the original binary on their CAS identified by hash . As long as the person making the claim and signing the statement knows that this is one of their obligations, they don't literally have to say it in every manifest/entry
+Rasmus Dahlberg
+12:33 Okay cool
+12:33 Same goes for (iii) then in FT model
+12:34 Because that's how I think about the signed statement
+12:34 We give meaning to it by making all the claims explicit
+12:34 So everytime you see a signature from the claimant
+12:34 You know what they are claiming, and those claims should be verifiable
+Martin Hutchinson
+12:34 Yeah exactly. This implicit claim is really something that exists in a world without transparency where you just have signed binaries. It seems to me that the point of verifying the signature on a binary is that I trust a certain author to not give me stuff which is going to pwn me
+Rasmus Dahlberg  12:35
+Okay cool I think we are on the same page
diff --git a/archive/2021-06-29-tooling-mockup b/archive/2021-06-29-tooling-mockup
new file mode 100644
index 0000000..25e0003
--- /dev/null
+++ b/archive/2021-06-29-tooling-mockup
@@ -0,0 +1,23 @@
+Example snippet with signify to log a new checksum
+- The only thing that should change with e.g. minisign, yubihsm, or any other tool that signs what we ask for with ed25519 -> specify this tool with -f FORMAT flag.
+
+$ signify -G -p rgdd.pub -s rgdd.sec
+$ ls
+rgdd.pub rgdd.sec
+$
+$ echo 'print("hello, world!")' > hello.py
+$ sha256sum hello.py | awk '{print $1}' > hello.sum
+$ ls
+hello.py hello.sum rgdd.pub rgdd.sec
+$
+$ sigsum-format abcd --to-sign -c hello.sum > hello.tosign
+$ signify -S -s rgdd.sec -m hello.tosign
+$ ls
+hello.py hello.sum hello.tosign hello.tosign.sig rgdd.pub rgdd.sec
+$
+$ sigsum-format abcd --to-log -d example.com -c hello.sum -s hello.tosign.sig -k rgdd.pub
+...
+$ !! | curl --data-binary @- $(siglog-format abcd --endpoint add-leaf) 
+...
+
+And from here on, fetch cosigned tree head, inclusion proof, bundle them up into a format that is suitable for the use-case, etc. That's what I'm thinking the "bundle" option could do, so that we have concrete examples of what we mean by "you can distribute proofs of public logging in any format that suits you".
diff --git a/archive/2021-06-29-website-thoughts b/archive/2021-06-29-website-thoughts
new file mode 100644
index 0000000..e889037
--- /dev/null
+++ b/archive/2021-06-29-website-thoughts
@@ -0,0 +1,76 @@
+What information is needed on sigsum.org?
+	* rgdd needs somewhere to point people as he attends conferences, etc.
+	* doesn't have to be perfect, but should also not be inconsistent
+
+Before vaccay (?)
+	* Identity
+		* sigsum
+		* anything about the ongoing project shaping?
+	* How to get involved and/or stay updated
+		* Day-to-day conversations happen on irc/oftc #sigsum, Matrix bridged
+		* Open video/voice meeting on Jitsi, Tuesdays 1300 CEST
+		* Meeting minutes and discuss documents are persisted every week
+	* Where are our repositories right now
+
+Later (not an exhaustive list)
+	* Backdrop, origin story
+		* How we started as ST logging
+		* What are we doing and how in more detail
+	* Project
+		* Free and open source
+		* Vision
+			* Short term
+			* Long term
+			* How
+		* Involved people
+			* Name, nick, affilitation
+		* Funding / sponsors
+	* ...
+
+=== Inspiration from ST website planning, copy-pasted ===
+Who is the target audience?
+	* Security experts
+	* Non-technical decision makers
+	* Technical decision makers
+	* New/existing users
+	* Cloud service operators
+	* Journalists
+
+Website content (in order)
+	* What is ST?
+	* Is it useful for me?
+	* How does it work?
+	* How do I try it out?
+	* Who is behind ST?
+
+Information places
+	* Entrance / Portal / Website @ system-transparency.org
+	* Code repositories @ GitHub
+		* Or self-hosted with mirror on GitHub
+		* GitHub is bad for non-technical people
+	* Documentation & tutorials
+		* High-level documentation on the website?
+		* Detailed documentation for sysadmins
+		* The more details the closer it should be to the code (in Git)
+	* Slack
+	* Blog
+	* Twitter
+	* Newsletter
+	* Conferences
+=== End of copy-paste ==
+
+Text proposal
+	* Intent: add on github.com/sigsum/sigsum, top-most README.md
+	* Intent: add on sigsum.org
+	* See below
+
+# The Sigsum Project
+Sigsum logging brings transparency to signed checksums.
+
+Join the conversation at irc/oftc \#sigsum.  Our channel is bridged with [Matrix](https://app.element.io/#/room/#sigsum:matrix.org) to support web browsers, phones, etc. We have voice meetings on Jitsi every Tuesday, 1300 CEST.  Our channel and voice meetings are open for everyone.  We encourage you to come say hello, talk transparent logs, and get involved!
+
+You can find more information here:
+	* [sigsum](https://github.com/sigsum/sigsum): Documentation, meeting minutes, persisted pads, etc.
+	* [sigsum-log-go](https://github.com/sigsum/sigsum-log-go): Trillian personality that implements sigsum logging
+	* [sigsum-lib-go](https://github.com/sigsum/sigsum-lib-go): Go library and (soon) command line utilities that are useful for tooling purposes
+	* [sigsum-witness-py](https://github.com/sigsum/sigsum-witness-py): Python witness that cosigns sigsum logs