| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
cf commit a242308c
|
|
|
|
|
|
| |
Needed for being able to verify signatures.
Also, remove struct statement since we won't expose it and have no use
for it.
|
|
|
|
| |
See details in proposals/2022-01-log-url.
|
|
|
|
|
| |
- Remove final "/" from log URL definition (more readable API doc)
- Resolve XXX that ln5 looked in to a while back (don't be strict).
|
|
|
|
| |
See details in proposals/2022-02-end-user-terminology.md.
|
| |
|
|
|
|
| |
The majority of this commit is from ln5, thank you.
|
| |
|
|
|
|
| |
Refer to doc/proposals/2021-11-ssh-signature-format.md for details.
|
|
|
|
|
|
|
|
|
| |
Refer to
doc/proposals/2022-01-tree-head-endpoint
doc/proposals/2022-01-no-quick-tree-head-endpoint
for details.
|
|
|
|
|
|
|
|
|
|
| |
Refer to doc/proposals/2021-11-remove-arbitrary-bytes.md for details.
Since our proposal left the exact terminology undefined, this commit
took a stab at that. The main idea was to keep referring to what we
have in a leaf and what is being signed as a _checksum_. This ensures
that we are not undermining or stepping away from our core of "signed
checksums". It seemed quite natural to refer to a checksum's preimage.
|
|
|
|
| |
See decision in archive/2022-01-04--meeting-minutes.
|
| |
|
|
|
|
| |
Refer to doc/proposals/2022-01-add-leaf-endpoint for details.
|
|
|
|
| |
Refer to doc/proposals/2022-01-domain-hint for details.
|
|
|
|
| |
Refer to archive/doc/proposals/2022-01-get-endpoints for details.
|
|
|
|
| |
See doc/proposals/2022-01-how-to-use-proposal-folder for details.
|
| |
|
|
|
|
| |
It did not become part of the SSH signing format proposal after all.
|
| |
|
|
|
|
| |
Sigsum logs should now use open-ended shard intervals.
|
|
|
|
|
| |
We get the remove arbitrary bytes proposal "for free" when switching to
a signing format that is backwards-compatible with SSH signatures.
|
|
|
|
| |
We decided to implement open-ended shard interval on 2021-11-23.
|
| |
|
|
|
|
|
| |
Punting on all crypto agility for now. Let's make a separate proposal
out of the contents of the section "Related questions".
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
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
|
| |
|