Re: [Suit] self-describing format vs fixed/binary manifest structure - pull parser

[David Brown <[e-mail]>]

On Thu, Dec 20, 2018 at 02:05:14AM +0000, Martin Pagel wrote:

>Yes, I am familiar with pull parsers, thanks to Brendan's example,
>but I'm not sure what the advantage of CBOR encoding provides if you
>build a custom parser for a particular fixed CBOR encoding/schema.
>Seems more complicated (and therefore error-prone) to me than using a
>packed binary structure which apparently MCUboot uses. If I
>understand correctly, you believe that such encoding wouldn't be
>appropriate as a manifest. I proposed to use such binary encoding in
>https://tools.ietf.org/html/draft-pagel-suit-manifest-00.

MCUboot does not use a packed binary structure.  It uses its own
custom TLV encoding which is basically a very limited subset of what
can be described in CBOR.  Effectively, the data is a single map.  The
parser for this TLV format vs a decoder that could decode an actual
CBOR map are fairly insignificant.

>I agree that there will be powerful and flexible MCUs which have
>capabilities where a CBOR  based flexibility would provide benefits,
>but for simple constrained devices, I think there is a benefit to use
>the same simple lean packed encoding for both the boot and update
>process, or am I missing some important aspect? If so, can you
>provide an example?

In reality, MCUboot will likely continue to support its custom TLV
format for quite some time, since the parsing code will still be
smaller than a hand-written CBOR decoder.

I see little advantage to an overly-specialized packed encoding
format, especially if there is variation, especially when it comes to
processing by external tools.  I think most of the requirements for
restricted code size can be handled by merely restricting what
constitutes a valid manifest.

Even with the most memory constrained devices in MCUboot, it has been
useful to be able to extend the format of its manifest (by adding new
tags) without having to disrupt a fixed structure.

David