Subject: Re: WG Review: CBOR Object Signing and Encryption (cose)

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 May 2015 14:52:06 -0400

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 <[email-masked]> 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 <[email-masked]>
>
> Mailing list
>   Address: [email-masked]
>   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
>
>
>

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 May 2015 15:01:39 -0400

I'd like toh second Phil's concerns here.

A proliferation of security standards, even when there are levels of
interoperability between them, is problematic for interoperability.
The folks proposing JOSE were required to make a very strong
justification about why we needed something JSON based  in addition to
our  existing security standards.
I believe they did that.

However, I don't think the constrained devices area has made a
justification explaining why

1) They need something different

2) They don't need interoperability with the rest of the world.

Even if constrained devices could benefit from a different encoding, if
they need interoperability, we still run into problems.  In the
discussions leading to DICE ACE, and COAP, arguments were made that there
would be proxies between the rest of the world and the constrained
network, so it was acceptable that we used different protocols.Th
These arguments basically don't apply to object signing and encryption.

Based on the charter, this working group sounds like a really bad idea,
flying in the face of interoperability and the IETF's mission.
I do not support chartering this work.

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 May 2015 16:04:16 -0500

On Fri, May 22, 2015 at 02:52:06PM -0400, Phillip Hallam-Baker wrote:
> literals and the lack of a binary blob type. Rather than develop a [...]

Also inefficiency as to numbers.  In a binary protocol ideally numbers
could be sent in whatever format is easiest for the sender (e.g.,
little-endian IEEE754 doubles).

All I wanted was: chunking for strings, which effectively takes care of
the need for a binary type, and binary numbers.  CBOR added a datetime
type, optional tagging of items, and who knows what else.

> IESG should reject this WG proposal and all future proposals of this type.

+1 to this and Sam's take.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 May 2015 18:54:42 -0500

I should clarify that my objection is to a working group IF a JOSE->CBOR
mapping is trivial enough, and if it's not trivial due to CBOR having a
different data model from JOSE, well, then there's Phillip's I-told-you-
so.

Also, COSE is predicated on constrained devices ("class 1"), and some
thought convinces me that it is true that [at least a profile of] CBOR
is easier to implement than JSON, but mostly that's a function of a)
being able to use base-2 number representations on the wire, and b) not
having to escape/unescape strings.  Decimal<->IEEE754 conversions are
easily the trickiest part of any decent JSON parser/encoder, so I'm
quire prepared to believe that CBOR is easier to implement on class 1
constrained devices.

Now, looking again at the WG proposal, there are deliverables that go
beyond merely mapping JOSE onto CBOR, so perhaps there is enough work
for a WG.  Therefore I retract my opposition.

Nico
--

---

From: Andrew Newton <[email-masked]>
Date: Tue, 26 May 2015 14:31:36 -0400

First, I appreciate the effort that went into this charter text. It is
clear, understandable, and properly focused.

That being said...

On Fri, May 22, 2015 at 2:52 PM, Phillip Hallam-Baker <[email-masked]>
wrote:
> consider other design approaches.

There was an appeal regarding the publication of CBOR for which the outcome
was: 1) IETF process was not followed, and 2) but the RFC is already
published and some bells cannot be unrung. Fair enough, however basing
further IETF work on it may not be wrong but does not seem right either.
Phillip, having been active in the JSON wg and a known security-area
participant, has a broader point that different design decisions may have
been made had we known things would go this far.

I also noticed that the active draft for this effort has a normative
dependency on CDDL. Working groups such as TZDIST were told they could not
normatively depend on JCR. Again, fair enough. But what is to happen here?
Given the parallels drawn between CBOR and JSON, it would be unfortunate
for the IETF to bless one "JSON schema language" without a wider
discussion. I am not saying they shouldn't use CDDL, but it would be best
if the relationship between it and JSON were more clearly understood.

-andy

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 May 2015 21:50:25 +0200

Andrew Newton wrote:
> Fair enough, however basing further IETF work on it may not be wrong but
> does not seem right either. 

CBOR is getting a lot of traction in the constrained node networking
space (the low-resource part of the "Internet of Things"), which is not
surprising as it was designed for hat.
Not basing further IETF work on CBOR would ensure the IETF loses impact
there, and would accomplish what?

> dependency on CDDL.

How best to write up the spec is indeed an interesting issue.

For now, CDDL is a good way to discuss the draft, much better than
lobbing around large quantities of ambiguous English prose.
But then, CDDL is still being tweaked, and it is not clear that the IETF
wants to give this language a role similar to the one ABNF has for text,
or (even if that is at some point accepted as a reasonable thing to do)
would want to reach a decision on something like this before COSE is done.

So, once the remaining decisions have been taken, the CDDL snippets will
probably move to an appendix, and will be replaced in their normative
role by gobs of ambiguous English prose.  With any luck, we may be able
to generate that automatically from the CDDL (just as we are already
checking the examples automatically against the CDDL).

(Kudos, by the way, for the concepts the CDDL authors could steal from
JCR; what a great source of inspiration.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 May 2015 12:56:02 +0200

On 23 May 2015 at 04:16:00, Nico Williams ([email-masked]) wrote:
I should clarify that my objection is to a working group IF a JOSE->CBOR 
mapping is trivial enough, 
The CBOR data model is a superset of the JSON data model, so a trivial translation of JOSE to CBOR is indeed trivial.

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].  So the main work of the WG will simply be about how exactly to use those capabilities.  (It all looks trivial on a napkin, but a few bikesheds still have to be painted.)  Any other hypothetical approach that adds binary capabilities to the JSON data model will need to do this kind of work, bold statements to the contrary notwithstanding.

The lack of a need for backward compatibility with dusty JavaScript decks also means that a few unsavory details of JOSE can be cleaned up in the process (e.g., JOSE muddles up MACs and signatures, which is easily fixed).  The WG clearly is mandated to be rather conservative in those cleanups.

Thank you.

Grüße, Carsten

[1]: http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf

---

From: Andrew Newton <[email-masked]>
Date: Wed, 27 May 2015 10:38:02 -0400

> there, and would accomplish what?
To head off one of those threads where arguments are rehashed repeatedly, I
think I'm gonna let the arguments given by Phillip and Sam stand on their
own now that I've stated my concern.

> lobbing around large quantities of ambiguous English prose.

You and I agree here. I favor whatever it takes to make CDDL a viable
normative reference, so long as it doesn't preclude other efforts.

-andy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 May 2015 15:53:55 -0400

On Wed, May 27, 2015 at 6:56 AM, Carsten Bormann <[email-masked]> 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.

> 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.

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

So the main work of the WG will simply be about how exactly to use those
> capabilities.  (It all looks trivial on a napkin, but a few bikesheds still
> have to be painted.)  Any other hypothetical approach that adds binary
> capabilities to the JSON data model will need to do this kind of work, bold
> statements to the contrary notwithstanding.
>
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.

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.

---

From: "Joe Hildebrand" <[email-masked]>
Date: Wed, 27 May 2015 14:24:48 -0600

> 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.

> 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.

> 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.

> compiled, but that is at worst a registration effort.

Really not that different from CBOR.

> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 May 2015 16:30:32 -0400

> normative reference, so long as it doesn't preclude other efforts.

At this point I have schema driven tools for the following encodings:

* RFC822 style headers (works for RFC documented HTTP, SMTP headers)
* RFC821 style command
* JSON
* ASN.1
* TLS
* DNS
* XMLSchema[*]
* Goedel meta-synthesizer

None of these use a syntax that looks remotely like the encodings they
target, nor do I find the slightest use for the ASN.1 or XML schema
languages. I developed my first encoder after getting fed up of having to
edit XML Schema by hand for the SAML 1.0 spec.

Right now only a few of the tools share the same input language but they
all look pretty similar except for the DNS parser. JSON is obviously better
for highly nested structures than RFC822 but it isn't difficult to subset.

In recent years there has been a trend towards using YANG at the lower
levels in the stack and I think that is a good approach at the transport
layer down. But the features that make YANG useful at that layer make it
less appropriate for the application layer and above where the objective is
to make the mapping between the protocol data structures and the
implementation data languages as simple and straightforward as possibles.

Right now most JSON Web Services are layered on top of HTTP which means
that we have the following encodings involved:

RFC821 [Method line]
RFC822 [Headers]
MIME-ish [Chunked Encoding]
JSON [Payload]

And that is going to be where a large fraction of Web Services are going to
be for the next couple of decades. But the fact is that we can convert the
entire stack into JSON without any change to the semantics. And if we use
JSON-B or JSON-C we get improved efficiency as well.

One of the odd features of Web Services is that even though we have to do
all that implementation work above, almost none of it provides any payoff
from an architectural point of view. Yes 'in theory' it is possible to
route HTTP messages as if they are multiparty transactions and this is what
SOAP tried to support. But the cost of making that work was to insert a
whole new framing layer for SOAP which made the HTTP layer redundant.

If we get the DNS client-resolver link fixed so it is practical to make
multiple requests in one round trip request, it is a simple matter to
define a DNS record that says 'this Web Service available over the HTTP
binding and the J-Binding using encoding X'

Note however that people who write and deploy Web services are not going to
support two syntaxes for the same protocol and thus make a transition
strategy possible unless providing support for the two stacks is completely
transparent and automatic.

What I am getting to here is that if we want to have a cleaner, simpler
Internet some time in the future, we should be looking at approaches that
allow us to remove the unnecessary variations in encoding at some point. We
really should be looking at ways to reduce the number of encodings, not
varying them to no benefit.

---

From: Nico Williams <[email-masked]>
Date: Wed, 27 May 2015 16:03:16 -0500

On Wed, May 27, 2015 at 02:24:48PM -0600, Joe Hildebrand wrote:
> 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.

I agree that a binary JSON parser/encoder would not share much code with
a plain JSON parser/encoder, but just to be clear, having the same data
model is a win because many tools (e.g., JSON query/pointer-type tools,
such as jq) would remain usable with binary JSON.

For example, for jq to speak a binary JSON wouldn't be too hard, but for
jq to speak CBOR would require mapping CBOR non-JSON data types onto
JSON data types -- such mappings must be lossy.  Alternatively jq would
need to be extended to support CBOR data types, which would require
significantly more work.  (If and when we add CBOR support we'll have to
deal with this; we might never get there.)

The jq programming language is so useful to me when dealing with JSON
that I suspect it will be useful when dealing with JSON variants, but
the less they stray from the JSON data model, the easier it will be to
add support for them.  I suspect this is true for many other JSON tools.

Nico
--

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 May 2015 17:15:22 -0400

Hi Sam,

> These arguments basically don't apply to object signing and encryption.

In Dallas as well as on the COSE list, the WG has built a case for the work
specific to constrained devices first for me and then again for Stephen.
Here is the link to the discussion with Stephen.  Please let me know if
this addresses your concerns:

You can probably get most of what you are looking to see in Stephen's
DISCUSS up to this point in the thread (plus previous messages).
Subsequent messages hit on crypto and wording for the charter to not create
anything new in this WG.

http://www.ietf.org/mail-archive/web/cose/current/msg00146.html

Sorry for my delay in response.  I spoke at LACNIC last week and it took a
hit on my schedule.  It's an important group to support, so it's worth it.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 May 2015 23:54:20 +0100

> On 27 May 2015, at 21:30, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> If we get the DNS client-resolver link fixed so it is practical to make multiple requests in one round trip request, 

It is already possible to send multiple DNS requests in one round trip. I know you want to be able to ask multiple questions in one request, but it is practically impossible to upgrade everything to support that, and there is no need since concurrent requests work.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 May 2015 19:34:55 -0400

On Wed, May 27, 2015 at 4:24 PM, Joe Hildebrand <[email-masked]> wrote:

> "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)
>

These are not a problem in protocols since we almost never use floating
point numbers. We do use decimals but those are rare as well.

> 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.
>

The aim would be to leave these to deployment.

> similarity.

Yes, there is a lot of similarity and had certain individuals been willing
to consider external input we could have come up with one specification
very easily.

The key difference is that JSON-C is doing string segment compression and a
single dictionary can be used for any code point. There is no context
sensitivity. That greatly reduces the complexity of writing
encoder/decoders at a modest cost in space efficiency.

> 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.
>

The reason I let that draft expire is I have been working on this one that
eliminates the need for the ASN.1 there:

https://tools.ietf.org/html/draft-hallambaker-udf-00

Basically it is a spec that generalizes OpenPGP fingerprints to allow other
content to be digested in the same fashion without ambiguity.

> 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).
>

Thanks.

> 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.

Since the specs are supersets a JSON-D decoder will decode JSON, JSON-B or
JSON-C. A JSON-C decoder, JSON-B and JSON and so on.

The advantage comes when you have nested structures. Say you have a JSON
document and you want to include in another structure. You can copy across
the bytes verbatim without worrying if they are JSON or JSON-B.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 28 May 2015 01:02:06 +0000

Could the working group be chartered with a requirement to align “Object Signing and Encryption” so that it uniformly applies to CBOR and JSON?

I think the case has been made that the data model differences between JSON and CBOR are legitimate and I don’t think the IETF should pick one over the other as a policy, let the sides fight it out in the market, not in the decision whether to charter a working group.

But getting each side to recognize the legitimacy of the other and making OSE more independent of the details of the data model would be really helpful.
Why not XML and http://www.w3.org/XML/EXI/ too?

Larry
—
http://larry.masinter.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 May 2015 21:08:16 -0400

On Wed, May 27, 2015 at 9:02 PM, Larry Masinter <[email-masked]> wrote:

> Could the working group be chartered with a requirement to align “Object
> Signing and Encryption” so that it uniformly applies to CBOR and JSON?
>
> I think the case has been made that the data model differences between
> JSON and CBOR are legitimate and I don’t think the IETF should pick one
> over the other as a policy, let the sides fight it out in the market, not
> in the decision whether to charter a working group.
>
> But getting each side to recognize the legitimacy of the other and making
> OSE more independent of the details of the data model would be really
> helpful.
Because XML is a document format which makes it a bad choice for a data
format.

The order of elements means absolutely nothing in an object.
<a><b/><c/></a> conveys exactly the same information as <a><c/><b/></a>. If
the order of a sequence of objects matters, then a sequence should be used.

SGML/XML offer a lot of flexibility in expression because this does matter
in documents. Documents are edited by hand and so schema validation is
useful.

Moving data in a Web Service is essentially just an API call or a return
[occasionally a callback]. More flexibility is neither necessary or
desirable.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 28 May 2015 01:52:19 +0000

I think you missed the point: is it possible not to have to respec signing and encryption
for every variant of data model and serialization?

>  XML is a document format which makes it a bad choice for a data format.
There are a wide variety of contexts and considerations.

How would you update BCP70 on use of XML? Section 3 covers many of the points.

---

From: "Joe Hildebrand" <[email-masked]>
Date: Wed, 27 May 2015 20:14:52 -0600

> How would you update BCP70 on use of XML? Section 3 covers many of the 

Reduce it to one sentence:

"Do not use XML for new wire protocols, please."

-- 
Joe Hildebrand

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 May 2015 09:39:27 -0700

> "Do not use XML for new wire protocols, please."

Yes.  Lesson learned.