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.
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
