[Suit] Combine the best of moran and pagel drafts

[Martin Pagel <[e-mail]>]

Brendan, 
I really like your attempts to simplify the draft further and your proposal of a minimal manifest and parser and 
David and Frank, 
I also like your efforts to make sure the manifest can also be used for secure boot. 

In fact I'm thinking that we might be able to incorporate some of the concepts from the binary format draft into your next draft to effective merge the approaches. If we can tighten the manifest format, then binary vs CBOR becomes a minor difference not worth pursuing. Here are a few thoughts on that:

Cloud vs Broadcast
I believe the current draft is optimized towards the broadcast of many manifests and the device may have to check many manifests in order to determine whether it needs to apply an update while a lot of the manifests would be irrelevant to the device. If however the device could provide its configuration information (vendor and class and version for each of its components) to an Update Server cloud service, the cloud service could just respond with a confirmation that the device is running the proper software or provide a new manifest of the software it should be running. That way the cloud would have the burden of selecting the correct manifest rather than the device. The service may even provide the payload, too, and use channel encryption for privacy. I think it would be beneficial to define a subset which would be simpler and optimized for this scenario, I have no problem if the extra fields (like PreInstallationInfo, DependencyInfo...) would be included for the broadcast scenario.

Severable: I like the concept of severable elements. But if elements are severable, my question is whether they can be eliminated in the first place. There are a lot of strings which the device software won't be able to act on anyways. If it is just meta data, could that meta data just be provided by the cloud service? For example human readable names may be useful for debugging, but could be provided by the cloud service separately if requested. Both the device installation component and the boot loader would rather act on pay load type ids etc

PreDirective: I'm not sure the PreDirective should be part of the manifest. Often update timing can be configured per device depending on the environment the device was set up in and independently from the manifest.

InstallationInfo: I think the device installer should know how to install a particular component or deal with a particular payload type and deal with PostInstallationInfo. I don't think this process will change over time and therefore only adds complexity and size.

Martin




-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Brendan Moran
Sent: Thursday, January 31, 2019 5:28 AM
To: [e-mail]
Cc: [e-mail]; Henk Birkholz <[e-mail]>
Subject: [Suit] Improvements to draft-moran-suit-manifest-03

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.
_______________________________________________
Suit mailing list
[e-mail]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Cc506a9c9363f4b35824f08d6877fe695%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636845380738061367&amp;sdata=%2Fzo99eTfIFnNctuWmDDN7zng3kJiHQz9xitdFbNvRks%3D&amp;reserved=0