[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]