Re: [Cbor] Unusual map labels, dCBOR and interop

[Carsten Bormann <[e-mail]>]

Hi Orie,

an application profile specifies some aspects that are common for each member of a set of application protocols.
(By that definition, each application protocol also is an application profile, so much of the reasoning for application profiles needs to apply directly to application protocols.  Clearly, to be useful, an application profile should be applicable to a set of application protocols with much more than one member.)

draft-mcnally-deterministic-cbor-07 does not define a media type for dCBOR [1].
It could, but it would not be very useful, as you’d really want to know the specific application protocol (such as application/envelope+cbor in [2]).
If we would, we would undoubtedly call it application/dcbor+cbor, as dCBOR instances are CBOR instances.
A Structured Syntax Suffix [3] could be defined for dCBOR itself, but then we’d run into the question whether that should be stacked on top of +cbor and all that unwieldiness (application/envelope+dcbor+cbor?) (***).

[1]: https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-07.html#name-iana-considerations
[2]: https://www.ietf.org/archive/id/draft-mcnally-envelope-06.html
[3]: https://www.rfc-editor.org/rfc/rfc6839.html

> If undefined were encountered when deserializing dcbor to JavaScript, an error should be thrown?

(Or to any implementation platform.) Yes.
(Asking the same question for a CBOR generic decoder, the answer is always “no”, independent of application protocol or profile.  Of course, a CBOR decoder can be implemented with limitations that fit well with the application protocol(s) to be used, so CBOR decoders can be written that reject “undefined” or any other simple value (or 4711, if you like) right during the deserialization.)

> SCITT Receipts and CWTs are built on the assumption that no error would be thrown.

SCITT Receipts and CWTs are application protocols that have not been designed with the application profile dCBOR in mind.  (E.g., in CWT, »undefined« can occur once a Claim is defined that can have that inside its member value.  But then dCBOR already would reject receiving 1711604736.0 in an iat/exp/nbf.)

> I must have not understood the comment made regarding map labels, because I thought you were saying that dcbor serializes maps differently from vanilla CDE... If it doesn't, why the need for any new serialization?

(I think Wolf covered this.
Random information: My PoC implementation derives the dCBOR-serialized map keys for use as the sorting key in sorting the map members immediately before their serialization — which it would need to do anyway to actually encode them, but the actual serialization is then done separately inside a plain generic encoder(*).  The assumption here is that the map keys are small and structurally simple enough that the runtime hit is not a big problem.)

> I don't think dcbor can be called application/cbor any more than json without booleans can be called application/json.

[1, 2, 3] is an instance of application/json.  There is no boolean in there.  Likewise, the use of application/cbor does not require that any CBOR instance is a valid instance of the application protocol.

> Processors not expecting Booleans in JSON would explode, and processors of dcbor expecting it to be meaningfully different than application/cbor will also explode right?

Not sure I can parse this.

> Feeding unexpected content to a parser is the normal expectation for security formats.

Absolutely, and a checking dCBOR decoder is a good tool to factorize out detection of certain format violations to a common, reusable, well-tested library.
(**)

> We've seen real problems arise from JSON-LD, being valid json, but not quite valid "JSON-LD"... It can lead to ambiguous processing, where some middle boxes throw errors and others don't.

JSON-LD is RDF serialized in JSON.
RDF provides an application data model that is completely different from that of JSON.
JSON-LD documents "look like" JSON, and hand-made examples you can find in documents are typically made up in such a way that this illusion is fed well.
But interpreting JSON-LD documents as PoJ (plain old JSON) is, in general, a mistake.

The dCBOR application data model is a proper subset of the CBOR generic application data model, with identical semantics; no special processing is required after CBOR-decoding to do further interpretation by the application.
(Insert lengthy discussion whether numeric reduction leads to different semantics — mathematically, it does not, and dCBOR lends itself to application protocols that do not make that distinction either.)

> Distinguishing dbcor from cbor seems a prerequisite to making any progress on its application in a security context.

Not sure if I’m getting what you are trying to say, but you can’t distinguish a specific dCBOR instance from a CBOR instance, because any dCBOR instance is both.

Grüße, Carsten

(***) Of course, we have +der and +ber, but I don’t think we want to emulate that here.

(*) which, for my implementation platform, luckily happens to be able to preserve the order of map elements that has been set by the sorting; as a prerequisite, map ordering by insertion order is implemented in the implementation platform.

(**) My 65-LOC PoC dCBOR implementation doesn’t even come with a decoder, so the user of that library has to do the checking of incoming dCBOR.
This checking can be implemented trivially by dCBOR-encoding the result of the decode with a strict encoder and ensuring the bytes of the encoded representation are the same as the original encoded input.  (Insert runtime argument here.)  I probably should add those 5 LOC for a dCBOR decode function to the code, once I’ve made the encoder strict…