On Tuesday, 24 October 2017 17:21:54 PDT Nash, George wrote:
> Summary of issues:
> Issue #1: Nesting cbor within cbor
Unfortunately, we're not alone. COSE (RFC 8152) also does that.
I'm not sure why we've done it, but I can tell you COSE's reasoning: the
portion of CBOR stored inside a CBOR Byte String is part of the data that is
either encrypted or included in the hashing or signing. To make sure there's
no transformation of that data between sender and receiver by an ill-advised
but well-intentioned intermediary (a proxy), it's sent as a Byte String.
> Issue #2: Adding to and changing the input *.json file
> Issue #3: Special handling of the "data" value from the "privatedata",
> "publicdata", and "optionaldata".
>
> Is the output from the json2cbor tool supposed to produce 100% valid cbor
> according to RFC-7049?
Not sure.
Here's a wild suggestion: use Sqlite for storing the settings.
> "doxm":
> h'BF646F786D738100666F786D73656C006373637409656F776E6564F56A646576696365757
> 56964782433313331333133312D333133312D333133312D333133312D3331333133313331333
> 133316C6465766F776E657275756964782433323332333233322D333233322D333233322D333
> 233322D3332333233323332333233326A726F776E657275756964782433313331333133312D3
> 33133312D333133312D333133312D333133313331333133313331627274816A6F69632E722E6
> 46F786D626966816F6F69632E69662E626173656C696E65FF',
>
> Here the h is for hex encoded byte string. If the decoder were following
> recommendations of section 4 of the RFC-7049 the output should have
> actually been base64url encoded. Since my tool is an analysis tool I think
> it is ignoring that part of the RFC.
RFC 7049 section 4 describes one way of transforming from CBOR to JSON. It's
not a normative part of the spec, only a suggestion. The TinyCBOR tool called
"cbordump" mostly follows that recommendation when you use the -j option.
In any case, the output you're seeing is not JSON, but the CBOR "diagnostic
notation" (RFC 7049 section 6). That's what cbordump does if you do not pass
the -j option.
The output indicates that the value associated with the "doxm" key is a CBOR
Byte String. That is, the same thing that COSE does.
Also note that COSE requires that the protected maps also conform to the
canonical format (RFC 7049 section 3.9), but our map doesn't.
> What we expect would be: (white space added for readability actual output
> would be on a single line.)
>
> "doxm": {
> "oxms": [0],
> "oxmsel": 0,
> "sct": 9,
> "owned": true,
> "deviceuuid": "31313131-3131-3131-3131-313131313131",
> "devowneruuid": "32323232-3232-3232-3232-323232323232",
> "rowneruuid": "31313131-3131-3131-3131-313131313131"
> },
Uh... those UUIDs are doubly-encoded. "31" is likely 0x31 == '1'. But the
dashes aren't encoded...
> This tells us that the value stored in the "doxm" map is actually cbor
> encoded data. The problem is RFC-7049 does not know when cbor is encoded
> inside cbor and thinks it is just a collection of binary data.
There's a way to mark that a Byte String contains CBOR, but I've never seen it
used in practice. And to be honest, I'm not sure a decoder should decode the
CBOR contained inside like that.
> As best I can figure we should not be nesting cbor output inside another
> cbor it will not be understood by any other cbor decoders except IoTivity.
This goes back to why we store it like that. Why does it need to be byte-
exact? Where did this come from? Where is it going?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
iotivity-dev mailing list
[email protected]
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
