Re: [Suit] Which type of devices?

[Brendan Moran <[e-mail]>]

Hi Michael,

You’re absolutely right. I’ve written an example of a completely minimal manifest parser, for a very limited subset of the manifest I proposed.

The “parser” only returns the information that is needed for each step, so it has several functions that must be called in sequence.

This is a pull parser that interacts with the signature verification primitives to initialise a signature verification context in preparation for verifying the COSE_Sign1 structure that is in the manifest outer wrapper.

All builds were done for ARM Cortex-M4. I built this parser in two ways, depending on the bit-size of CBOR integers. This affects two fields in the minimal manifest subset I chose: the payload size and the sequence number.

The test manifest for this minimal subset was 302 bytes and includes a reference digest for a text description, but that description has been severed.

When assuming that all CBOR integers are 64-bit:
Full Structural verification: 562
Information Extraction: 339

When assuming that all CBOR integers are 32-bit:
Full Structural verification: 542
Information Extraction: 323

Given that this is a very rough first try, I expect there is room for further optimisation.

I’ll post the code shortly. For now, however, we have a maximum lower bound that we can use to discuss the suitability of a fixed-function CBOR parser for a fixed, minimal subset of draft-moran-suit-manifest-03.

Best Regards,
Brendan


> On 12 Nov 2018, at 09:52, Michael Richardson <[e-mail]> wrote:
>
>
> Martin Pagel <Martin.Pagel=[e-mail]> wrote:
>> Let me try to describe the process in more detail: From what I
>> understand (correct me if I'm wrong as I'm not a CBOR expert) CBOR uses
>> the first three bits of a field as its type identifier, for example
>> whether the rest is a (5bit) integer or, depending on the following
>> values, is followed by a 16bit or 32bit integer or text string or...
>> As such format is kind of difficult to parse by code natively, you
>> usually load the CBOR data into a temporary receiving buffer and you
>> use a parser which parses the CBOR structure from beginning to end into
>> a more convenient structure such as a C structure or array of
>> structures. For example the parser would store the 5bit value into a
>
> This is certainly how it works with Python or Ruby.
> In C, which is not what I'd do.
>
> I'd look at the CBOR blob, parse enough to find out which key signed it,
> validate the signature, and then I'd mutate the CBOR into formats I can
> use directly.  For instance, setting the upper three bits to zeroes if
> I wanted the 5-bit number directly. (That's probably a silly example, because
> it's just one byte, but maybe it helps to have a length value in front of a
> string)
>
>> 8bit or 16bit integer variable and drop any of the type identifier info
>> so that the application can work with the data just like any other
>> program variables. During that process, the parser needs about twice
>> the memory of the manifest file: one memory area for the receiving
>> buffer and one for the final data the application can conveniently deal
>> with.
>
> I think that I would build a structure that would point to all the strings
> in the original manifest that I needed.  Maybe saving bytes by using offsets
> rather than 32-bit pointers.
>
> It just doesn't seem that hard to me, nor do I think it has to take a lot
> of space.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>
> _______________________________________________
> Suit mailing list
> [e-mail]
> 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.