[saag] Current status of Blockchain/Merkle Tree type things in IETF

Phillip Hallam-Baker <[email protected]>
Newsgroups gmane.ietf.saag
Message-ID <CAMm+LwgUoghDwZgNifEvp=CH_hTVCZMjQRa4CyxgNX-sTvkaAw@mail.gmail.com>
All,

Over the years, there have been many proposals for Merkle Tree like things.
I thought there was an active working group looking at math for such but
have been unable to find one listed as an active working group. Possibly I
am thinking of a proposal that got to DISPATCH or BOF stage but not
further. What I am aware of at this point is

Certificate Transparency
Proposal to redo certificates based on CT like objects dispatched to a
(Montreal?) BOF

The reason I am raising this is that I am currently writing a draft to
propose the DARE Envelope format as a JOSE WG item and trying to decide
whether to include DARE Sequences which address a very specific problem
with XML, JSON, CBOR and pretty much every serialization format we use
which is that the serialization format assumes that the data is read in the
forward direction and most times, we want to be able to read the last n
from a log of m items where m >> n.

To be clear, I am NOT proposing to include the mechanism for signing
sequences because there are many different ways to do that. This is only a
mechanism to wrap some blobs of serialized data for easy handling.

The basic DARE envelope is:

varint - envelope type
varint, bytes - unsigned header, set up the signature/encryption
varint, bytes - signed header, typically metadata
[varint > 0, bytes] - data chunks, any number containing the content payload
varint, bytes - trailer containing the signature data

This format supports all the usual capabilities we have come to like from
formats like CMS etc. It is not necessary to buffer the signed/encrypted
content, the chunk construction allows data of unknown length to be
processed efficiently with bounded memory usage.

I am proposing to use MOQ varints for this because I have a MOQ aligned
file/message exchange scheme using the same DARE envelope format. The
varint scheme is 20 lines of code. I don't want to 'reuse' another spec
because then I am going to end up pulling in a 5,000 line library and as
you will see, it doesn't help at all for sequences.

The headers and trailers can be in JOSE, COSE or even XML Signature and
encryption as the application demands. The envelope type specifies the
serialization format used.


The DAR Sequence is similar:

varint - sequence type (same registry as envelopes)

Followed by a sequence of n entries:

varint total length of entry
varint, bytes - unsigned header, signature setup and value, encryption setup
varint, bytes - signed header, typically metadata
varint, bytes - the content payload
tnirav total length of entry

A tnirav is simply a varint written backwards. And that allows the sequence
to be scanned backwards.

This structure does NOT support unbuffered construction unless the
application can backtrack and fix up the length specifier.


The first and the last entries being the easiest to obtain, these can be
used for special purposes. The first containing metadata applying to the
whole sequence. The last containing e.g. an end of sequence integrity
check, an index of the sequence contents, etc. These are all out of scope
though. Only the basic tagging and bagging is needed in the first instance.

Thoughts? Pointers?

PHB

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.