[Trans] Modularity and reuse

Phillip Hallam-Baker <hallam@gmail.com> Fri, 14 March 2014 14:39 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 24ED41A0154 for <trans@ietfa.amsl.com>; Fri, 14 Mar 2014 07:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eAJ29nyRVYaO for <trans@ietfa.amsl.com>; Fri, 14 Mar 2014 07:39:29 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AB61C1A014F for <trans@ietf.org>; Fri, 14 Mar 2014 07:39:28 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id y1so1823714lam.20 for <trans@ietf.org>; Fri, 14 Mar 2014 07:39:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bxPKxC/iMrdQ4kngJwI+T+Y5L/vWLxTH++QKvZFA1Y4=; b=a20YdVXbDo86O3gPbaaH/QuFqOzUF5hcEhnp8uCW4ldBBu7Ntm6wpcwPeo2UCZRv5W Kxxl2jYceecCnA7/VxKJ7UFhMw+QyhTiezASOCBFPhp7hQ8PDmXLBbhI3NwJOTBLTcUd aCODmjBXhqIFdnleYy9rl4yGmuBr7XB9WdLZAQ3+OxwFFsv3XYV4rfKwGuhPJei4unES pAU504zc3zHuG/yh5+3C20xED9xIyHVoOhc3RdaWSwVFOcb4zBCQ1Xs5Nxgo3Xzz81pF m9sdq7iBnI/X28DBxejpzVCDBg9xcd9tl13MLcX0p462SxBHTgu8pEftMS2oxj1PjwMS JfPw==
MIME-Version: 1.0
X-Received: by with SMTP id q7mr31968lbv.64.1394807961250; Fri, 14 Mar 2014 07:39:21 -0700 (PDT)
Received: by with HTTP; Fri, 14 Mar 2014 07:39:21 -0700 (PDT)
Date: Fri, 14 Mar 2014 10:39:21 -0400
Message-ID: <CAMm+Lwh=zVgoMXtE8Afa6SpLB+-EQXH=Vq-k56=NzjYw42r6Sw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="14dae94736b50f6fbe04f4920935"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DVdoxWwMsbt0puv-GCsHEugCe5g
Subject: [Trans] Modularity and reuse
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: <http://www.ietf.org/mail-archive/web/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: Fri, 14 Mar 2014 14:39:31 -0000

Having taken a look at the data structures I have come to the following

1) The JSON service protocol can with minor changes be made generic to any
sort of catenate log based notary protocol.

2) The log data format is so tightly optimized to the specific CT
implementation that any change to the data structures is going to be very

The sort of changes I suggest making to the service protocol are pretty
minor. The main change being that all the data needed to process a message
should be in the JSON encoded structure. Relying on particular URL formats
is considered to be very bad design practice (see the off my lawn draft).


URIs should be used as a way of routing messages to end points. Depending
on data encoded in URIs is like depending on the format of an IP address or
DNS name. It is a layer violation.

We need to rev this protocol in any case so that a client can request a
consistent set of data in one operation rather than attempt multiple
retrievals and possibly get out of sync data.

I propose breaking the service protocol out into a separate document Which
can then be reused by other catenate notary style protocols. I think this
will improve readability as well.

The log data format has been designed to be as compact as possible and so a
position based data structure is used. The internal data structures use
fixed length codes and in some cases fixed length fields.

This avoids wasted bytes which is important in the CT scenario but I would
not want to be having to give court testimony based on those formats. Which
is one of the primary purposes other uses of a notary are likely to involve.

Even attempting a meta-notary based on this format is going to be
difficult. Because a meta-notary is likely to be based on a skip-list or
other sequential log type approach rather than a Merkle Tree.

The practical upshot is that rather than just adding a version attribute to
the service protocol we probably want to add a format parameter. Since I
expect that the CT format will develop independent of other formats.

Website: http://hallambaker.com/