| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
After our refactor rate limits are no longer mentioned in §3. The
domain hint subsection contains that text now, and should therefore be
before the shard hint subsection that assumed it is already explained.
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
These questions are to some extent answered as part of our refactor, or
addressed as things we are still open to think more about. I think we
can leave them out for now and add them later _with answers_ if needed.
I kept the privacy concerns question because that is not addressed
anywhere yet. We think that the answer is "mostly none".
|
| | |
| |
| |
| |
| |
| |
| | |
To be re-added at a later time somewhere else. It is not helpful for a
reader that is trying to understand the basic design for the first time.
Spotted by ln5.
|
| | |
| |
| |
| | |
Spotted by ln5.
|
| | |
| |
| |
| |
| | |
Strictly speaking the logged data structure is a checksum of a Go
module. This could be confusing with the wording of this sentence.
|
| | |
| |
| |
| | |
Discussed with ln5.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I don't think it improves our design document by being moved. We
already have a summary of properties in the introduction, and an easier
primer at the start of Section 3 that is strongly coupled to Figure 1.
Perhaps it is no longer necessary though. When we wrote this we did not
have a summary of properties in introduction, or a relatively detailed
walk-through of the log's intended usage-pattern.
I'm fine with both keeping as is or deleting if it feels redundant.
|
| | |
| |
| |
| |
| | |
- Expanded into two separate examples
- Moved it into the verification subsection
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Deleted unnecessary roadmap
- Clarified distribution and verification section
- Proposed down-to-the-point text for domain hint description
- Left comments that we should consider addressing
- A bunch of minor edits
For transparency this commit was squashed and rebased by rgdd.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
- s/verifier/monitor
- s/claimant/signer
- s/believer/verifier
- s/opaque data/data
- minor rewordings related to these substitutions
- referenced a possible timestamp usage
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
More emphasis on what a sigsum log actually provides, and less emphasis
on the details about how one can think about the cool use-cases that are
possible on-top of a sigsum log. Just list relatable examples instead.
Also fixed capitalization typos for Sigsum, "the project".
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
- Added anti-spam mechanism, completes figures without too much clutter
- Minor rewordings that simplified description
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
There is a risk that "the right data" is confused with "what do you
mean, obviously it is the right data if there is a valid signature".
Tried just reword.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The claimant model was mostly pulled from this document. It is useful
to define use-cases of sigsum in a succinct way, but not helpful to tell
the reader about the concrete design that we have for a sigsum log.
(We still have a separate document that uses the claimant model.)
This refactor also tries to remove focus from use-cases that in general
are messy, and instead focus on the simple sigsum logging design that
has a very well-defined and thought-through usage-pattern. The result
of this is that things should be a little bit more down-to-the-point.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I think the claimant model is most helpful for us to describe the
different use-cases of a sigsum log. Let's focus on claimant models for
use-cases in this document, not claimant models for logs _as well_.
I kept R-B as an example because it is concrete, and fixed the long-due
updates that GeKo pointed out a while back about, e.g., "right data".
|
| |
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
- Minor rephrasing and white-space changes to make raw text nicer.
- Avoid using sigsum as "signed checksum" in text. Not helpful.
- Removed TODO in text about Figure 2. It works without it for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Minor rephrasing and white-space changes to make raw text nicer.
- Avoid using sigsum as "signed checksum" in text. Not helpful.
- Removed paragraph about risk-averse attacker. It is not needed to
make our points right now. In a future revision, we should re-add this
and explain why it is interesting. It would also be a good idea to then
cite the two papers that z4lem mentioned a while back, see archive.
- Clarified that we need a threshold of witnesses that follow the
cosigning protocol for security. It is a start on addressing rohonk's
comment about which parties may (not) follow protocol and why.
- Emphasized that sigsum logging is only more course-grained than CT if
the data is actually lost. Hence, more course-grained _in isolation_.
- Added links to slow-down and split-view attacks.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Minor rephrasing and white-space changes to make raw text nicer.
- Avoid using sigsum as "signed checksum" in text. Not helpful.
- Replaced TPM quote example. Not easy for everyone to relate to.
- Added a paragraph with examples of how our design goals are not
fulfilled by CT. This starts to address Rohon's comment about having
comparative study. Elaborate later on, and include more than just CT.
- Pointed out that our abstract setting is not 100% claimant model. For
example, the claimant model does not say much about role interaction.
- Fixed missing and broken links.
|
