Subject: [jose] CBOR encoding for JOSE?

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 4 Feb 2015 20:09:51 +0000

There have been some hallway conversations about making the JOSE semantics 
available in CBOR (RFC 7049).  I wanted to start a conversation on the 
JOSE list to see if there was any interest in doing the work here (after a 
recharter), in another working group, or through some other mechanism.

The hope is that the CBOR encoding would be pretty easy to specify.  It 
would do away with the Base64url requirements from the JSON form (reducing 
size and complexity), since arrays of bytes are first-class entities in 
CBOR.  It would not require JOSE/JSON compatibility.

There are several reasons people seem to want this:
- byte size on the wire (CBOR packs more tightly than JSON, and no need to 
Base64)
- size of implementation for constrained devices (CBOR implementations can 
be quite small)
- CPU utilization (CBOR can be more efficient, particularly on small 
devices)

More information on the motivations and suggested approach can be found at:

http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf

(skip to slide 33 if you understand what a constrained network device 
looks like)

There may be other encodings that people want to do.  One I've heard 
mentioned is protobufs 
(https://developers.google.com/protocol-buffers/docs/overview).  I don't 
yet believe there are enough of those other encodings for us to do a bunch 
of work generalizing JSON in an encoding-agnostic way.  Each encoding will 
also need specific handling for what bytes will be protected.  As such, my 
suggestion would be for us to gather a set of lessons learned in the 
process of doing the CBOR encoding that might act as signposts if anyone 
wants another encoding later.

Please discuss.

-- 
Joe Hildebrand

---

From: Mike Jones <[email-masked]>
Date: Wed, 4 Feb 2015 20:30:59 +0000

Thanks, Joe.  I think this could be pretty straightforward.  As I understand it, it would replace uses of JSON and base64url encoding with CBOR, but otherwise reuse as much of JOSE with as few changes as possible, such as reusing the algorithms, header parameters, etc.  A few CBOR-specific features would be needed, such as defining the particular CBOR concatenation used to represent the JWS Signing Input (instead of "ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))", which is JSON-specific).

I agree that any work on this should be CBOR-specific, due to the need for a few CBOR-specific rules such as the one above, while also trying to capture what it would take to do other encodings (essentially, the necessary differences from JSON-specific and CBOR-specific rules), and probably capture that in a non-normative appendix.  A fully generic treatment wouldn't answer necessary questions to achieve interop.

I personally think this work should happen, because of interest from IoT folks, and that it should happen in JOSE, because we already have most of the right experts assembled into a working group.  It won't be hard for interested JOSE members to learn the necessary details about CBOR, and I'm sure Carsten will guide us in that regard.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Joe Hildebrand (jhildebr)
Sent: Wednesday, February 04, 2015 12:10 PM
To: [email-masked]
Subject: [jose] CBOR encoding for JOSE?

There have been some hallway conversations about making the JOSE semantics available in CBOR (RFC 7049).  I wanted to start a conversation on the JOSE list to see if there was any interest in doing the work here (after a recharter), in another working group, or through some other mechanism.

The hope is that the CBOR encoding would be pretty easy to specify.  It would do away with the Base64url requirements from the JSON form (reducing size and complexity), since arrays of bytes are first-class entities in CBOR.  It would not require JOSE/JSON compatibility.

There are several reasons people seem to want this:
- byte size on the wire (CBOR packs more tightly than JSON, and no need to
Base64)
- size of implementation for constrained devices (CBOR implementations can be quite small)
- CPU utilization (CBOR can be more efficient, particularly on small
devices)

(skip to slide 33 if you understand what a constrained network device looks like)

There may be other encodings that people want to do.  One I've heard mentioned is protobufs (https://developers.google.com/protocol-buffers/docs/overview).  I don't yet believe there are enough of those other encodings for us to do a bunch of work generalizing JSON in an encoding-agnostic way.  Each encoding will also need specific handling for what bytes will be protected.  As such, my suggestion would be for us to gather a set of lessons learned in the process of doing the CBOR encoding that might act as signposts if anyone wants another encoding later.

Please discuss.

--
Joe Hildebrand

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

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Feb 2015 17:39:45 -0300

I agree that it should be done and that JOSE is probably the best place for it.

John B.
> On Feb 4, 2015, at 5:30 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 4 Feb 2015 16:05:53 -0500

The one thing we should be abundantly clear on is the relationship between
"COSE" and "JOSE".  In particular, that what we're talking about is *not*
simply a re-encoding -- a JOSE signed object (JWS) and a COSE signed object
will have different signature values.

So the main value will be in re-using identifiers (e.g., header field
names) and the overall structure (header, protected, etc.).

Agreed?

On Wed, Feb 4, 2015 at 3:30 PM, Mike Jones <[email-masked]>
wrote:

> Thanks, Joe.  I think this could be pretty straightforward.  As I
> understand it, it would replace uses of JSON and base64url encoding with
> CBOR, but otherwise reuse as much of JOSE with as few changes as possible,
> such as reusing the algorithms, header parameters, etc.  A few
> CBOR-specific features would be needed, such as defining the particular
> CBOR concatenation used to represent the JWS Signing Input (instead of
> "ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS
> Payload))", which is JSON-specific).
>
> I agree that any work on this should be CBOR-specific, due to the need for
> a few CBOR-specific rules such as the one above, while also trying to
> capture what it would take to do other encodings (essentially, the
> necessary differences from JSON-specific and CBOR-specific rules), and
> probably capture that in a non-normative appendix.  A fully generic
> treatment wouldn't answer necessary questions to achieve interop.
>
> I personally think this work should happen, because of interest from IoT
> folks, and that it should happen in JOSE, because we already have most of
> the right experts assembled into a working group.  It won't be hard for
> interested JOSE members to learn the necessary details about CBOR, and I'm
> sure Carsten will guide us in that regard.
>
>                                 -- Mike
>
> available in CBOR (RFC 7049).  I wanted to start a conversation on the JOSE
> list to see if there was any interest in doing the work here (after a
> mentioned is protobufs (
> https://developers.google.com/protocol-buffers/docs/overview).  I don't

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Feb 2015 18:14:23 -0300

Right,  I can’t think of any way that the same signature value could work across both encodings, without doing something twisted.

John B.

> On Feb 4, 2015, at 6:05 PM, Richard Barnes <[email-masked]> wrote:
> 
> The one thing we should be abundantly clear on is the relationship between "COSE" and "JOSE".  In particular, that what we're talking about is *not* simply a re-encoding -- a JOSE signed object (JWS) and a COSE signed object will have different signature values.
> 
> So the main value will be in re-using identifiers (e.g., header field names) and the overall structure (header, protected, etc.).
> 
> Agreed?
> 
> On Wed, Feb 4, 2015 at 3:30 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> From: jose [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Joe Hildebrand (jhildebr)
> To: [email-masked] <mailto:[email-masked]>
> http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf <http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf>
> 
> There may be other encodings that people want to do.  One I've heard mentioned is protobufs (https://developers.google.com/protocol-buffers/docs/overview <https://developers.google.com/protocol-buffers/docs/overview>).  I don't yet believe there are enough of those other encodings for us to do a bunch of work generalizing JSON in an encoding-agnostic way.  Each encoding will also need specific handling for what bytes will be protected.  As such, my suggestion would be for us to gather a set of lessons learned in the process of doing the CBOR encoding that might act as signposts if anyone wants another encoding later.
> 
> Please discuss.
> 
> --
> Joe Hildebrand
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 4 Feb 2015 21:14:32 +0000

On 2/4/15, 2:05 PM, "Richard Barnes" <[email-masked]> wrote:

>The one thing we should be abundantly clear on is the relationship 
>between "COSE" and "JOSE".  In particular, that what we're talking about 
>is *not* simply a re-encoding -- a JOSE signed object (JWS) and a COSE 
>signed object will have different
> signature values.

Agree.  I wasn't quite explicit enough when I said "It would not require 
JOSE/JSON compatibility", but my intent was exactly as you state: the 
signatures will be different.

>names) and the overall structure (header, protected, etc.).

Yes, the bulk of the semantic that was hammered out as a part of the JOSE 
work to date.

>Agreed?

Yes.

>On Wed, Feb 4, 2015 at 3:30 PM, Mike Jones 
><[email-masked]> wrote:
>
>CBOR, but otherwise reuse as much of JOSE with as few changes as 
>possible, such as reusing the algorithms, header parameters,
> etc.  A few CBOR-specific features would be needed, such as defining the 
>particular CBOR concatenation used to represent the JWS Signing Input 
>(instead of "ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || 
>BASE64URL(JWS Payload))", which is JSON-specific).
>
>I agree that any work on this should be CBOR-specific, due to the need 
>for a few CBOR-specific rules such as the one above, while also trying to 
>necessary differences from JSON-specific and
> CBOR-specific rules), and probably capture that in a non-normative 
>appendix.  A fully generic treatment wouldn't answer necessary questions 
>to achieve interop.
>
>interested JOSE members to learn the necessary
> details about CBOR, and I'm sure Carsten will guide us in that regard.
>
>                                -- Mike
>
>There have been some hallway conversations about making the JOSE 
>semantics available in CBOR (RFC 7049).  I wanted to start a conversation 
>on the JOSE list to see if there was any interest in doing the work here 
>(after a recharter), in another working group,
> or through some other mechanism.
>
>would do away with the Base64url requirements from the JSON form 
>(reducing size and complexity), since arrays of bytes are first-class 
>entities in CBOR.  It would not require JOSE/JSON
> compatibility.
>
>yet
> believe there are enough of those other encodings for us to do a bunch 
>of work generalizing JSON in an encoding-agnostic way.  Each encoding 
>will also need specific handling for what bytes will be protected.  As 
>such, my suggestion would be for us to gather
> a set of lessons learned in the process of doing the CBOR encoding that 
>might act as signposts if anyone wants another encoding later.
>
>Please discuss.
>
>--
>Joe Hildebrand
>
>
>

-- 
Joe Hildebrand

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 04 Feb 2015 23:12:29 +0100

On 2015-02-04 21:30, Mike Jones wrote:
> understand it, it would replace uses of JSON and base64url encoding
> with CBOR, but otherwise reuse as much of JOSE with as few changes as
> possible, such as reusing the algorithms, header parameters, etc.  

That is one view (also the one that underlies
draft-bormann-jose-cose-00.txt).

Another view is that we could use the obvious incompatibility to "fix" a
few shortcomings of JOSE that have been caused by its need to stay
compatible with JWT and the likes.
I think the benefit of this needs to be carefully weighed against the
potential for confusion and the added committee time (which also
translates into real time) until these fixes converge.
(I'm personally not yet decided.)

> A
> few CBOR-specific features would be needed, such as defining the

Yes.  draft-bormann-jose-cose-00.txt says:

      *  where the output of the base64url function was to be joined by
         ASCII dots (".") with other such outputs, CBOR encoding of an
         array built from the inputs, each represented as a byte string,
         is used.

which seems like the natural way to do this.

Gruesse, Carsten

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 5 Feb 2015 14:58:25 +0000

>(I'm personally not yet decided.)

I'm not decided yet, either.  It may be that some changes might be a good 
thing; I would suggest waiting until we have a defined wish list before 
making a final decision.

-- 
Joe Hildebrand

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 06 Feb 2015 11:11:12 +0100

On 02/04/2015 10:05 PM, Richard Barnes wrote:
> signed object will have different signature values.
>

Yes, but ...

(Sorry for the long mail ahead, TL;DR: Do this and more!)

I've done a few quick calculations on that topic.

A simple JWS (alg='HS256', kid=<16 chars>, not including any of the 
payload, just the signature and the header) would have a size of 100 bytes.

Simple translation of that to CBOR (as suggested in Carstens 
presentation at IETF90) shrinks this down to 67 bytes.

In the constrained devices use cases, the data we would want to protect 
with JW* would typically be sensor readings and actuator commands. These 
would have a size of just a few bytes (say a 4 byte float for example). 
Adding 67 bytes overhead to that still seems pretty steep.

Therefore I would suggest to also consider what Carsten mentioned on 
slide 35 (last bullet) of this:
http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf

It basically boils down to define abbreviations for common member names 
and pre-defined values (such as 'alg', 'enc', 'kid', 'HS256').

Furthermore I suggest to define new algorithm identifiers for e.g. 
truncated MACs, and for AES_128_CCM_8 (AFAIK CCM mode is more efficient 
to implement in constrained devices than GCM).

Hope this helps,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 14 Feb 2015 20:22:11 +0900

We probably need to give careful consideration to it, but my gut feeling is that such short cut can be useful especially in power restricted devices. 

Nat Sakimura 

2015/02/06 19:11、Ludwig Seitz <[email-masked]> のメッセージ:

> A simple JWS (alg='HS256', kid=<16 chars>, not including any of the payload, just the signature and the header) would have a size of 100 bytes.
> 
> Simple translation of that to CBOR (as suggested in Carstens presentation at IETF90) shrinks this down to 67 bytes.
> 
> In the constrained devices use cases, the data we would want to protect with JW* would typically be sensor readings and actuator commands. These would have a size of just a few bytes (say a 4 byte float for example). Adding 67 bytes overhead to that still seems pretty steep.
> 
> Therefore I would suggest to also consider what Carsten mentioned on slide 35 (last bullet) of this:
> It basically boils down to define abbreviations for common member names and pre-defined values (such as 'alg', 'enc', 'kid', 'HS256').
> 
> Furthermore I suggest to define new algorithm identifiers for e.g. truncated MACs, and for AES_128_CCM_8 (AFAIK CCM mode is more efficient to implement in constrained devices than GCM).
> 
> Hope this helps,
> 
> Ludwig
> 
> 
> -- 
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70-349 92 51
> http://www.sics.se
>