Thanks for writing this, Joe. I know that people from the IoT and other communities are already itching for a CBOR JOSE encoding and we'll do everyone a service by providing one in a timely fashion.
I think your proposal to set a high, well-understood and agreed upon bar for any changes to the decisions made in JOSE is the key to having this complete in a reasonable period of time. In my view, if we open most decisions to be re-debated, our timeline is far more likely to look like the JOSE timeline (in which we had the WOES BoF in July 2011 and are only nearing having RFCs now over 3.5 years later) than the quick turnaround achievable by building on past work that I think we would all like. Getting down to specifics, looking at the two COSE submissions to date, https://tools.ietf.org/html/draft-bormann-jose-cose-00 and http://tools.ietf.org/html/draft-schaad-cose-00, I think Carsten's submission is more effective at leveraging our existing decisions than Jim's does so I'd personally want to use that as a starting point, but there are some things I find valuable in Jim's draft as well. For instance, I think that we should consider using arrays rather than maps at the top level, as Jim suggests, as it may keep the code simpler and the representations more compact. I'll note that this is actually parallel to the JOSE Compact Serializations, which used data structures with fixed numbers of elements in fixed positions at the top level, rather than JSON objects, as was done in the JSON Serializations. I'll also add that I personally think we should only define one serialization for the CBOR encoding. I would justify this departure from JOSE as being in the name of "keeping simple things simple" - something I think should also be part of our criteria when making our decisions. (If people do need a URL-safe representation of a COSE object, it would be fine for them to base64url encode the whole thing, for transmission purposes - a suggestion that Joe made to me in person in Honolulu.) Anyway, I'm glad to see this discussion and look forward to us hopefully completing a COSE standard within a year from now! -- Mike -----Original Message----- From: jose [mailto:[email protected]] On Behalf Of Joe Hildebrand (jhildebr) Sent: Friday, March 06, 2015 11:19 AM To: [email protected] Subject: [jose] COSE: what would change? In talking with several folks about COSE, it appears that there are differing views on how much to change in the JOSE/COSE translation. I would like to explore the points of agreement and disagreement a little. It seems like most people agree that maintaining signature compatibility is a non-goal; I agree that is the only way for us to have a chance at success. I think we're also likely to get agreement that we should do our best to use CBOR idioms in COSE (such as mixed-type keys for maps) once they are explained to the group in enough detail for everyone to understand the proposals. Finally, I think one of the reasons people are interested in COSE is a chance to optimize for a different set of use cases than we had for JOSE. The main source of disagreement seems to be what we would change in COSE of the things some might have wanted to done differently in JOSE. I'm sympathetic to both the group that wants to crank something out quickly without re-litigating the past, as well as to the group that wants to re-optimize as many things as possible given the removal of the pressure of existing codebases that we had with JOSE. An approach that might work for this would be to set a bar for changes along the lines of "significant improvement in security, performance (wire size, code size, CPU, power, etc.), or deployability" would be required to justify a change. To see if that approach would work, it would be nice to see a list of things that folks would want to change, and to get early agreement on a couple of those changes as being above the bar that we set, so that we have some precedent to reason from. To that end, I propose that those that want changes produce a list, perhaps annotated with whether the change is seen as imperative or merely nice-to-have. The folks that want a quick outcome would then select several changes they see as being definitely above the line. My hope is that this exercise would build trust that we all want something similar: a high quality protocol standardized in as short a time as possible. -- 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
