From f64c1f24a3956be8547d5d98a0348fd7b49f6aa7 Mon Sep 17 00:00:00 2001 From: Rasmus Dahlberg Date: Sat, 2 Oct 2021 00:04:26 +0200 Subject: updated q/a section - Named it FAQ - Linked pad with design things that we still consider - Cleaned notes about what we should be adding - Removed empty concluding remarks section --- doc/design.md | 40 ++++++++++++++++------------------------ 1 file changed, 16 insertions(+), 24 deletions(-) (limited to 'doc/design.md') diff --git a/doc/design.md b/doc/design.md index 1179489..8c14992 100644 --- a/doc/design.md +++ b/doc/design.md @@ -337,13 +337,15 @@ distribution mechanism. It is the claimant's job to log signed statements and distribute necessary proofs of public logging. It is the verifier's job to look for new statements in the log and alert an arbiter if any claim is false. -### 4 - A peek into the details -Our bird's view introduction skipped many details that matter in practise. Some -of these details are presented here using a question-answer format. A -question-answer format is helpful because it is easily modified and extended. +### 4 - Frequently Asked Questions +#### 4.1 - What parts of the design are we still thinking about? +A brief summary appeared in our archive on 2021-10-05 +[link](https://pad.sigsum.org/p/cb19-fa17-ac51-ce72). -#### 4.1 - What is the point of having a shard hint? -Unlike X.509 certificates which already have validity ranges, a checksum does +XXX: add persisted link when it is available. + +#### 4.2 - What is the point of having a shard hint? +Unlike TLS certificates which already have validity ranges, a checksum does not carry any such information. Therefore, we require that a claimant selects a _shard hint_. The selected shard hint must be in the log's _shard interval_. A shard interval is defined by a start time and an end time. Both ends of the @@ -360,23 +362,13 @@ Note that _the claimant's shard hint is not a verified timestamp_. The submitter should set the shard hint as large as possible. If a roughly verified timestamp is needed, a cosigned tree head can be used instead. -#### How is the threat of log spam and poisoning reduced? -- Relates to: "why not log richer metadata and why not store the opaque data" -- Relates to: "why we removed identifier field from the leaf" -- Relates to: domain hint (maybe better as a separate heading) - -#### What are the details for witness cosigning? -- Relates to: explain `tree-head-latest`, `tree-head-to-sign` and -`tree-head-cosigned` - -#### What cryptographic primitives are supported? -#### What (de)serialization parsers are needed? -#### Are there any privacy concerns? - -#### Other +#### 4.3 - XXX +- Why not store opaque data in the log? +- Why not store rich metadata in the log? +- What (de)serialization parsers are needed? +- What cryptographic primitives are supported and why? +- Could you give a primer of witness cosigning? Needs to include +`get-tree-head-latest`, `get-tree-head-to-sign`, and `get-tree-head-cosigned`. +- Are there any privacy concerns? - How does it work with more than one log? - What policy should a believer use? -- Coarse-grained vs fine-grained detectability properties -- \ - -## Concluding remarks -- cgit v1.2.3