On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie <[email protected]> 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/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
