On Tue, Jun 30, 2015 at 01:30:32PM +0100, Ben Laurie wrote: > On 30 June 2015 at 00:04, Matt Palmer <[email protected]> wrote: > > 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". > > Fair enough. Do you have proposed text?
Not at the present time. I'll add it to the todo list. - Matt _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
