A suppression of a fake gmail.com cert in the logs so google will never know a rogue cert was issued and used?
Sent from my iPhone > On Nov 16, 2016, at 12:54, Phillip Hallam-Baker <[email protected]> wrote: > > That particular attack is certainly an issue for some linked notary logs. The > point of CT is to prevent insertion attacks, to ensure that only items > entered into the log are notarized. > > What is the harm you see being caused by suppression? Remember that a party > that has the actual data can still prove that it was enrolled. > > >> On Tue, Nov 15, 2016 at 10:46 PM, Paul Wouters <[email protected]> wrote: >> How can I as log consumer detect the difference between the log removing >> illegal content and the log being compelled by a government to hide a rogue >> certificate? >> >> Sent from my iPhone >> >>> On Nov 16, 2016, at 10:01, Phillip Hallam-Baker <[email protected]> >>> wrote: >>> >>> >>> >>>> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie <[email protected]> wrote: >>>> Eran asked me to briefly describe how redaction in a transparency log >>>> would work. >>>> >>>> First, we introduce a new leaf type, "Redacted". The content of this >>>> leaf is simply the hash of the original leaf, the entry number of the >>>> redaction reason entry (see below) and a signature over the content by >>>> the log key. >>>> >>>> Rather than hashing this entry, verifiers simply use the enclosed hash >>>> to calculate the tree hash. >>>> >>>> Secondly, we introduce a second new leaf type, "Redaction reason". >>>> This leaf contains two things: the entry number of the redacted entry >>>> and a textual explanation of why it was redacted (possibly we need to >>>> get a little more elaborate here, but perhaps the simplest thing to do >>>> is to allow it to include URLs to point to any supporting material). >>>> This leaf type would be hashed in the usual way. >>>> >>>> Observers of the log can verify that every redacted entry has a >>>> corresponding redaction reason entry, and if not, can produce proof it >>>> does not (this is why the redacted entry has to be signed directly). >>>> >>>> Note that the redacted entry could not include the entry number of the >>>> redaction reason, if preferred, though that would force an observer of >>>> that entry to download the whole log to verify the reason and also >>>> would make proof of non-compliance bulky. :-) >>> >>> I decided I had to do something of this sort in the Mesh notary log. It is >>> probably a good idea to do it as a matter of course. >>> >>> Lets consider the general case for a moment, what happens if someone puts >>> some child pornography into the log. Obviously you can't publish it or you >>> go to jail. So you have to take it out which breaks the log. >>> >>> So either you have to devise a scheme that you are certain cannot be used >>> to publish abusive material or you have to have a way to suppress it >>> either. I think the second approach is better. >>> >>> >>> Of course putting bad stuff in a Trans log would be a lot more effort than >>> putting it into the blockchain or the like. But don't think it is >>> impossible. I have a few attacks that are worrying enough not to want to >>> share in public. The sort of thing that has Special Branch making house >>> calls. >>> >>> So I would hash the received data values before enrolling the hash in the >>> notary log as a matter of course. >>> _______________________________________________ >>> Trans mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
