Re: [Suit] Mechanism to start with CBOR, leaving C-Struct for future extension (2 bytes cost - magic 0x82 0xF6 and 0x82 0x82)

[Martin Pagel <[e-mail]>]

Alex,
Very clever idea! I like the “magic bytes” to distinguish between the formats…
But the increased size kind of defeats the purpose to have a simple tight format which can be easily loaded and interpreted in memory.

I think the manifest format decision should be left to the platform vendor who also develops the update agent (status tracker or communicator). The Update Server will need to know anyway what options a particular platform requires as certain platforms will require specific image types, signature formats, instructions etc. We talked about the fact that every platform won’t support all options. Then the server might as well also generate CBOR or Binary manifest formats and not both.
Martin

From: Suit <[e-mail]> On Behalf Of Alexander Pelov
Sent: Thursday, November 8, 2018 4:50 AM
To: Carsten Bormann <[e-mail]>
Cc: [e-mail]
Subject: Re: [Suit] Mechanism to start with CBOR, leaving C-Struct for future extension (2 bytes cost - magic 0x82 0xF6 and 0x82 0x82)

Hi Carsten ,
On Thu, Nov 8, 2018, 7:31 PM Carsten Bormann <[e-mail]<mailto:[e-mail]> wrote:
On Nov 8, 2018, at 18:50, Alexander Pelov <[e-mail]<mailto:[e-mail]>> wrote:
>
> 0x82 0x82 0xVV 0xC2 0x9A 0xXX 0xX1 0xX2 0xX3 0xX4 OTHER-ENCODING-BYTES 0xXZ 0xXZ ....

I can’t quite parse this (bignum tag on array of lots of elements?)..

Yep, the idea is to have a fixed number of bytes that allows for a non-cbor parser to skip to their payload , while in the same time keeping it a valid cbor construct.

This, a SUIT manifest can be parsed by anyone, even if only to understand "that's not for me"

It is important that the binary blob that contains the non-cbor manifest is in a fixed (and big enough) cbor container. That avoids the need for the binary parser to parse any cbor.

Essentially, the algorithm is:
Read first two bytes, if 0x82 0x82 then :
  Read third byte, if equal to my format version :
  Skip 7 bytes
  Load binary manifest (must have length indicator)
  Skip padding




Of course a bespoke binary header can be carried within CBOR (preferably as a byte string, without needing to mask it as a bignum), and the addition or stripping of an “envelope” like 0x82 0x2A (for a 10-byte binary string) does not require a lot of lines of code.
(See Section 3.2 of draft-ietf-core-multipart-ct for an example how this can be used the other way around, with non-fixed values/lengths.)

The problem here really is that the bespoke byte string loses the extensibility inherent in CBOR.
(We may not care about the additional safety, for code that will be highly robustness tested as well.)
That may be OK for some applications, in which case I’d say go ahead…
The real CBOR representation of the structure follows in the second array element, after all, and the users of the bespoke binary representation simply don’t get to see the extensions.

But in general this is mostly a diversion distracting from getting the information model right…

Completely agree on both points.

What I wanted to point out is that there is a way to ensure extensibility and thus not block on binary formats .

Just focus on CBOR (+the semantics and all that). Worst case scenario, that's a 2 byte overhead on all SUIT manifests.

Alex







Grüße, Carsten