ietf
[Top] [All Lists]

Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose)

2015-05-27 14:54:32
On Wed, May 27, 2015 at 6:56 AM, Carsten Bormann <cabo(_at_)tzi(_dot_)org> 
wrote:

On 23 May 2015 at 04:16:00, Nico Williams (nico(_at_)cryptonector(_dot_)com) 
wrote:

I should clarify that my objection is to a working group IF a JOSE->CBOR
mapping is trivial enough,

The CBOR data model is a superset of the JSON data model, so a trivial
translation of JOSE to CBOR is indeed trivial.

It is a rather complex superset.


Doing such a trivial mapping would be completely misguided, though, as
CBOR has additional capabilities, and the efficiencies we need in the
constrained node network environment are indeed made possible by those
additional capabilities [1].

I note that you still haven't answered my challenge on data encoding
efficiency. My JSON-C encoding shows what can be achieved using the JSON
data model with only the addition of a binary blob data type. I posted the
encoding for the JOSE signing example shortly after Dallas.

What your constrained node example needs is a better encoding for JSON, not
the introduction of yet another encoding for a random data model.

So the main work of the WG will simply be about how exactly to use those
capabilities.  (It all looks trivial on a napkin, but a few bikesheds still
have to be painted.)  Any other hypothetical approach that adds binary
capabilities to the JSON data model will need to do this kind of work, bold
statements to the contrary notwithstanding.

My encoding is generated entirely mechanically. Switching from a text
encoding to binary means simply choosing a different encoding method. Using
compressed tags is slightly more complicated in that a dictionary has to be
compiled, but that is at worst a registration effort.

I repeat that no Working Group effort is required or desired for applying
the encoding to JOSE, ACME or any current or future JSON spec.