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? _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
