Re: [Suit] CBOR pull parsing vs. packed binary format extraction

Hi Øyvind,

You’re correct, this is an extremely limited parser. It’s roughly as limited as it would be if it were interpreting a packed binary format.

This manifest parser makes a number of flexibility sacrifices for the sake of size. It requires:
* authentication is only done with COSE_Sign1
* the only supported algorithm is ES256
* the signer ID is implied (only one signer, for example—this is a legitimate use-case with a trust proxy as raised in a previous IETF meeting)
* no elements of the outer wrapper are parsed except for the authentication wrapper and the manifest
* no severable fields except text
* text is ignored completely (parsing ends before text is encountered)
* only one payload
* no dependencies
* no directives
* vendor and class ID conditions must be present
* no post-conditions
* no post-directives
* payload must be a raw binary
* canonical (sorted) CBOR map encoding is required (this is the point about deterministic ordering)

The intent is to show what the absolute minimum size of a manifest parser can be when many constraints are placed on it in the same way as a packed binary format. This is the sort of parser that could be used by a bootloader for whole-image updates. The intent not necessarily to build a production manifest parser. Though, if you were willing to accept those limitations, there is very little space for bugs due to the structure of the parser.

I believe that this approach is extensible to handling more fields and adding more flexibility, but I’ve not had a chance to build a proof-of-concept.

Thanks,
Brendan

> On 13 Nov 2018, at 13:16, Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no> wrote:
>
> Thanks for sharing!
>
> Your code seems to assume a specific order of map elements, but as far as I know, CDDL (or even CBOR?) doesn't guarantee deterministic ordering.
> Am I missing something?
>
> Also, a full implementation will require the ability to fetch of most or all present elements (if not, why are the elements present?), so in practice the size will be larger, right?
>
> Øyvind
>
>> -----Original Message-----
>> From: Suit <suit-bounces@ietf.org> On Behalf Of Brendan Moran
>> Sent: 13. november 2018 13:24
>> To: suit <suit@ietf.org>
>> Subject: [Suit] CBOR pull parsing vs. packed binary format extraction
>>
>> I have worked up an example pull parser for Class 1 devices. It is
>> published in the suit-manifest-generator repo:
>>
>> https://github.com/ARMmbed/suit-manifest-
>> generator/tree/master/parser-example
>>
>> This repo demonstrates constructing a highly specialised parser for the
>> draft-moran-suit-manifest-03 draft (with one small modification that will
>> be included in the 04 draft) as detailed in README.md.
>>
>> The parser has been built for ARM Cortex-M4 to evaluate size:
>>
>> The parser consumes 560 bytes of flash, uses only a single pointer of
>> state between function calls, returns interpreted integers and references
>> to byte strings to save memory when called, and uses no dynamic
>> memory. It is guaranteed not to issue unaligned accesses, since all
>> accesses are explicitly byte-wise.
>>
>> The parser can be used in a low-resource mode, consuming 333 bytes of
>> flash, but giving up structural validation of the CBOR, and assuming that
>> any fixed components (such as containers) of the manifest are correct
>>
>>
>> I have also provided, for comparison, an unserialised binary structure
>> using the same information and the same parser API. In this instance, the
>> parser consumes 102 bytes of flash. This is not the manifest as defined in
>> draft-pagel-suit-manifest-00.
>>
>> Martin, would you be able to offer an implementation of an updater for
>> class 1 devices using your manifest draft so that we can compare the
>> compiled size?
>>
>> Best Regards,
>> Brendan
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments
>> are confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> _______________________________________________
>> Suit mailing list
>> Suit@ietf.org
>> https://www.ietf.org/mailman/listinfo/suit

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.