On 6 January 2014 17:20, Robin Wilton <[email protected]> wrote: > Hi all - > > A further suggestion inline. One motivation for my suggesting a change is > that I am instinctively uneasy when the word "proof" crops up in this kind > of context. I think what we're doing is providing the means to accrue > evidence, on the basis of which someone can make an inference as to whether > correct log behaviour has been recorded.
My suggestion already eliminated the word "proof". But I quite like your suggestion, too. Note, however, we are on the wrong lists. I will post a revised draft charter to therightkey shortly. > > R > > > On 6 Jan 2014, at 17:02, Ben Laurie wrote: > > On 30 December 2013 15:36, Stephen Kent <[email protected]> wrote: > > Ben, > > > How's this? > > > [1] A cryptographically verifiable log is an append-only log of hashes > > of more-or-less anything that can prove its own correctness > > cryptographically. > > > For example, from RFC 6962: “The append-only property of each log is > > technically achieved using Merkle Trees, which can be used to show > > that any particular version of the log is a superset of any particular > > previous version. Likewise, Merkle Trees avoid the need to blindly > > trust logs: if a log attempts to show different things to different > > people, this can be efficiently detected by comparing tree roots and > > consistency proofs. Similarly, other misbehaviours of any log (e.g., > > issuing signed timestamps for certificates they then don't log) can be > > efficiently detected and proved to the world at large.” > > > See RFC 6962, > > http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf > > and http://www.links.org/files/RevocationTransparency.pdf for > > background. > > > Sorry to be so late in responding; holidays ... > > > Likewise. > > The text describing how 6962 uses Merkle trees is good. I think the > > phrase "prove its own correctness" is way too broad. The example > > you cite shows how to demonstrate internal consistency for a log, > > and to enable third parties to verify certain lob properties. That > > is much narrower than what the term "correctness" implies. > > > How about, instead of "can prove its own correctness > cryptographically", we say "allows efficient verification of > behaviour"? > > > "A cryptographically verifiable log is an append-only log of hashes, > structured in such a way as to provide efficiently-accessible, > cryptographically-supported evidence of correct [log] behaviour". > > That way, you capture the following: > > - use of hashing/cryptographic mechanisms to maintain the integrity of the > evidence trail > - reference to the relevance of structure (Merkle trees) > - de-coupling of the evidence (signed records) from what it is that the > evidence is intended to show (correct behaviour) > > Hope this helps - > > Robin > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
