Re: [Trans] Verifying inclusion proof

[Matt Palmer <[e-mail]>]

On Tue, Jun 30, 2015 at 01:30:32PM +0100, Ben Laurie wrote:
> On 30 June 2015 at 00:04, Matt Palmer <[e-mail]> wrote:
> > On Mon, Jun 29, 2015 at 12:29:47PM +0100, Ben Laurie wrote:
> >> On 28 June 2015 at 23:06, Matt Palmer <[e-mail]> wrote:
> >> > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote:
> >> >> On 28 June 2015 at 16:05, Stephen Kent <[e-mail]> wrote:
> >> >> > IETF standards need to be unambiguous. Code is very helpful, but it is not a
> >> >> > substitute
> >> >> > for a rigorous description of how to resolve the issue that Onderj raised.
> >> >>
> >> >> Whilst I am not necessarily opposed to that, there has to be a point
> >> >> at which you stop explaining what can be worked out given existing
> >> >> information. The RFC does state how the hash is calculated, from which
> >> >> it is clear what the placement of each node is in the hash
> >> >> calculation.
> >> >
> >> > s/it is clear/it is possible to determine/
> >> >
> >> > I would be in favour of more clarity around exactly how the inclusion proof
> >> > is represented; I recall having significant trouble comprehending how
> >> > inclusion proofs "worked", and ended up examining existing operational logs
> >> > and using trial and error to determine how the inclusion proof was
> >> > presented.
> >>
> >> Feel free to open a ticket. However, the mechanism for verifying
> >> inclusion in a Merkle tree is widely available in standard texts, for
> >> example 3.3 in http://www.emsec.rub.de/media/crypto/attachments/files/2011/04/becker_1.pdf.
> >
> > That document doesn't appear to be referenced in 6962bis, nor would it, I
> > assume, answer the question "how is the inclusion proof represented in the
> > response to get-sth-consistency".
> 
> Fair enough. Do you have proposed text?

Not at the present time.  I'll add it to the todo list.

- Matt