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] On Behalf Of Nash, George Sent: 25 October 2017 01:22 To: 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
