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 protected]> 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 > > -----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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
