On Fri, Mar 28, 2014 at 5:09 AM, Thomas Ristenpart <[email protected]> wrote: > I haven't been following through all the details of this exchange, so > sorry if this was brought up already, but you might want to check out > this paper: > http://www.internetsociety.org/doc/enhanced-certificate-transparency-and-end-end-encrypted-mail
This proposes 2 merkle trees: using one as an authenticated dictionary, while also entering the (certificate, hash-root-of-auth-dictionary) pairs into a CT-style append-only merkle tree. The claimed advantage of this over an authenticated dictionary alone is that adding the CT-style tree enables efficient proofs that one log is an "extension" of another. It's unclear to me why this is useful. The paper argues: """ Linearity: It is vital that the log is a single linear record. If the log maintainer can create different versions of the log to show to different users, the security is lost. Linearity is maintained in two ways. Firstly, whenever a user interacts with the log, it requests proof that the current snapshot is an extension of the previously cached snapshot.[...] Second, gossip protocols [30] can be used to disseminate values of the log. This means that users of the log (that is, client browsers) need to have a way to exchange with other users the value of the hash of the log that they have received. At any time, a user can request proof that the snapshot currently offered by the log is an extension of a previous snapshot received through direct communication with other users. """ I agree that we want to prevent "abuse of the change mechanism to make temporary changes shown only to a subset of relying parties", as Ben puts it [1]. But I don't see why this requires complicated "proofs of extension". In Ben's "Revocation Transparency", he proposes the simpler idea of entering the root-hashes of the authenticated dictionary, alone, into an append-only log [1,2]. I'll argue for an even simpler idea: clients maintain a collision-resistant hash over all authenticated-dictionary root-hashes. Clients can compare this hash. If it differs, the log must have provided different root-hashes. If these root hashes are signed, this can be used to show log misbehavior. Is that sufficient? Am I missing something? Trevor [1] http://www.links.org/?p=1272 [2] http://sump2.links.org/files/RevocationTransparency.pdf _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
