Opened 6 years ago

Closed 5 years ago

#180 closed defect (fixed)

Consolidate all Merkle tree data formats and computations

Reported by: rlb@… Owned by: eranm@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:


Right now, the rules for how you (1) represent aspects of a Merkle tree, (2)
generate them, and (3) verify them are scattered through three different
sections of the document. These should be consolidated into one section that
describes all the details of dealing with Merkle tree information. Outline
would be something like the following (assuming the data model consolidation
proposed elsewhere):

# Merkle Hash Trees

overview of Merkle trees, as now ?

## Leaves

definition of EntryDataV2 and leaf hash ?

## Tree Heads

what a tree head does ?
definition of pair hash and TreeHea<D-r>dDataV2 ?

## Inclusion Proofs

what an inclusion proof does ?
definition of InclusionProofDataV2 ?

### Generation

algorithm from current {{#merkle_inclusion_proof}} ?

### Verification

algorithm from current {{#verify_inclusion}} ?

## Consistency proofs

what a consistency proof does ?
definition of ConsistencyProofDataV2 ?

### Generation

algorithm from current {{#consistency}} ?

### Verification

algorithm from current {{#verify_consistency}} ?


If that's too much to go at the front, I would take the functional description
and the data structures and put them up front, then toss all of the technical
details in a section further down.

Change History (4)

comment:1 Changed 6 years ago by rob.stradling@…

  • Component changed from client-behavior to to-be-decided

comment:2 Changed 5 years ago by eranm@…

It would make implementators' lives easier if they didn't have to hunt through the document for the data structures that actually go in the tree.
However the verification algorithms were in appendices because that's just one suggested approach, the definition of the Merkle tree should be enough to figure out the validation algorithm.

Change out for review in

comment:3 Changed 5 years ago by eranm@…

  • Component changed from to-be-decided to rfc6962-bis
  • Milestone set to review
  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…
  • Status changed from new to assigned

comment:4 Changed 5 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.