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 protected]] On Behalf Of Joe Hildebrand (jhildebr)
Sent: Wednesday, February 04, 2015 12:10 PM
To: [email protected]
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)
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
