Thanks for the reply Thiago. I will take a look a COSE (RFC-8152). Thanks for pointing out section 6 'diagnostic notation' it really is useful when exploring an encoded cbor file. I did not read section 6 but I did reference Appendix A which is referenced by section 6.
I missed that the UUIDs are doubly encoded. I may add that issue to the list. UUID can be send as 128 bytes no need to encode the string when it already has a standard encoding. One of the major arguments for CBOR is size if we are holding to that argument then we should probably be encoding the UUID. George -----Original Message----- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira Sent: Wednesday, October 25, 2017 6:41 PM To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] Questions about json2cbor tool from the security tools folder 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'BF646F786D738100666F786D73656C006373637409656F776E6564F56A6465766963 > 65757 > 56964782433313331333133312D333133312D333133312D333133312D3331333133313 > 331333 > 133316C6465766F776E657275756964782433323332333233322D333233322D3332333 > 22D333 > 233322D3332333233323332333233326A726F776E65727575696478243331333133313 > 3312D3 > 33133312D333133312D333133312D333133313331333133313331627274816A6F69632 > E722E6 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 iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
