persisted pads from meeting minutes

2 files changed, 140 insertions, 0 deletions

diff --git a/archive/2021-09-28-announcement-inspiration b/archive/2021-09-28-announcement-inspiration
new file mode 100644
index 0000000..0ab27ab
--- /dev/null
+++ b/archive/2021-09-28-announcement-inspiration
@@ -0,0 +1,117 @@
+Summary
+	* Announce via mailing list
+		* It happens in our community
+		* It makes it easy to respond
+		* It makes it easy to forward
+		* We can keep our website minimal for now (landing page)
+	* Announcements seem to be relatively short
+		* Max 500 words is probably a good rule of thumb
+		* Shorter if you have a few polished links to reference
+	* Possible points to make, also based on what we discussed before
+		* What type of project are we
+		* What is the project about
+		* What is the purpose of project announcement
+		* What is the timeline leading up to announcement
+		* What is the current project status
+		* What are the next steps
+		* Who is involved, people and funders
+		* Relevant links to help the reader navigate sigsum
+		* (Get feedback from a communicator)
+
+Other things to keep in mind
+	* Double check that what we are linking is in good enough shape
+		* E.g., small TODOs in sigsum-log-go README.md (fix links)
+	* We should think about what questions people might have in response to announcement
+		* Perhaps it would be a good idea to give design.md FAQ some love
+	* Try to avoid too much detail, we can make sigsum blog posts at a later stage
+	* The fact that we are aware of sigstore should probably be clear
+		* Let people ask, that's fine
+
+---
+Warning: I have not spent much time verifying if there were other announcements
+than the ones specified below.  It is the result of a v. quick search / analysis.
+
+(Some of the below links are not even project announcements, but rather
+announcement of 'we are developing or developed cool thing XXX'.  I kept
+everything I found useful as inspiration in case it helps anyone else.)
+
+Debian
+	* https://www.debian.org/doc/manuals/project-history/project-history.en.pdf
+	* See §1.1
+	* How: mail
+	* Points
+		* This is a work in progress
+		* It is cool because XXX
+		* Purpose of anouncement is XXX
+		* It is better than XXX because A,B,...
+
+Tails (back then amnesia)
+	* https://lists.torproject.org/pipermail/tor-talk/2009-August/002667.html
+	* How: mail
+	* Points
+		* This work is about XXX
+		* Licence is XXX
+		* Purpose of announcement is XXX
+		* We prefer if you get in touch via XXX
+
+Qubes
+	* https://blog.invisiblethings.org/2010/04/07/introducing-qubes-os.html
+	* How: post on website
+	* Points
+		* Timeline before announcing project
+		* Project is about doing XXX
+		* Current project status is XXX
+		* Learn more via resources XXX
+
+Signal
+	* https://signal.org/blog/signal/
+	* How: post on website
+	* Points
+		* Timeline leading up to announcement
+		* Mision and work is about XXX
+		* Next steps
+		* Who is involved
+		* "Give it a try!"
+
+Wireguard
+	* https://lists.zx2c4.com/pipermail/wireguard/2016-June/000002.html
+	* How: Mail
+	* Points
+		* Been at this for a while, confident enough to launch now
+		* Purpose of launch is XXX
+		* Link relevant resources (paper, website, git, mailing list)
+		* One paragraph primer (118 words)
+
+Firecracker
+	* https://aws.amazon.com/about-aws/whats-new/2018/11/firecracker-lightweight-virtualization-for-serverless-computing/
+	* How: post on website
+	* Points
+		* We are launching product XXX
+		* Key concepts are XXX
+		* How it is used / can be used
+		* Visit XXX to learn more
+
+System Transparency
+	* https://mullvad.net/en/blog/2019/6/3/system-transparency-future/
+	* How: post on website
+	* Points
+		* Key questions and background that motivated this work
+		* We believe that ST gives you the ability to XXX
+		* Call to action
+		* Little detail, link to ST white paper
+
+Sigstore
+	* How: press releases on partner websites
+		* https://security.googleblog.com/2021/03/introducing-sigstore-easy-code-signing.html
+		* Points
+			* What is the problem
+			* Announcement project with goal/mission XXX
+			* Problem space is related to XXX, involved tehniques are...
+			* Collaboration is between XXX
+			* Request for feedback
+			* Next steps
+		* https://www.linuxfoundation.org/en/press-release/linux-foundation-announces-free-sigstore-signing-service-to-confirm-origin-and-authenticity-of-software/
+		* Points
+			* Collaborators XXX want to achive XXX
+			* Quotes from involved people that explain idea and purpose
+			* Refer to website for more information
diff --git a/archive/2021-09-28-design-comments b/archive/2021-09-28-design-comments
new file mode 100644
index 0000000..42cebec
--- /dev/null
+++ b/archive/2021-09-28-design-comments
@@ -0,0 +1,23 @@
+-design.md file: [rohonk]
+    
+    Line 39-49: This part is very important as it clearly states the goal of the project. Also it draws a comparison between our goal and what we want to achieve different/better than the previously available certificate transperancy. I would like to suggest if we can make a different subsection 1.2, which deals with the comparative study. 
+    
+   Line 60-62: Using Claimant Model.
+   
+   Line 88-89: Does it mean that the fingerprint i.e. (hash of the opaque data is already stored in the sigsum log)? And now the Claimant checks with the log.
+   
+   Figure 1: What happens if one of the participating party (Believer/Claimant) act maliciously by deviating from the protocol?
+   
+   Line 109-113: Introduction to DNS in order to avoid log poisoning is a very interesting concept.
+   
+   Line 141-158: Each of the different attack circumstances needs to be dealt with in the security proof. Here we are considering an external attacker as a threat. Is it a good question to ask that what happens when the trusted party act maliciously within the system?
+   
+   Line 183-185: This part partially address my concern stated in the previous point.
+   
+   Steps for Security Proof:
+       https://git.sigsum.org/sigsum/tree/archive/2021-06-21-system-overview-ascii
+       1. Writing pseudocodes for each interaction i.e. Claimant <> Believer , 
+       Claimant <> Witness. 
+       2. Have a threat model considering all possible misbehaviours.
+       3. Cryptographic Schemes already determined (CRH, ECDSA)
+       4. Decide on what kind of security proof is necessary like pen and paper proof or using software like Proverif/Tamarind?