Re: [Trans] How to redact an entry

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 <ietf@hallambaker.com> 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 <paul@nohats.ca> 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 <ietf@hallambaker.com> wrote:
>>> 
>>> 
>>> 
>>>> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie <benl@google.com> 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
>>> Trans@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trans
> 