[Trans] Modularity and reuse

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

MIME-Version: 1.0
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
Precedence: list

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

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


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

http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-01

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/

[Trans] Modularity and reuse Phillip Hallam-Baker