Wouter, Is the swag2cbor.py the package that does the conversion? George
From: Wouter van der Beek (wovander) [mailto:wovan...@cisco.com] Sent: Wednesday, October 25, 2017 3:38 AM To: Nash, George <george.n...@intel.com>; iotivity-dev@lists.iotivity.org Subject: RE: Questions about json2cbor tool from the security tools folder Hi George, Where in the spec it says that the doxm contains cbor within cbor? Just going over the definition (raml file) for doxm: https://github.com/openconnectivityfoundation/security-models/blob/master/schemas/oic.r.doxm.json then it just defined as an regular json object... which should be mapped directly on to CBOR... e.g. I can't find out where cbor definition is used as a part of the json definition... about cbor conversion, there is an python package that can do this conversion as well. This python package is wrapped in: https://github.com/openconnectivityfoundation/DeviceBuilder it will be good to see how this implementation behaves on this issue. Kind Regards, Wouter From: iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Nash, George Sent: 25 October 2017 01:22 To: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: [dev] Questions about json2cbor tool from the security tools folder Summary of issues: Issue #1: Nesting cbor within cbor 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? Do we expect the json2cbor tool to add-to or remove or change the input *.json? I am asking because I am getting output that does not seem to be valid cbor. See https://jira.iotivity.org/browse/IOT-2826 As listed in the summary, there are at least three possible issues I have discovered with the json2cbor tool. Most of my investigation has been done using the web site http://cbor.me, http://cbor.io, and https://tools.ietf.org/html/rfc7049. I have been using the oic_svr_db_server.json and oic_scr_db_server.dat files from the resource/examples for most my work but I have also verified some of what I am about to say with other files found in the IoTivity project. Detailed description of each issue: Issue #1: Nesting cbor within the cbor output. If you decode the bytes oic_scr_db_server.dat You will something resembling: (output will differ depending on the decoder) (if the decoder were following recommendations of section 4 of the RFC-7049 ) "doxm": h'BF646F786D738100666F786D73656C006373637409656F776E6564F56A64657669636575756964782433313331333133312D333133312D333133312D333133312D3331333133313331333133316C6465766F776E657275756964782433323332333233322D333233322D333233322D333233322D3332333233323332333233326A726F776E657275756964782433313331333133312D333133312D333133312D333133312D333133313331333133313331627274816A6F69632E722E646F786D626966816F6F69632E69662E626173656C696E65FF', 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. 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" }, If we pass the hex from the first decoding result into a cbor2json decoder we get: (white space added) { "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" }, 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. 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. Issue #2: The json2cbor tool is adding and changing information that is not in the original .json file. It changes the "rownerruuid" from the in the oic_svr_db_server.json "creds" array from "32323232-3232-3232-3232-323232323232" to "00000000-0000-0000-0000-000000000000" It also adds two additional values to the "creds" "rt": ["oic.r.cred"], "if": ["oic.if.baseline"] Should our tool be adding values I did not know these were being added till I started inspecting the output in a hex editor. Shouldn't these values be required in the original source json file. Issue #3: Special handling of the "data" value from the "privatedata". Looking at the code this will be a problem in the "publicdata" and "optionaldata" as well since they also have special handling in the code. This is the source of the jira ticket listed above IOT-2826. Currently it is handled differently depending on if you are on master or if you are on 1.3-rel. The json2cbor from master is treating the "data" as a longer byte string while the json2cbor from 1.3-rel is treating data as a shorter bytes string. json2cbor output with annotations to help read. >From master: 64 # text(4) 64617461 # "data" 50 # bytes(16) 41414141414141414141414141414141 # "AAAAAAAAAAAAAAAA" >From 1.3-rel 64 # text(4) 64617461 # "data" 48 # bytes(8) AAAAAAAAAAAAAAAA # "\xAA\xAA\xAA\xAA\xAA\xAA\xAA\xAA" Master takes the string "AAAAAAAAAAAAAAAA" an converts the string to bytes. the hex 0x41 for each letter (ASCII letter 'A'). 1.3-rel treats the string "AAAAAAAAAAAAAAAA" as already byte encoded. so it treats each pair of 'A's as a bite. In both instances I am not sure why it is encoded as bytes and not strings. Both outputs from the json2cbor tool are incorrect according to RFC-7049 the output of "data": "AAAAAAAAAAAAAAAA" should be annotation to help read: 64 # text(4) 64617461 # "data" 70 # text(16) 41414141414141414141414141414141 # "AAAAAAAAAAAAAAAA" note the difference. In both the above examples it is specifying a byte string. While the specification (RFC-7049) states it should be a text string. The OFC specification says nothing about exceptions to RFC-7049. Everywhere I could find information the OFC 1.0 core specification states. <QUOTE> 12.4 Payload Encoding in CBOR OCF implementations shall perform the conversion to CBOR from JSON defined schemas and to JSON from CBOR in accordance with IETF RFC 7049 section 4 unless otherwise specified in this section. </QUOTE> I could not find anything on this from the 1.0 security specification so I am left thinking it should follow RFC-7049 since no exceptions were found in the spec. Anyone have any feedback on the listed issues? Thanks, George Nash
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
