[Suit] FW: Introducing draft-moran-suit-manifest-04

I did a full pass through the document today, and wrote down (quite a few) comments, see below. I think this document is very exciting!

- Øyvind

The digest-algorithm-ids list is missing the following SHA-2 family functions:
 - SHA224
 - SHA512/224
 - SHA512/256
Also, the functions that are truncated to 128 and fewer bits will not be secure against brute-force attacks, so I question their inclusion here.

The requirement that all manifests must have a sequence number higher than their dependencies might be inconvenient when dependencies are validated by version ranges, since a dependency might be updated to something that is created after the root manifest, but still fulfills the check. Comparing sequence number dependency<->dependent might be superfluous, since the dependency is already referenced quite specifically in other ways. Alternatively, the requirement can be valid only up to and including installation.
Also, the text should probably mention that if a manifest is replaced by an update, the new manifest must have a higher sequence number.

What directives/conditions can apply to components in suit-dependency-components? I don't quite understand the purpose of the suit-dependency-components list.

I read it many times now, but I don't really understand the last paragraph of "8.4.  SUIT_Component". Can you elaborate on the assumptions? How are the values dependent on installation offset? Who updates the parameters to match what? What does "defining a component" mean?

I might have missed something, but can you elaborate on how scoping of parameters work, specifically when are they unset? For example Encryption Info, does it become unset after being used once? Which parameters are inherited into a Run_Sequence or Process_Dependency? Does a Set_Component_Index/Set_Manifest_Index effectively unset all parameters that have scope "Component"/"Dependency". How does scoping affect parallell processing (how to keep track of the value of a parameter for a given Directive/Conditition if they are executed out of order)?	

SUIT_Unpack_Algorithm_Delta should be split into individual IDs for algorithms like SUIT_Unpack_Algorithm_VCDIFF.

I think there's a quirk with the versions where comparisons can be subverted. If you have a dependency on version 1.x of something, it's hard (impossible in the general sense) to express those bounds with the greater/lesser comparisons. This is because there is no well-defined highest or lowest version with a given prefix such as "1." (unless the version list has bounded length).  If you have a bound on the length of the version list, you could express the upper bound e.g. as "Lesser or equal than 1.INTMAX.INTMAX..." etc. which isn't very pretty. Can we find some better way? I'm assuming 1.1 is equivalent (equal) to 1.1.0 etc.

If SUIT_Directive_Set_Component_Index is set to ALL components, is the order in which it applies to the components well-defined? Same question for SUIT_Directive_Set_Manifest_Index. 

Can you give an example of providing an argument to SUIT_Directive_Fetch?

The CDDL for Condition, Directive and Parameters should have the name as part of the CDDL (i.e. as a label/type, not a comment) to make it more amenable to machine parsing.

*The rest is nitpicking*

The SUIT_Manifest CDDL references Digest instead of SUIT_Digest.

Should suit-install be MANDATORY if suit-payload-fetch is present?

I suggest being more specific about suit-validate. Something to the effect of: "suit-validate is a SUIT_Command_Sequence to execute in order to validate that the result of applying the update (i.e. the state of the device after suit-install) is correct."

When forwarding a dependency to a component that is capable of parsing its own manifests, the dependency manifest might not be SUIT-formatted, so it should not need to be interpreted. This could be elaborated on in the text.

This sentence should probably be fixed (typo etc.): "It consists of three elemnts: the component identifier that represents a component that will be affected by this manifest."

Can a SUIT_Component_Reference refer to a component in a dependency of a dependency?

For readability, I suggest placing the "name" column (of the manifest parameters table) further to the left.

Can you elaborate on the "Skip" flag for parameters? Even just mentioning that it is TBD.

This could be more specific: "This index is a numeric index into the component ID tables defined at the beginning of the document."

SUIT_Directive_Set_Parameter_State_Append is not mentioned in the table.

Should "dependent-components" be "dependency-components" instead?

For the sake of completeness: In "Access Control Lists" I envision another situation, where ACL is implemented as a function that e.g. takes the Component ID and returns the identities that can manipulate it. This is for when Component IDs can alias each other, or the component ID contains a flash address, so it doesn't make sense to store every conceivable component ID in a list.

The names in the example in "Creating conditional sequences" don't look right, are they outdated?

An example with dependencies would of course be useful.

-----Original Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Brendan Moran
Sent: Tuesday, March 12, 2019 11:35
To: suit@ietf.org
Subject: [Suit] Introducing draft-moran-suit-manifest-04

draft-moran-suit-manifest-04 has now been published.

https://tools.ietf.org/html/draft-moran-suit-manifest-04

This draft is the result of combining the information model in draft-moran-suit-behavioural-manifests-00 (the 01 version fixes example formatting only) with that in draft-ietf-suit-information-model, then serialising the result in CBOR. This is a significant departure from previous drafts. It attempts to preserve flexibility, fully define the behaviour of recipient, simplify the manifest structure, reduce code-size of the recipient, and reduce the size of the manifest. This ambitious set of goals required a significant change in approach as compared to draft-moran-suit-manifest-03 and before. In order to outline the approach clearly, we have separately published draft-moran-suit-behavioural-manifests-00. draft-moran-suit-manifest-04 focuses more on the serialisation of the manifest.

I look forward to discussing this draft in more detail.

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
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit