On 2/4/15, 2:05 PM, "Richard Barnes" <[email protected]> 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. >So the main value will be in re-using identifiers (e.g., header field >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 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 > > > > > > > > -- Joe Hildebrand _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
