Subject: [jose] Binary JSON Signing and Encryption

From: John Mattsson <[email-masked]>
Date: Fri, 4 Jul 2014 23:26:03 +0000

One of the outcomes (from a breakout session) of the recent W3C workshop
on the Web of Things (http://www.w3.org/2014/02/wot/) were that for
constrained devices, more lightweight alternatives to JSON are desired.

It was discussed that one of the binary JSON formats (e.g. RFC7049 CBOR)
would be better alternatives for constrained devices using 802.15.4, and
that e2e secure binary JSON would be needed in some applications and
architectures.

Is anyone aware of any work on securing binary JSON?

John Mattsson

----------------------------------------------------
JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 5 Jul 2014 10:27:58 +0200

> Is anyone aware of any work on securing binary JSON?

CBOR certainly was designed with the knowledge that JOSE was going to be available.
Preliminary analysis indicated that an adaptation of JOSE to CBOR should be possible with a limited amount of work.
So our plan here at TZI is to contribute to that work as soon as the work on JOSE is completed.

Maybe we can have a short hallway meeting in Toronto between people interested in this space.

Grüße, Carsten

(I’m not particularly fond of calling CBOR a “binary JSON”, but I read this usage here as a shorthand for “a binary-capable representation format in the spirit of the JSON data model”, which CBOR is.)

---

From: Tim Bray <[email-masked]>
Date: Sat, 5 Jul 2014 10:34:24 -0700

If you move from JSON to something that’s not JSON, you lose a whole lot of
super-developer-friendly libraries and tooling, all very fully-debugged and
performant; and you also lose interchange opportunities.  So you should be
really sure that you actually get a significant advantage in one or more of
performance, code size, or data size.

I personally just haven’t seen the evidence that the binary-ness of a
format guarantees really significant wins. Specifically, my experience is
that time spent deserializing message formats into program data structures
is often dominated by memory management code.  I’m not saying that some
sort of binary JSON-like message format is necessarily bad, but I am saying
that the costs are significant, and you should insist on quantitative
evidence of a win before you impose those costs on your community.

On Fri, Jul 4, 2014 at 4:26 PM, John Mattsson <[email-masked]>
wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Richard Barnes <[email-masked]>
Date: Sat, 5 Jul 2014 14:36:47 -0400

I implemented a msgpack serialization in PyJOSE in literally ten lines of
code.
https://github.com/bifurcation/pyjose/blob/master/jose/serialize.py#L183

Of course, you still have to have a JSON parser if you want to support
protected attributes.  Otherwise, it's completely trivial -- the text
fields are text fields, and the binary fields are binary fields.   But of
course, there is no coherent use case for protected attributes (vs. adding
things to the payload), so it doesn't seem like it would be super painful
just to omit protected attributes from an implementation.

Sure is a shame that we baked in a JSON dependency, isn't it?

--Richard

On Sat, Jul 5, 2014 at 4:27 AM, Carsten Bormann <[email-masked]> wrote:

> Preliminary analysis indicated that an adaptation of JOSE to CBOR should
> be possible with a limited amount of work.
> (I’m not particularly fond of calling CBOR a “binary JSON”, but I read
> this usage here as a shorthand for “a binary-capable representation format
> in the spirit of the JSON data model”, which CBOR is.)
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 6 Jul 2014 01:11:58 +0000

Carsten, could you give a presentation on TZI's approach to the JOSE working group in Toronto?  I think that would be valuable for all concerned.

I understand that agendas will be published Monday, so you should request time from the chairs soon.

				Best wishes,
				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Saturday, July 05, 2014 1:28 AM
To: John Mattsson
Cc: [email-masked]
Subject: Re: [jose] Binary JSON Signing and Encryption

Grüße, Carsten

(I'm not particularly fond of calling CBOR a "binary JSON", but I read this usage here as a shorthand for "a binary-capable representation format in the spirit of the JSON data model", which CBOR is.)

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 6 Jul 2014 07:14:28 +0200

> Carsten, could you give a presentation on TZI's approach to the JOSE working group in Toronto?  I think that would be valuable for all concerned.

Certainly.

> I understand that agendas will be published Monday, so you should request time from the chairs soon.

Chairs: consider yourselves requested.
The presentation will be short; most of the slot will be discussion, the time for which is hard to predict.  (Clearly, any remaining finishing work has precedence.)

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Mon, 7 Jul 2014 09:44:09 +0000

On 06/07/14 07:14, "Carsten Bormann" <[email-masked]> wrote:

>> Carsten, could you give a presentation on TZI's approach to the JOSE
>>working group in Toronto?  I think that would be valuable for all
>>concerned. 
>
>Certainly.

I think that’s great.

I think it’s important that the presentation should not only cover how
CBOR works, but also why something more compact than JSON is needed for
some classes of IoT devices. Not only because of processing//memory, but
also for storage, data size (802.15.4), and battery (affected by
processing/receiving/and transmitting).

(See e.g. http://www.w3.org/2014/02/wot/slides/petersen.pdf)

If there is time in the agenda, I could give a five 5 min talk on that.

John

>The presentation will be short; most of the slot will be discussion, the
>time for which is hard to predict.  (Clearly, any remaining finishing
>work has precedence.)
>
>Grüße, Carsten
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 07 Jul 2014 11:49:15 +0100

I've recently realized that JSON Web Signature and Encryption can sign 
and encrypt arbitrary payloads. Only the metadata (headers) are in JSON 
format.
While I do not appreciate/understand how constrained some devices can be 
but I wonder if there could be any significant win by replacing the JSON 
metadata with the binary equivalent, it is likely in 80% there will be 
two/three headers max with some of those headers are the hints on how to 
process the payloads thus bearing no memory requirements...

Cheers, Sergey

On 05/07/14 18:34, Tim Bray wrote:
> If you move from JSON to something that’s not JSON, you lose a whole lot
> of super-developer-friendly libraries and tooling, all very
> fully-debugged and performant; and you also lose interchange
> opportunities.  So you should be really sure that you actually get a
> significant advantage in one or more of performance, code size, or data
> size.
>
> format guarantees really significant wins. Specifically, my experience
> is that time spent deserializing message formats into program data
> structures is often dominated by memory management code.  I’m not saying
> that some sort of binary JSON-like message format is necessarily bad,
> but I am saying that the costs are significant, and you should insist on
> quantitative evidence of a win before you impose those costs on your
> community.
>
>
> On Fri, Jul 4, 2014 at 4:26 PM, John Mattsson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 07 Jul 2014 13:12:55 +0200

My recent investigations on using OAuth for IoT use cases (see
http://www.ietf.org/mail-archive/web/ace/current/msg00677.html)
indicates that there is not that much JSON. There are three places where
JSON may show up:

 * C->AS Request
 * C<-AS Response (including access token)
 * C->RS Request (including access token)

The access token may indeed be the biggest part of that JSON related
content and that could be avoided.

Of course, there is the actual data communication. It is not clear
whether there is any need for JOSE there since current work focuses on
the use of DTLS.

Of course, it would have been nice if the JOSE specs would have
separated the encoding from the rest of the spec to make it re-usable in
non-HTTP-based Web contexts.

Ciao
Hannes