[Suit] New Version Posted for draft-ietf-suit-manifest-14.txt

[Brendan Moran <[e-mail]>]

I have posted a new version of the suit manifest format.

It has two outstanding issues raised by Øyvind:
1) How do you refer to an integrated payload/dependency in-place for digest validation?

While I understand the motivation for providing a way to reference integrated payloads and integrated dependencies with a special component ID, I do not think this is the best approach because it would cause breakage in the override handling system. Consider a situation like the following:

* Manifest A:
** Sets a digest for Payload A
** Sets a URL for Payload A if unset
** Fetches Payload A to a component ID
** Verifies Payload A
* Manifest B:
** lists Manifest A as a dependency.
** includes Manifest A as an integrated dependency
** includes Payload A as an integrated payload

When it comes to fetch/verification, as you rightly point out, the Manifest Processor should verify the payload in-place prior to copying it anywhere. However Manifest A knows nothing about this. As far as Manifest A is concerned, the payload is hosted remotely. I think this is an important capability and we should not break it.

My take on this requirement is that, where it is required, Fetch should have a hook for handling relative URIs. In the case above, this would allow Fetch to identify a relative URI (in this case #../<envelope-key>), showing that the Payload is stored in an envelope. Fetch then locates the payload within that envelope using the envelope key encoded into the URI.

I think that this is more an argument for a new operation:
suit-condition-integrated-image-match (consumes suit-parameter-uri, suit-parameter-digest)

This requires some consideration around how to handle setting those parameters since they may not apply to a component ID in this case.

I think this would make a fine extension to the SUIT manifest.


There’s an additional consideration on the dependency side of things: Dependencies are referenced by digest, not component-id, so this is slightly different. The expectation has always been that dependencies will be copied into a manifest storage area. This is an important step in many systems because these will have their signatures validated at time of copy, then, for example, HMAC’d if they are valid. Signatures will not be recalculated because they are expensive. In the case of a monolithic file, particularly on a powerful device, this makes less sense. If dependencies are to be left in-place, then fetch is the mechanism by which the manifest processor registers the location of a particular dependency.

That is to say that, barring the introduction of another operation, when fetching a dependency, the fetch operation should skip fetching a relative URI and simply register the manifest digest with the appropriate offset in the containing envelope.



2) Should there be a list of URIs to search for future updates?

I’m not so sure about this. This has a number of system implications that I don’t believe we’ve thought through enough. If it’s an attribute of the manifest, like reference-uri or sequence number, then it prevents a dependency from overriding the URI list if permitted. On the other hand, if we add a command and a parameter (suit-parameter-manifest-source-uri-list, suit-command-monitor-source-uri-list), then it implies an API between the Manifest Processor and the Status Tracker (which would normally have the job of checking for new manifests) that I’m not sure exists.

I think this needs further discussion and I think it would be reasonable to consider it as an extension.

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.