As I stated in the JOSE working group, this is a very bad idea and should not go forward.
When CBOR was proposed, the group working on it asserted that it was a private initiative, outside IETF process and they had no obligation to consider other design approaches. As a result they chose to design a new binary encoding that is not based on the JSON model, offers no advantages over the JSON model and requires protocols making use of the encoding to be hand tweaked on a case by case basis.
If the CBOR group had been willing to accept input from outside their closed circle, this could have been avoided.
The core problem with CBOR is that it appears that the network protocol specification community has made a consensus decision to base all future work on the JSON encoding specification. A binary encoding obviously cannot be compatible with JSON but it can be compatible with the JSON data model. CBOR throws away the JSON data model and replaces it with its own idiosyncratic approach.
The 'need' for this new working group is purely the result of that decision. While it is 'possible' to encode JSON in CBOR and vice versa, the same is true of JSON and XML, XML and ASN.1 and JSON and ASN.1. Nobody disputes that it is possible to use CBOR as a binary encoding for JSON. The problem is that the introduction of a new and incompatible data model means that such a mapping has to be written by hand.
It did not need to be this way. Many of us who commented on CBOR said that we do not want any encoding that changes the JSON data model. In fact the only limitations we find in JSON are the need to perform escaping on string literals and the lack of a binary blob type. Rather than develop a completely new encoding we would much prefer to simply add these two missing features to JSON. While the result is no longer a pure text encoding, it is close enough that we can add support by simply adding a few extra tags to the existing JSON encoding.
One of the problems of dealing with a situation like this is that the first response is 'make your own proposal' and if you do that the response is to accuse detractors of clinging to their own scheme. For the record, the only reason I wrote my counter-proposal was to demonstrate that it is possible to develop a binary encoding of JSON that is efficient and does not require any further work to apply it to JOSE or any other JSON based protocol.
This binary encoding is described in:
Since this encoding does not change the JSON data model, no additional specification is required to describe the application to JOSE. Applying the encoding to the example in the JOSE specification produces the following results:
In JSON: 244 bytes
Protected 35 / Payload 70 / Signature 32
In JSON-B: 165 bytes
Protected 24 / Payload 70 / Signature 32
In JSON-C: 129 bytes
Protected 13 / Payload 70 / Signature 32JSON-B is JSON with minimal extensions to support binary encoding, JSON-C adds a compression capability. While a compression capability may or may not be desirable, it is useful to have data to make such a decision.
The issue here is not just JOSE. If this precedent is accepted we can expect a demand for similar groups to repeat all the work that is being done in JSON in CBOR. So after we complete ACME we will have a proposal to start a CACME working group. And on and on and on.
Choice of binary versus text encoding should be no more than a switch like choosing UTF8 encoding versus UTF16. If changing the position of the switch has knock on effects in the rest of the specification there is something seriously wrong with the design.
Choice of encoding is not an 'editor war' issue because it is a choice that affects everyone in the user community. I want to see as much commonality across the design space as possible. JSON is not the perfect encoding but it does eliminate the primary objections to the use of XML and ASN.1, namely the fact that they impose a highly convoluted and complex set of rules for converting between data structures and the encoding. The fact that JSON can encode the same data with equivalent or better efficiency to XML shows that the rules are not necessary. JSON-B achieves similar efficiency to ASN.1
The only reason this group is necessary is that CBOR is not suited to IETF needs. Rather than starting a working group to rewrite IETF standards so they are suited to work in CBOR we should start a working group to make something that does the job of CBOR that is suited to use by the IETF.
IESG should reject this WG proposal and all future proposals of this type.
On Fri, May 15, 2015 at 1:25 PM, The IESG <iesg-secretary@xxxxxxxx> wrote:
A new IETF working group has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2015-05-25.
CBOR Object Signing and Encryption (cose)
------------------------------------------------
Current Status: Proposed WG
Assigned Area Director:
Kathleen Moriarty <Kathleen.Moriarty.ietf@xxxxxxxxx>
Mailing list
Address: cose@xxxxxxxx
To Subscribe: https://www.ietf.org/mailman/listinfo/cose
Archive: http://www.ietf.org/mail-archive/web/cose/
Charter:
Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary
format for the serialization of data structured to an extended version of
the JSON data model. COSE seeks to create CBOR-based object signing and
encryption formats. One motivation for COSE was to reuse functionality
from the JOSE working group using the CBOR data representation as it is
more amenable to constrained nodes and constrained node networks (RFC
7228).
The JOSE working group recently completed producing representations for
cryptographic keys, message authentication (MACs), encryption, and
digital signatures, using JSON representation.
The resulting formats will not be cryptographically convertible from or
to JOSE formats. This lack of a need for bit-for-bit compatibility will
enable some simplification in the adaptation process.
Criteria that should be considered in the decision making process,
changing from JSON to CBOR encoding include:
o Maintain the current JOSE paradigms and formatting where feasible.
o Minimize message size, code size, and computational complexity to
suit constrained environments, where this is expected to be used.
o Improve security
o Provide new functionality for additional use cases that were not
required for JOSE.
Key management and binding of keys to identities are out of scope for the
working group. The COSE WG will not innovate in terms of cryptography.
The specification of algorithms in COSE is limited to those in RFCs or
active IETF WG documents.
The working group will coordinate its progress with the ACE, DICE and
CORE working groups to ensure that we are fulfilling the needs of these
constituencies to the extent relevant to their work. Other groups may be
added to this list as the set of use cases is expanded.
The WG will have two deliverables:
1. A standards-track specification covering the same cryptographic
formats from JOSE, with optimizations for constrained device processing,
expressed in CBOR;
2. Registration for algorithms (such as AES-CCM-8) that are appropriate
for constrained environments.
The Working Group will use a wiki to track desired use cases for its
work, but does not intend to publish this as an RFC.
Milestones:
Jun 2015 - Submit COSE specification as a WG item
Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item
Jan 2016 - Submit COSE specification to the IESG, for publication as a
Proposed Standard
Jan 2016 - Submit COSE constrained-appropriate algorithms to the IESG,
for publication as a Proposed Standard