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

[Martin Pagel <[e-mail]>]

Thanks, David, 
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. 

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?
Best
Martin


-----Original Message-----
From: David Brown <[e-mail]> 
Sent: Wednesday, December 19, 2018 9:07 AM
To: Martin Pagel <[e-mail]>
Cc: Michael Richardson <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Suit] self-describing format vs fixed/binary manifest structure

On Thu, Dec 13, 2018 at 11:22:07PM +0000, Martin Pagel wrote:

>In general I actually agree with your assessment. If you have many 
>options, a well defined format like CBOR is much better than custom C 
>structures as you can use a standard, already vetted parsing library.
>The standard parser library turns the CBOR data into a data structure, 
>in IoT usually a pretty complex C structure. As the generic parser does 
>not understand the semantics of the fields (only the syntax as defined 
>by the CDDL), the developer still has to write code to verify a complex 
>data structure and enforce semantics and you still have to test/verify 
>such code.

There has been some good discussion on list about pull vs push parsing.  What you are describing is known as a push parser.  The parser parses the CBOR and converts it into a fairly rich data structure that describes the contents of the CBOR.  This is a common approach, and is quite useful on "powerful" computers, such as host-side tooling to process the data.

However, in a highly-resource-constrained device, this is not typically how it is done.  Usually a "pull" parser is used, which will have entry points to effectively expect a specific (and likely
limited) variant of the manifest, and simply abort if it see what is unexpected.  The data is not converted to another structure, but directly parsed/used in place.  For this kind of use, CBOR works very well.  Draft 3 of the manifest document has an accompanied example parser that works this way.

As a comparitive example, MCUboot uses a custom encoding format for the data in its manifest.  It consists of a small amount of data in a fixed structure (with defined byte ordering and packing), and a set of tag-length-value items (effectively a single CBOR map, with integer keys and all values as bstrs).  This is parsed with a similar custom parser for the data expected.  I expect the parser for the SUIT manifest to be somewhat larger than this, but within a similar magnitude.  Even this simple case of a single map, there is enough variation that a plain struct would not be appropriate to represent this information.

David