IETF Logo Mail Archive

Re: [Trans] Verifying inclusion proof

Ben Laurie <benl@google.com> Sun, 28 June 2015 15:26 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404FA1A8827 for <trans@ietfa.amsl.com>; Sun, 28 Jun 2015 08:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 rNADQbfbKi5o for <trans@ietfa.amsl.com>; Sun, 28 Jun 2015 08:26:52 -0700 (PDT)
Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (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 4261B1A8824 for <trans@ietf.org>; Sun, 28 Jun 2015 08:26:52 -0700 (PDT)
Received: by vnbf129 with SMTP id f129so6488908vnb.5 for <trans@ietf.org>; Sun, 28 Jun 2015 08:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pvGIxNCXpZ8F62LE7oVZbGf2sFhKk4M4YnAWClUCt04=; b=Mi+/BsbiiS2I7q9vjRRRElHM82VBIQgFBsZGxbs+gWv/Bm7wxcXQ/aBHwGNkqB0P0x 0J/IPw3qyS9jNArAS2Sj/5jrp5kXnFC1hafgccYrH/XNW62S5w6tVbC2e+Gl5M8ZXBsn mL5UACiTCt5F+Zba5v+/hoUPqnVG4xOGH1eUyGe8TPWTcfvIKLU74qAg8lqDyyxjolUO asFHE4Xdl3xkgaZQs+WO8DILb3Kn/t6bxIXFcjxWXFVeVOSetkRcA64MPYF9O2BtYwE8 kxbHBEPts6yoJUR2mJFRiA65d1ibxVAVsA8ehnUqYSaMIsFwrrsOFEH/hZnxvMinCQxu MMAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pvGIxNCXpZ8F62LE7oVZbGf2sFhKk4M4YnAWClUCt04=; b=Bo/osrFwIdGU9LbC6ye8/CcTnQLREvs6npSeMKlqqo1QWi2vJJnPTJiXDRQSYBMra8 c1VT66MIWE6lDHc2j8CFzt6F1ehVft268YhID1UksZJ8KwlaPnFD/Zweh23mXCxnStPq xr/fSsC4oDqxSQJMjGXt8d+OGRwLmd8wqsAvItdypd8eq2sRjp3u2eIH2Xj7ROY71CFA CWJFMFkk24vaOtL3Jv+0EXmly5DbzSWqkWVuadAvEsG0W1daEJkC628TcjHRT0Egzd2h /+UvvFyGUdnlbt6QeO6r2MCKxBAWPxZ4i5LbfrhYny0qWPXzGeqzKCO0r8FUTHxhtUsl U8NA==
X-Gm-Message-State: ALoCoQnHLpK/kvlsT5YboLSFYAWfYVvf50UV1YbHeM3zsd2Ss8Z7/b156Du7Sj4zPiwrt8WJG/az
MIME-Version: 1.0
X-Received: by 10.52.75.201 with SMTP id e9mr9279683vdw.33.1435505211412; Sun, 28 Jun 2015 08:26:51 -0700 (PDT)
Received: by 10.52.76.6 with HTTP; Sun, 28 Jun 2015 08:26:51 -0700 (PDT)
In-Reply-To: <55900D1D.2030009@bbn.com>
References: <558D61DE.8020402@nic.cz> <CACM=_OeTnNCk+VSiQ1E5T2_a7YkxwxZ2w8HJSg13wtVc2wQUfA@mail.gmail.com> <55900D1D.2030009@bbn.com>
Date: Sun, 28 Jun 2015 16:26:51 +0100
Message-ID: <CABrd9SQV6tybHwgo=ZATEPjhsV64=5=O-fi10pcwHnAHCyArDA@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/Bo_mAlb_jk1QEw-gkSp-tCV9XfQ>
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Verifying inclusion proof
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 28 Jun 2015 15:26:53 -0000

On 28 June 2015 at 16:05, Stephen Kent <kent@bbn.com> wrote:
> IETF standards need to be unambiguous. Code is very helpful, but it is not a
> substitute
> for a rigorous description of how to resolve the issue that Onderj raised.

Whilst I am not necessarily opposed to that, there has to be a point
at which you stop explaining what can be worked out given existing
information. The RFC does state how the hash is calculated, from which
it is clear what the placement of each node is in the hash
calculation.

v2.23.0 | Report a Bug | By Email