[Suit] Improvements to draft-moran-suit-manifest-03

[Brendan Moran <[e-mail]>]

Following IETF103, I have been collecting more use cases and user stories to influence the development of the manifest.

Three points have become very clear:

First, the processing tree is too complicated. There are many possible configurations that would never be used. There is plenty of room for error. In reality, the configurations that seem to be usable are all the combinations of these three operations:
* decrypt
* decompress
* unpack (delta, relocate, hex, etc.)

I have yet to find a use-case where these operations do not appear in this order, or where there is another operation that is missing from this list.

That being the case, a processing tree, while very general-purpose is extra overhead that is not needed. With that in mind, I would like to propose changing the payload model back to something more conventional.

The payload-installation-info structure contains information about
* where to store the firmware image (install-component),
* where to retrieve it (uris),
* whether the firmware image is encrypted and with what algorithm (encrypt-info),
* whether a compression algorithm has been applied to the firmware image and what algorithm has been used (compression-algorithm),
* whether the image is a binary diff or requires relocation (unpack), and
* an indication whether these fields may be overridden by an authorized party (allow-override).

Here is a proposed CDDL snippet for draft-moran-suit-manifest-04:

payload-installation-info = {
   install-component => component-identifier,
   ? allow-override => bool,
   ? uris => uri-list,
   ? encrypt-info => COSE_Encrypt0 / COSE_Encrypt,
   ? compression-algorithm => compression-algorithm-ids,
   ? unpack => [
       unpack-algorithm : unpack-algorithm-ids, ; binary diff, or relocation, or binary-to-text algorithm identifier
       ? unpack-arguments : bytes                 ; private config for the unpack algorithm selected
   ]
}

This should be much easier to understand and implement.


The second point is that regen-info is frequently misunderstood and misused. After some discussion with suit participants, it’s become clear that the regen-info block should be represented as a dedicated “digest algorithm” which solves the same problem as the regen-info block currently does. When incorporated with the changes recommended by Jim Schaad, the result is that we replace COSE_Digest with SUIT_Digest and we remove regen-info. Here is a CDDL snippet that represents SUIT_Digest:

SUIT_Digest = [
   digest-algorithm-id: int,
   digest: bytes,
   ? digest-extra-info: bytes
]

Any needed regen-info can then be contained in the digest-extra-info section with an appropriate algorithm identifier.


The third point of clarity is that we need to do some work in making the manifest easier to parse and process in a constrained environment. I don’t have a simple change to enable that, but we’re working on it.

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.