Re: [Trans] How to redact an entry

On 16 November 2016 at 11:16, Ben Laurie <benl@google.com> wrote:
> On 16 November 2016 at 03:46, 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?
>
> Court orders are court orders. That issue is not in the log's domain.

BTW, anyone who sees the actual cert would presumably verify it, find
the entry is redacted, and publish the cert (or decide they were also
bound by the order cited in the redaction reason and not publish it
:-).

We could say, for example, that a cert whose entry has been redacted
MUST NOT be used further.

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