Re: [Trans] How to redact an entry

Following up on this thread, after a few discussions about it in online &
offline forums:
- It is necessary to have the "Redaction reason" entry in the log to commit
the log to the redaction of a particular entry and avoid allowing the log
to present redacted/unredacted view at will.
- A few have echoed Phillip's sentiment that once an entry is suppressed
then the suppression reason can't be effectively audited for correctness.
- There was a strong push-back against this mechanism on the basis that it
weakens the basic properties we get from the Merkle tree right now.
Potential problems: What if the "Redaction reason" entry itself was
redacted?
- A suggestion by Peter Bowen was to simply not serve the redacted entry:
The only API method by which a suppressed entry can be obtain is
'get-entries', it's possible to return an error when the range specified
includes a suppressed entry. That suffers from the same drawback of the log
being able to selectively presenting redacted/unredacted view.
- An approach many see as superior is to reduce the chances of having
entries with undesirable content in the log by restricting the certificates
that may be logged (e.g. forbidding certificates with embedded images).

Eran

On Wed, Nov 16, 2016 at 6:20 AM, Phillip Hallam-Baker <ietf@hallambaker.com>
wrote:

> Lets break this down.
>
> In what way is suppression of a previously enrolled certificate different
> to not enrolling the certificate at all?
>
> The only ones I can see is that it means that 1) the CA is off the hook,
> they fulfilled their duties and 2) the fact that suppression has occurred
> is visible.
>
>
> CT relies on there being some feedback mechanism to detect unenrolled
> certs, the same would apply to suppressed certs.
>
> So let us imagine that a government coerces a CA to issue a bogus cert and
> then coerces a notary to suppress it. What next?
>
> Well first off anyone who has a copy of that cert taken from the
> repository before the suppression is going to hard look at it. So the
> chance of people being aware of the suppression and working out the reason
> for it is essentially 99%.
>
>
> A person formerly very senior in NSA told me that the governing paradigm
> post Snowden was 'NOBUS': Nobody but us. Sure they might want to perform
> this type of attack if they think they can get away with it but they won't
> do things that are liable to get caught.
>
>
>
>
> On Wed, Nov 16, 2016 at 6:48 AM, Ben Laurie <benl@google.com> wrote:
>
>> On 16 November 2016 at 11:39, Paul Wouters <paul@nohats.ca> wrote:
>> > On Wed, 16 Nov 2016, Ben Laurie wrote:
>> >
>> > (no hats on)
>> >
>> >> 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.
>> >
>> >
>> > It was an example. the core isuse is, how can a consumer determine the
>> > log censored itself with a valid reason, versus an attack, compromise,
>> > having been compelled, or for financial gain or any other invalid
>> reason?
>> >
>> > Using a hash of a removed cert won't allow anyone to verify the reason
>> > for removal. And clearly the content cannot remain their either. It's
>> > a catch22.
>>
>> This is why the redaction reason entry exists, so that there _is_
>> something to reason about. If you (a consumer) are unconvinced by the
>> reason, well, there are public fora where you can voice your concerns.
>>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>