Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Editing after review #29

Merged
merged 5 commits into from
Aug 9, 2024
Merged

Editing after review #29

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
0552312
Improve clarity of references to MHT root hashes
felixlinker Aug 7, 2024
24ece84
Drop ambiguous 'signature'
felixlinker Aug 7, 2024
05520ac
Replace latest/previous with newer/older
felixlinker Aug 7, 2024
a5eb93e
Update draft-ietf-cose-merkle-tree-proofs.md
felixlinker Aug 7, 2024
cc4196d
Update draft-ietf-cose-merkle-tree-proofs.md
OR13 Aug 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions draft-ietf-cose-merkle-tree-proofs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -299,7 +299,7 @@ The identifying index of a leaf node is relative to all nodes in the tree size f

### Receipt of Inclusion

In a signed inclusion proof, the previous merkle tree root, maps to tree-size-1, and is a detached payload.
In a signed inclusion proof, the payload is the merkle tree root which corresponds to the log at size `tree-size`.
Specifications are encouraged to make payloads detached when possible, forcing validation-time comparison.
Profiles of proof signatures are encouraged to make additional protected header parameters mandatory, to ensure that claims are processed with their intended semantics.
One way to include this information in the COSE structure is use of the typ (type) Header Parameter, see {{-cose-typ}} and the similar guidance provided in {{-cwt-header-claims}}.
Expand Down Expand Up @@ -337,9 +337,9 @@ unprotected-header-map = {
* vdp (label: 396): REQUIRED. Verifiable data structure proofs. Value type: Map.
* inclusion-proof (label: -1): REQUIRED. Inclusion proofs. Value type: Array of bstr.

The payload of an RFC9162_SHA256 inclusion proof signature is the previous Merkle tree hash as defined in {{-certificate-transparency-v2}}.
The payload of an RFC9162_SHA256 inclusion proof signature is the Merkle tree hash as defined in {{-certificate-transparency-v2}}.
The payload MUST be detached.
Detaching the payload forces verifiers to recompute the root from the inclusion proof signature, this protects against implementation errors where the signature is verified but the merkle root does not match the inclusion proof.
Detaching the payload forces verifiers to recompute the root from the inclusion proof, this protects against implementation errors where the signature is verified but the merkle root does not match the inclusion proof.
The EDN for a Receipt containing an inclusion proof for RFC9162_SHA256 is:

~~~~ cbor-diag
Expand Down Expand Up @@ -408,13 +408,13 @@ The cbor representation of a consistency proof for RFC9162_SHA256 is:
~~~~ cddl
consistency-proof = bstr .cbor [

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also believe it should be possible for a consistency proof to show consistency between two arbitrary points in the log. So the 'older' / 'newer' frazing seems like an improvement to me also

; previous merkle root tree size
; older merkle root tree size
tree-size-1: uint

; latest merkle root tree size
; newer merkle root tree size
tree-size-2: uint

; path from previous merkle root to latest merkle root.
; path from older merkle root to newer merkle root.
consistency-path: [ + bstr ]

]
Expand All @@ -425,7 +425,7 @@ Editors note: tree-size-1, could be omitted, if an inclusion-proof is always pre

### Receipt of Consistency

In a signed consistency proof, the latest merkle tree root, maps to tree-size-2, and is an attached payload.
In a signed consistency proof, the newer merkle tree root (proven to be consistent with an older merkle tree root) is an attached payload and corresponds to the log at size tree-size-2.

The protected header for an RFC9162_SHA256 consistency proof signature is:

Expand Down Expand Up @@ -461,7 +461,7 @@ unprotected-header-map = {
* consistency-proof (label: -2): REQUIRED. Consistency proofs. Value type: Array of bstr.

The payload of an RFC9162_SHA256 consistency proof signature is:
The latest Merkle tree hash as defined in {{-certificate-transparency-v2}}.
The newer Merkle tree hash as defined in {{-certificate-transparency-v2}}.
The payload MUST be attached.

The EDN for a Receipt containing a consistency proof for RFC9162_SHA256 is:
Expand Down
Loading