ietf
[Top] [All Lists]

Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose)

2015-05-27 15:25:27
On 27 May 2015, at 13:53, Phillip Hallam-Baker wrote:

The CBOR data model is a superset of the JSON data model, so a trivial
translation of JOSE to CBOR is indeed trivial.

It is a rather complex superset.

It takes less code to parse than JSON, however, which is ironic. For those that haven't thought about the problem, consider this bit of valid JSON:

{ "one": 1e400, "on\u0065": "\udead" }

1e400 is bigger than most implementations can deal with. Are "one" and "on\u0065" the same thing? (yes) If so, what do you do about the duplicate key? (implementation-defined, non-interoperable) What do you do about the half surrogate pair \udead, since JSON is defined as an odd subset of UTF-16 that allows invalid 16-bit code units? (usually: generate an invalid codepoint and hope for the best)

The added complexity of CBOR yields interesting properties, such as removing some of the ambiguities and edge cases of JSON that hinder interoperability. That said, most of the things that are in the superset (other than binary blobs, unambiguous UTF-8 strings, and interoperable integers) are unlikely to be used in a COSE spec. Some CBOR implementations already have flags to turn off some of those features, such as unambiguous IEEE754 floating point numbers in order to reduce code size.

Doing such a trivial mapping would be completely misguided, though, as
CBOR has additional capabilities, and the efficiencies we need in the
constrained node network environment are indeed made possible by those
additional capabilities [1].

I note that you still haven't answered my challenge on data encoding
efficiency. My JSON-C encoding shows what can be achieved using the JSON data model with only the addition of a binary blob data type. I posted the
encoding for the JOSE signing example shortly after Dallas.

I've just gone back and looked at draft-hallambaker-jsonbcd-02 again. I agree with you that JSON-[BCD] do a better job at segregating functionality that might be needed by different applications than CBOR does, at the expense of some implementation complexity and complexity on the part of the protocol designer picking which level to use.

I disagree that there is a difference in the degree to which JSON-C differs from JSON than CBOR does. If you compare Table 1 and Table 2 of your doc to Section 2.1 of RFC 7049, for example, there's a lot of similarity. The ASN.1 OID references in your Section 5 would need to be both motivated better and better described before they would be interoperably implemented.

If you wanted to do the work to turn this doc into one or more specifications that were ready to publish as RFCs, with more complete explanations and examples, then wanted to define a JOSE mapping into that set of specifications, I would fight for your right to do so (although probably wouldn't provide much technical help beyond reviewing for completeness).

However, I don't see any likely possibility that we could talk existing JSON implementations (such as those in browsers) into implementing these formats natively, so we're looking at completely new code for both parsing and generation. At that point, retaining any kind of compatibility with JSON doesn't provide a win, and retains all of JSONs interoperability issues.

What your constrained node example needs is a better encoding for JSON, not
the introduction of yet another encoding for a random data model.

The goal is a substantially similar data model. Potentially even identical, depending upon which warts of JOSE the working group would have consensus to fix.

My encoding is generated entirely mechanically. Switching from a text
encoding to binary means simply choosing a different encoding method. Using compressed tags is slightly more complicated in that a dictionary has to be
compiled, but that is at worst a registration effort.

Really not that different from CBOR.

I repeat that no Working Group effort is required or desired for applying
the encoding to JOSE, ACME or any current or future JSON spec.

Some relatively-large amount of work would be necessary to get your JSON-[BCD] spec ready for publication as one or more RFCs. If you have a group of people who have the energy for that work, then I think you should do so. If you then have a group of people who have the energy to do a spec (however minimal in size) for a JOSE encoding, you should do that, too. I would suggest that you get some buy-in from folks that are in the community you want to implement those specs before you start.

In the meantime, your potential desire to do other work shouldn't keep the COSE work from starting, in my opinion.

--
Joe Hildebrand