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

[Ben Laurie <[e-mail]>]

On 30 December 2013 15:36, Stephen Kent <[e-mail]> 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"?