aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--archive/2021-09-14-checkpoint-format-summary18
-rw-r--r--archive/2021-09-14-qna-session50
2 files changed, 68 insertions, 0 deletions
diff --git a/archive/2021-09-14-checkpoint-format-summary b/archive/2021-09-14-checkpoint-format-summary
new file mode 100644
index 0000000..f41b8c9
--- /dev/null
+++ b/archive/2021-09-14-checkpoint-format-summary
@@ -0,0 +1,18 @@
+Decision about checkpoint format?
+ * First line is a free form unique log ID
+ * Leave everything else as is
+ * If anyone wants Verifier("Property X") from witnessing -> use [otherdata]
+ * Leave [otherdata] undefined for now, focus on Verifier("Append-Only")
+ * Possible documentation TODOs
+ * Warning: monitors need to ensure that they have fresh append-only views. The base witnessing format helps with append-only, not freshness.
+ * Warning: if you plan for witnesses to peek into [otherdata], it would probably be a good idea to propose a common format that will facilitate such witnessing.
+
+Way forward in sigsum?
+ * Easiest thing right now is to just add checkpoint as an endpoint and keep everything else as is. This should work well with TrustFabric's Feeder/Distributor thoughts.
+ * Motivation
+ * Don't have to figure out [otherdata] exactly right now "in a rush"
+ * Others can add their opinion and discuss what [otherdata] should (not) be
+ * We can do a proper trial-run of the design that we have and learn from it
+
+What do we do now with sigsum x trustfabric?
+ * Homework until next time to think about this?
diff --git a/archive/2021-09-14-qna-session b/archive/2021-09-14-qna-session
new file mode 100644
index 0000000..e57cdf8
--- /dev/null
+++ b/archive/2021-09-14-qna-session
@@ -0,0 +1,50 @@
+Q/A session rgdd-rohon
+
+Q: how sigsum project different than ct from security / architecture point of view
+
+CT
+ * SCTS, promises of public logging
+ * Centrally trust the logs because it is difficult to audit in practise
+ * Privacy
+ * Complexity
+
+Sigsum
+ * No SCTs, you need to fetch an inclusion proof that references a cosigned tree head
+ * Decentralized/distributed trust, assumption is an honest majority for witnesses
+ * A pretty opinionated gossip-audit model, much emphasis on simple and minimalistic
+
+Q: why no cryptographic agility / what is the motivation?
+ * Don't let people use old bad choices like rsa, legacy tools, etc.
+ * Makes exchanged protocol messages simpler (e.g., no negotiation)
+ * Makes supporting sigsum protocol easier (you need one primitive, not many)
+ * If a primitive breaks -> roll up protocol version
+
+Q: Elaborate about "the right data"?
+ * Suppose you downloaded Tor Browser
+ * Signature is valid
+ * Now what?
+ * You kind of have to trust that the signer signed the right data
+ * What if the signer was coereced to sign a back-doored version?
+ * What if the signing key was stolen? How would a signer even detect that?
+ * Sigsum logs add discoverability into signing operations
+ * Anyone can detect what has been signed by monitoring sigsum logs
+ * "Oh, there is this signature that doesn't correspond to any Tor Browser Bundle"
+ * "Tor Project, what is that? Please look into this issue and explain"
+ * This type of transparency is difficult without a log that adds discoverability
+
+Q: What crypto primitives are supported
+ * Ed25519 (signify, minisign, etc.)
+ * SHA256
+ * (Remark: we are thinking about Ed25519ph and SHA512/256)
+
+Q: At what part Rohon comes in?
+ * Model system formally, requires notation
+ * Think about how security proof goes (properties, assumptions, argument)
+
+Some links
+ * Claimant model
+ * https://github.com/google/trillian/blob/master/docs/claimantmodel/CoreModel.md
+ * Sigstore (good to be aware of, does similar things with different trade-offs)
+ * https://www.linuxfoundation.org/en/press-release/linux-foundation-announces-free-sigstore-signing-service-to-confirm-origin-and-authenticity-of-software/
+ * https://www.sigstore.dev/
+ * https://github.com/sigstore/rekor/