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:
https://www.ietf.org/archive/id/draft-hallambaker-jsonbcd-02.txt
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 32
JSON-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(_at_)ietf(_dot_)org>
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(_dot_)Moriarty(_dot_)ietf(_at_)gmail(_dot_)com>
Mailing list
Address: cose(_at_)ietf(_dot_)org
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