diff options
| author | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-10-10 20:01:25 +0200 |
|---|---|---|
| committer | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-10-10 20:08:14 +0200 |
| commit | 4912cd5813e1ce69c3d8c5a95d91a78f70d92172 (patch) | |
| tree | 2543144a53a72d67c978d274a2ddf5706b4b4ed0 | |
| parent | d1ea4e9a9940367cc5dfdaf0d9eab99d1a54eb8b (diff) | |
added additional witnessing thoughts in FAQ
| -rw-r--r-- | doc/design.md | 26 |
1 files changed, 22 insertions, 4 deletions
diff --git a/doc/design.md b/doc/design.md index 40287a4..1117f02 100644 --- a/doc/design.md +++ b/doc/design.md @@ -382,13 +382,31 @@ management. Our work is about transparent _key-usage_. We are considering if additional anti-spam mechanisms should be supported. -#### 4.4 - More questions +#### 4.4 - Is witness cosigning done? +There are interesting policy aspects that relate to witness cosigning. For +example, what witnessing policy should a verifier use and how are trustworthy +witnesses discovered. This is somewhat analogous to a related policy question +that all log ecosystems must address. Which logs should be considered known? + +We do however think that witness cosigning could be done _from the perspective +of a log and its operator_. The + [sigsum/v0 API](https://git.sigsum.org/sigsum/tree/doc/api.md) +supports witness cosigning. Policy aspects for a log operator are easy because +it is relatively cheap to allow a witness to be a cosigner. It is not a log +operator's job to determine if any real-world entity is trustworthy. It is not +even a log operator's job to help signers and verifiers discover witness keys. + +Given a permissive policy for which witnesses are allowed to cosign, a signer +may not care for all retrieved cosignatures. Unwanted ones can simply be +removed before distribution to a verifier takes place. This is in contrast to +the original proposal by + [Syta et al.](https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7546521), +which puts an authority right in the middle of a slowly evolving witnessing policy. + +#### 4.5 - More questions - Why not store data in the log? XXX: answered enough already? - Why not store rich metadata in the log? XXX: answered enough already? - What (de)serialization parsers are needed and why? - What cryptographic primitives are supported and why? -- What thought went into witness cosigning? Compare with other approaches, and -should include `get-tree-head-*` endpoints in more detail. - What are the privacy concerns? - How does it work with more than one log? -- What policy should a verifier follow? |