Re: [perpass] Draft charter for a Transparency Working Group

On 6 January 2014 17:20, Robin Wilton <wilton@isoc.org> 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 <kent@bbn.com> 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
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>
>