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

Using deterministic encoding to serialize map keys is interesting.

I wonder about security issues with distinguishability.

Consider the case where a map has keys that are serialized with and without
deterministic encoding.

Restricting map keys, reminds me of another flavor of CBOR, I think it was
called dag-cbor, it required all map keys to be tstr... Whereas dCBOR
requires them all to be bstr?

Is it critical to assign unique media types in order for deserialization to
succeed?

I also wonder about interactions with COSE and related protocols especially
regarding unprotected headers.

OS

On Wed, Mar 27, 2024, 8:25 PM Wolf McNally <wolf@wolfmcnally.com> wrote:

> LL,
>
> On Mar 24, 2024, at 12:21 PM, lgl island-resort.com <lgl@island-resort.com>
> wrote:
>
> For dCBOR, I’d like to see map labels very restricted. I’m not a JSON
> user/expert, but it is a Jupiter-sized data point for me. It has massive
> use with only string labels.
>
> I’ll propose integers and strings (major types 0-3) to start discussion.
> Maps and arrays seem too much. Only strings might be OK.
>
>
> I’m not sure whether the issue you’re having is coming from a place of
> design advice, or implementation complexity. From a protocol design
> perspective, in the vast majority of cases I agree that using integers or
> strings for map keys makes the most sense. From an implementation
> perspective, our code simply incrementally manages maps by using the
> serialized CBOR of a key as the “real” key and keeps the map in sorted
> order, even though it hides this fact from the user. This lets us skip the
> sorting step during serialization, and facilitates the validation step
> during deserialization. It also lets us support arbitrary map keys per the
> CBOR spec. Obviously this isn’t the only approach that works to keeping the
> serialized map supported, its keys unique, and also support complex keys.
>
> I can imagine many use cases other than the Gordian Envelope finding dCBOR
> highly desirable because it eliminates all the CBOR stuff that is variable
> and a lot of stuff that is hard to understand. Most people aren’t as smart
> or as into this stuff as we are. Simple map labels line up with this.
>
>
> Again, the goal of dCBOR wasn’t “simple CBOR,” although it has some of
> that flavor, but “deterministic CBOR” as its name suggests, and I’ve kept
> that foremost in the design choices I made in its specification. I can see
> why someone might define an “sCBOR” protocol that further restricts dCBOR,
> but inasmuch as dCBOR meets its original goals, I don’t see the point of
> restricting it further.
>
> ~ Wolf
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>