[Cryptography] Encodings for crypto

Phillip Hallam-Baker hallam at gmail.com
Mon Feb 17 17:06:50 EST 2014

On Mon, Feb 17, 2014 at 4:03 PM, Tony Arcieri <bascule at gmail.com> wrote:

> If you're interested in this sort of thing, you should have a look at JSON
> Web Encryption:
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-21
> ...although I can't say I'm really a fan. It seems ugly to me.

That is in part what motivated the initial work. The problem with the JOSE
encryption work is that if you have nested encryption/signature sections
you suffer a cumulative 33% inflation per pass.

So what I started with was 'I just want to be able to do normal JSON
framing but be able to write out a binary chunk efficiently as a length
encoded blob'.

One consequence of my approach is that it is very easy to switch between
the text and binary encodings. Which means that you can use the text
version in the documentation knowing that it is semantically equivalent to
the binary. And you can have tools that interpret the binary and dump out

On Mon, Feb 17, 2014 at 4:46 PM, Theodore Ts'o <tytso at mit.edu> wrote:

>Have you looked at RFC 7049?  Paul Hoffman pointed me to it off-list,
>like your I-D, it's closely aligned to the JSON model.  There is also
>an Apache 2.0 licensed implementation available:

Yes, it is not a good piece of work. Unfortunately Paul was far more
interested in ramming it through the process than listening to anyone's
requirements other than his own. Each time a requirement was raised, his
response was 'this is a private matter, none of your business, go write
your own'. Which is why I appealed the standards track designation.

CBOR is not closely aligned with JSON, it is a new data model which means
that it is rather less interesting than BJSON which does at least have
millions of MongoDB users and is much closer to the JSON model.

The problem here is that a new encoding only has value if it has a chance
of becoming ubiquitous which means meeting all the requirements that are
regularly raised for encodings. So going off into a private 'members only'
club to write the spec removed the main potential benefit. As did moving it
through the process so fast that there was no time to get buy in from the
people who might adopt it in significant platforms as the default.

So instead of one definitive binary encoding we have another binary
encoding to add to the five that existed and were in use before the work
started and one that is not even based on the JSON data model.

For a new encoding to become a natural extension to JSON it has to be easy
for someone to take their existing JSON encoder/decoder and adapt it to
support the new encoding types. And it has to be backwards compatible.

CBOR requires a whole new encoder which is a very different model.

I did manage to convince them that it had to be possible to write data out
in chunks but they punted on the hard problems by making it extensible. One
of the main lessons of JSON is that a data encoding should not be
extensible or have versions.

JSON-B is not an extension to JSON, it is a new encoding that is a superset
of JSON - a different thing entirely. What this means is that when doing
content negotiation, the features are all or nothing. Either a decoder
understands the encoding or it does not. Having optional extensions that
might or might not be understood is a recipe for disaster.

Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140217/f04bf4da/attachment.html>

More information about the cryptography mailing list