On Mon, Jun 29, 2015 at 12:29:47PM +0100, Ben Laurie wrote: > On 28 June 2015 at 23:06, Matt Palmer <[email protected]> wrote: > > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: > >> On 28 June 2015 at 16:05, Stephen Kent <[email protected]> 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". - Matt _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
