csosto-pk
commented
5 years ago That is correct. We should prepend the CBOR with two representations with 0x84. It is explained in https://tools.ietf.org/html/draft-ietf-core-multipart-ct-02 as well.
We need to fix the examples. And potentially add a serialization example as Oliver requested or at least point to the serialization examples in draft-ietf-core-multipart-ct.
/skg response prototype sampled from the Nexus server: 1901195901C5308201C106092A864886F70D010702A08201B2308201AE0201013100300B06092A864886F70D010701A08201963082019230820139A003020102021059A300291EDAC1331EDEAF790D776339300A06082A8648CE3D0403023034310B3009060355040613025345310C300A060355040A1303414345311730150603550403130E4143452069737375696E67204341301E170D3138313131343039343530335A170D3230313131343039343530335A3027311730150603550403130E44656D6F506C6564676541323939310C300A060355040513033239393059301306072A8648CE3D020106082A8648CE3D0301070342000493C4A3478AF2E14BF6E2576D8254D77AA910F692A11C39C1B3F63E3540A12394C1DE3A08D626DEED5C828E88D0CE02D83E0F63167262755A26F9D3D9BDA9A595A33A303830110603551D0E040A0408470FDF7CE137DB8A30130603551D23040C300A800847627096DA4984FB300E0603551D0F0101FF0404030205A0300A06082A8648CE3D040302034700304402206DB69ABCF5ED1DAA0B768BFF5F526E4CFABC4A3FF24AB411E52A37B7C629284702203FCCC28F4A97E6970718824C4B4731037B81CBB5E12C93EAEA62B3C1DB9F1BE4310019011C5896308193020100301306072A8648CE3D020106082A8648CE3D0301070479307702010104201A67C86249C937722D9AF591EEFAA222278A346A76FE4C40B192221D4F41F9BDA00A06082A8648CE3D030107A1440342000493C4A3478AF2E14BF6E2576D8254D77AA910F692A11C39C1B3F63E3540A12394C1DE3A08D626DEED5C828E88D0CE02D83E0F63167262755A26F9D3D9BDA9A595
/skg response prototype sampled from the Siemens server: 8419011C58433041020100301306072A8648CE3D020106082A8648CE3D030107042730250201010420C2E05527F4C6C8DE0B543275438DD2CE69F6C0A91FE1ECC4975DE3C171EEDB0D1901195901ED308201E906092A864886F70D010702A08201DA308201D60201013100300B06092A864886F70D010701A08201BE308201BA3082015FA0030201020206016711E4D2D6300A06082A8648CE3D040302303531133011060355040A0C0A4D79427573696E657373310D300B06035504070C0453697465310F300D06035504030C06546573744341301E170D3138313131343131303432385A170D3139313131343131303432385A30293119301706035504030C104D7944656D6F506C6564676554573031310C300A060355040513033030313059301306072A8648CE3D020106082A8648CE3D030107034200049782D6567B067CC672F1363AFE74F248451B50E8206E4771934177B3ADC035BCD72C52D721DAA1E3767D32C1AFF1F76C6C0A058D98124C535F62C248F8978570A3673065301F0603551D23041830168014BCA987BFDA2FD4F2BD03C552664E48373E79232F301D0603551D0E04160414ADDD48112D4DDDB7E03C46E655AE9B2CDAA6AC5D300E0603551D0F0101FF04040302078030130603551D25040C300A06082B06010505070302300A06082A8648CE3D0403020349003046022100A84E040A0E2507F86CA9ADCA8B248136914659218B416418052F91D812AE5F5402210092395AEE1735951FF1B753787AC6E3087B73AA52615B74F28A2371FDD393D5B03100
When putting these samples into http://cbor.me/ (a 3rd party CBOR playground) then this interpreter struggles with the Nexus response but is happy when prepending "84" According my reading of RFC 7049 (see https://tools.ietf.org/html/rfc7049#appendix-B) "84" is an indicator for an array containing 4 data items. That matches my understanding of https://tools.ietf.org/html/draft-ietf-ace-coap-est-06#section-5.2.1: the /skg response is provided in a CBOR array with 4 elements (private key object plus content format ID, certificate object plus content format ID)
Hence I tend to think "84" to be correct at the beginning of the byte-wise representation of a CBOR array with 4 data items
My suggestion to the EST-coaps authors: instead or in addition to the examples in CBOR diagnostic representation (left-hand window in http://cbor.me/), provide examples in a byte-wise representation as seen on the network (right-hand window in http://cbor.me/). This might be more handy for non-CBOR-gurus (BTW: I belong to this camp)