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

[Martin Pagel <[e-mail]>]

Hi Brendan, 
Yes, nice tight implementation of CBOR, thanks for sharing. I don't understand your discussion about different private keys for minimal and non-minimal manifest though, I'm concerned if the signature is dependent on the parsing method...

I also like that it shows how a minimal manifest may only use signature, sequence number, vendor/class id, URI, and payload. 

You define the mfst_s struct as a C structure and you set a pointer to access the structure. How is this different from what's proposed for the binary manifest representation? 

You asked me about how much code is required for the parsing of the binary manifest. I reiterate that it only requires a call to verify the signature, all data fields can be accessed via a struct like you did which is resolved by the linker as you pointed out.
Thanks
Martin

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Brendan Moran
Sent: Tuesday, November 13, 2018 7:13 AM
To: Øyvind Rønningstad <[e-mail]>
Cc: suit <[e-mail]>
Subject: 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 <[e-mail]> 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 <[e-mail]> On Behalf Of Brendan Moran
>> Sent: 13. november 2018 13:24
>> To: suit <[e-mail]>
>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> ub.com%2FARMmbed%2Fsuit-manifest-&amp;data=02%7C01%7Cmartin.pagel%40m
>> icrosoft.com%7Cfce38a1566f74c9906e208d6497a80cd%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C636777187832203400&amp;sdata=oo7Q%2F4QSVGcjgc
>> RoJWh0hEH4QhKGlfEeWiJrEPG2nz8%3D&amp;reserved=0
>> 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
>> [e-mail]
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%
>> 40microsoft.com%7Cfce38a1566f74c9906e208d6497a80cd%7C72f988bf86f141af
>> 91ab2d7cd011db47%7C1%7C0%7C636777187832203400&amp;sdata=CrtRADnpWE8PG
>> DfsuPdQfrguHtU%2BaiZK9N3TDPx%2Fpo0%3D&amp;reserved=0

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
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Cfce38a1566f74c9906e208d6497a80cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777187832203400&amp;sdata=CrtRADnpWE8PGDfsuPdQfrguHtU%2BaiZK9N3TDPx%2Fpo0%3D&amp;reserved=0