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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie <[e-mail]> wrote:

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


I disagree. The Merkle tree part is only relevant to verification
efficiency. And I would want to look into it a lot further before
committing to that particular approach due to the Micali patents and other
patents applying Merkle to catenate certs.

The property that is important is the chaining of one hash to the next and
that is the property that is definitively out of patent.


For email security I am not planning to use trees at all or at least not in
that way. Chains are simpler to debug and the additional overhead largely
irrelevant as all the certificate validation and evaluation can be done
offline.

Latency is not a concern as this is a store and forward protocol or a
messaging protocol. The time it takes someone to pick up the phone is
always going to be much longer than any key evaluation process.

-- 
Website: http://hallambaker.com/