[Trans] How to redact an entry

Ben Laurie <benl@google.com> Tue, 15 November 2016 19:49 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F0612956C for <trans@ietfa.amsl.com>; Tue, 15 Nov 2016 11:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vX5qSNr5G-p for <trans@ietfa.amsl.com>; Tue, 15 Nov 2016 11:49:20 -0800 (PST)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064AC129556 for <trans@ietf.org>; Tue, 15 Nov 2016 11:49:20 -0800 (PST)
Received: by mail-vk0-x22f.google.com with SMTP id x186so97680873vkd.1 for <trans@ietf.org>; Tue, 15 Nov 2016 11:49:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=YqK5/6deFwjCRtEP69X9hfNPv3orN1kwnSoekJe2B1Y=; b=NXQCRDq5c6bO9o5e8+ZQP33r41VtdhtESwJoo6T/bRcSHmJ9gJe1FLXHFZuWFFt3ge MlhDtxcKQjKUvdloW+WcexsoE1OSVJuOW9AU0FdJT0NIhO/tos7zxaeV5i3uuKxnAbC8 O9YFbyHG50GnZvPgMLHl2S/v33TUBdzmLikhADmiVOlN9KuzEk8hvt7iKptWhVDbwiUr RqKT/UOO2RiCYr3Lk068g70V4bEzGSNrWXgTOJYYAUGCKqWZg5Pk//7D0tjoC/FgEK9t nizXr+BpJgEDcRaxqo4P6Q16Y5adLKReYL/kX/dtBfgDoXge0oapEo6iW0hjdrZYy0la Fu2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YqK5/6deFwjCRtEP69X9hfNPv3orN1kwnSoekJe2B1Y=; b=QCzSO0rhzNeFS2PTr2RT9KdS6JPM4Y4nLKkw2pppD6jZZ/uCIMInjUw8OEY9fpLrXO KHmAdpkLx7J9fiQKTJqtF1wWHOMulbYnPzx6leEBzP1blDFaV7BWAJk2ARJweywSSIHw x48kJ83IkSV6px8LUK6LNlAu8H5VJVlJ+3ybWruBRDwv0qxBkNzfSa6nAeOQqAYSYwER dR89XAPMpJg0V9l5ZUJCOSZ68Uh0BTGwdF5yH5aCq0DpP2Khfh1+vI0WInijCd5kAlGl XRwieGujuPONK0r5Vqk2+DYAwT7uk49SuacD4ipvE0iw7ITwT3NFx8s8vFFnkvO/T5E/ f5gg==
X-Gm-Message-State: ABUngvdCNnbxbSAeN2fsfI/DOzZETck/HbUNvRHKZoL7zLI+T/W/wumnE2ets94eaVlVzugg0gZ395d+bUpR+sdZ
X-Received: by 10.31.174.2 with SMTP id x2mr14595957vke.40.1479239358881; Tue, 15 Nov 2016 11:49:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.162.67 with HTTP; Tue, 15 Nov 2016 11:49:18 -0800 (PST)
From: Ben Laurie <benl@google.com>
Date: Tue, 15 Nov 2016 19:49:18 +0000
Message-ID: <CABrd9SSeePrsNq8ERjxpbEvUAdyb=yQOGAom0qh9SZMoP=nsMw@mail.gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/sTxETM1Q92puLNnXB3uJcsp2VZk>
Subject: [Trans] How to redact an entry
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 19:49:21 -0000

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. :-)