[Cryptography] DIME // Pending Questions // Seeking Your Input

[ianG]

On 1/03/2015 05:47 am, Phillip Hallam-Baker wrote:
>
>
> On Fri, Feb 27, 2015 at 5:57 PM, ianG <iang at iang.org
> <mailto:iang at iang.org>> wrote:
>
>     On 27/02/2015 16:08 pm, Ladar Levison wrote:
>
>         Hi,
>
>         1. While I’ve identified the majority of the functionality
>         associated
>         with the access protocol (DMAP), my attempts to document the
>         specifics
>         keep getting sidelined by a single question: */should DMAP be a line
>         based protocol, like IMAP (and POP, and SMTP), or should it be
>         designed
>         as a JSON-RPC protocol, like the Magma camelface, or JMAP?/* See:
>
>         https://github.com/lavabit/__magma.classic/raw/master/docs/__magma.web.api.pdf
>         <https://github.com/lavabit/magma.classic/raw/master/docs/magma.web.api.pdf>
>
>
>
>     For my money, binary.  Line-based or JSON are good if you are
>     working with lots of random implementations of low quality, but for
>     security work, it is easier to work in binary.  Be precise about
>     sodding everything.
>
>
> +1
>
> BUT!
>
> Pretty much the whole Web Services world is going to JSON because it is
> a simple data model that is widely supported. Unlike XML there is pretty
> much only one way to serialize a data stream on the wire rather than fifty.


Sure, JSON might beat XML, and JSON in binary would be a good thing.

But, they are both *general* data formats and one thing we know from 
security is that we don't want general, we want specific.  Close off 
stuff not open it up.


> Which is why some of us suggested that we would like a binary encoding
> for the JSON data model so that an encoder could emit either and a
> decoder could read either.
>
> I wrote this up as:
>
> https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/
>
> JSON only uses 7 bit ASCII code points for control data. That leaves
> 128+ data points for tagging binary data types which is more than enough.
>
> All that is really essential to encode crypto data nicely is an option
> to encode text strings and data blobs as length-data items.

Right, we need numbers, length-data items and everything can be 
constructed from that.

If one wants to use JSON in binary as a starting point, sure, do that. 
But call it MySON for My Security Object Notation :)  The point being 
that you can save on a bit of software if you want to, but there isn't 
that much software involved, and being lazy and secure at the same time 
isn't a happy mix.



Another possible way to go -- if your religion is "JSON saves" -- is to 
look at ProtocolBuffers or the other forms out there (I forget the names 
of the others but I guess they are equally good.   The reason for 
looking at these is that if you are trying to save effort, you are far 
better off if you can get a leg-up on the parsing of objects by 
generating classes for multiple languages using the tools.

(I've never actually worked with these things...)



iang