# Title

OLD: SUIT Manifest Extensions for Multiple Trust Domains 
NEW: Software Update for the Internet of Things (SUIT) Manifest Extensions for Multiple Trust Domains 

# Abstract

Consider swapping the two sentence for better flow

NEW:
   A device has
   more than one trust domain when it enables delegation of different
   rights to mutually distrusting entities for use for different
   purposes or Components in the context of firmware or software update.   This specification describes extensions to the Software Update for the Internet of Things (SUIT) Manifest format
   for use in deployments with multiple trust domains.  

# Introduction 

(1)

CURRENT:
   Devices that go beyond single-signer update require more complex
   rules for deploying software updates.  For example, devices may
   require:

   *  software Components from multiple software signing authorities.

   *  a mechanism to remove an unneeded Component

   *  single-object Dependencies

   *  a partly encrypted Manifest so that distribution does not reveal
      private information

   *  installation performed by a different execution mode than payload
      fetch

I have several comments on this part:

  + Was “single-signer update” introduced in some other documents? I failed to find this use in the suit manifest spec, rfc9019, etc. Same comment applies for “single-object Dependencies" term.

  + I was expecting to see explanation of “more complex” in the examples, which is not currently the case.

  + Consider s/software Components/Components given that “Component” is defined as “An updatable logical block of the Firmware, Software, configuration, or data of the Recipient”. No need to be redundant here.

  + Is the second bullet specific to the multi signer case? Isn’t this applicable even for the single-signer?

  + Where “payload fetch” mode is defined?

(2)

CURRENT:
  A device may contain a processor in its radio  

I don’t parse this. Please reword.

(3) What is a device operator? Is it the vendor? Else? Please consider adding a definition or supply a reference.

(4) Consider add references for TEEP-related entites:

CURRENT:
   *  A Trusted Application Manager (TAM) wants to distribute
      personalisation information to a Trusted Execution Environment in
      addition to a Trusted Application (TA),  

(5) Add a reference for “core Manifest specification”. Also, update the teep architecture to refer rfc9397, instead of the I-D.

CURRENT:
   These mechanisms are not part of the core Manifest specification, but
   they are needed for more advanced use cases, such as the architecture
   described in [I-D.ietf-teep-architecture].

(6) Fall a little bit short :-( A summary of the extensions would be helpful.

CURRENT:
   This specification extends the SUIT Manifest specification
   ([I-D.ietf-suit-manifest]).

# Section 2

I would avoid redundant terms but refer to draft-ietf-suit-manifest#section 2. Only new terms should be listed here.

On the “see” use (not only in this section, but through the document)

CURRENT:
      authorization information, and severable elements (see Section 5.1
      of [I-D.ietf-suit-manifest]).

There are more than 60 occurrences of such in the document. Please simply delete these as this makes the two too heavy. A reference is there to be checked/viewed/seen/etc. :-)

# Section 3

(1) multi trust domain used without being adequately introduced early in the document. Consider teasing this in the introduction:

CURRENT:
  The use of the features presented for use with multiple trust domains 

(2) Other assumptions:

CURRENT:
   One additional assumption is added for the Update Procedure:

   *  All Dependency Manifests must be present before any Payload is
      fetched.

   One additional assumption is added to the Invocation Procedure:

Please call out where the “other” assumptions are defined? I suspect that you meant 4.2 of the manifest. If so, please say so. If not, I need to understand ;-)

# Section 5

(1)

CURRENT:
   A Dependency is another SUIT_Envelope that describes additional
   Components.

   As described in Section 1, Dependencies enable several common use
   cases.

First, cite where the envelope is defined. Second, consider deleting the second sentence; it does not bring much, IMO.

(2) ACLs

CURRENT:
  (no ACLs defining which authorities have access to different
   Components/Commands/Parameters), 

How/where these ACLs are supplied? Can we have examples or a reference where these examples are provided?

(3) Lack of interpreter behavior

CURRENT:
   If the Manifest contains more than one Component and/or Dependency,
   each Command sequence MUST begin with a Set Component Index Command.

Can we include a reminder about what to do when a mandatory condition is not met, I guess the process will abort.

A generic statement would be helpful as this applies to other similar statements in the document.

(4) Where Update is defined?

CURRENT:
   1.  The dependent MUST populate all Command sequences for the current
       Procedure (Update or Invoke).


Can we please add a pointer where this command is defined?

(5)

CURRENT:
   In complex systems, it may not always be clear where the Root
   Manifest should be stored; 

Maybe

NEW:
   In complex systems, it may not always be clear where the Root
   Manifest is stored; 

(6) Broken reference

CURRENT:
   This section augments the Abstract Machine Description (Section 6.4)
   in [I-D.ietf-suit-manifest].   

Please check as there is no 6.4 in this doc. I guess you meant 6.4 of manifest. Please fix.


(7)

CURRENT:
   *  Five new Commands are introduced:

      -  Set Parameters

      -  Process Dependency

      -  Is Dependency

      -  Dependency Integrity

      -  Unlink

Consider adding a statemen to basically invite readers to look at Section 5.6.

(8) what is reference counting/reference count?

CURRENT:
   *  When a Manifest Processor supports shared Dependencies, it MUST
      support reference counting of those Dependencies.

That’is? I don’t get the meaning here. I see “reference count” used in some other parts but I have the same issue to parse the meaning, though.

(9) Lack of elaboration

CURRENT:
   3.  Loads the specified Component as a Dependency Manifest Envelope.

What does that mean concretely? Failed to find an elaboration of this in the doc.

(10) Lack of reference

CURRENT:
   Similar to suit-directive-override-parameters, suit-directive-set-

Cite 8.4.10.3 of manifest (idem for other similar constructs)

(11) Some more reasoning is needed:

CURRENT:
   parameters allows the Manifest to configure behavior of future
   Directives by changing Parameters that are read by those Directives.
   Set Parameters is for use when Dependencies are used because it
   allows a Manifest to modify the behavior of its Dependencies.

This explains why this is useful for dependency, but does not explain it can’t be used for other contexts.

(12) Factorize and ease identify failure conditions


CURRENT:
   If the current Component index does not have an entry in the suit-
   dependencies map, then this Command MUST Abort.

   If the current Component index has not been the target of a suit-
   condition-dependency-integrity, then this Command MUST Abort.

   If the current Component is True, then this Directive applies to all
   Dependencies.  If the current section is "Common metadata," then the
   Command sequence MUST Abort.

May factorize the abort part and list below the conditions as bullet list. 

Also, please consider having a section with a summary of abort conditions defined in this specification.

(13) TTL and Configurable parameters

CURRENT:
   The Manifest Processor MAY cache the results of these operations for
   later use from the context of the current Manifest.   

Is there any TTL associated with this? If so, is that controllable/tunable? 

Similar to the abort comment, consider having a dedicated section on configurable parameters supported by the specification. 

I see that you mention at least two conditions to flush out the cache. That’s great.

# Section 8

Please check this sentence:

CURRENT:
  The Distribution System can Set the Parameter URI in the Fetch/

# Section 9

Any reason the labels weren’t assigned to be consistent with the flow use?

CURRENT:
             | 7     | Dependency Integrity | Section 5.6.4 |
             +-------+----------------------+---------------+
             | 8     | Is Dependency        | Section 5.6.3 |
             +-------+----------------------+---------------+
             | 11    | Process Dependency   | Section 5.6.2 |
             +-------+----------------------+---------------+
             | 19    | Set Parameters       | Section 5.6.1 |
             +-------+----------------------+---------------+
             | 33    | Unlink               | Section 5.6.5 |
             +-------+----------------------+---------------+

Hope this helps.

Cheers,
Med

## Comments

Thank you to Valery Smyslov for the ART ART review.
I would like to see his review addressed on the list.

### overrides the URI 

```
130	      Payloads.  The network operator overrides the URI of a Payload by
131	      providing a dependent Manifest that references the original
132	      Manifest, but replaces its URI.
```

I don't understand this.

This could mean providing a locally sourced alternative to a remote resource, or it could mean redirecting a remote resource to some other resource.

### Terminology

```
260	   *  Image: Information that a Recipient uses to perform its function,
261	      typically Firmware/Software, configuration, or Resource data such
262	      as text or images.  Also, a Payload, once installed is an Image.
```

Consider moving this up, so we can see how Payload, Resource and image are related.
Also consider not repeating "Firmware/Software, configuration, or Resource data".

### Dependent

```
370	   it can skip redundant signature verifications.  For example, if a
371	   dependent's signer has access rights to all Components specified in a
372	   Dependency, then that Dependency does not require a signature
373	   verification.  Similarly, if the signer of the dependent has full
374	   rights to the device, according to the ACL, then no signature
375	   verification is necessary on the Dependency.
```

Consider introducing the concept of a dependent in the terminology section.

```
405	   The single dependent Manifest is sometimes called a Root Manifest.
```

Is this just a graph / network / tree / dag of manifests?

It it possible to specify the required checks in terms of common terminology for graphs?

Perhaps parent / child, ancestor / descendent, etc...

### Dependency Manifest's Component ID

```
418	   be used by the Root Manifest.  When a Dependency Manifest also
419	   declares a Component ID, the Dependency Manifest's Component ID is
420	   overridden by the Component ID declared by the dependent.
```

Children name their parent's component? or parents name their child's components?

Also, why do we care about overriding here?
What problem is the overriding behavior solving?
This section is motivated by "multiple, independent Root Manifests"... but then refers to dependents, which could be of any root I presume?

A diagram would be helpful here.

Later you have:

```
625	   Parameters Directive.  The second Manifest processor MAY also control
626	   which Parameters may be set by the first Manifest processor by means
627	   of an ACL that lists the allowed Parameters.  For example, a URI may
628	   be set by a dependent without a substantial impact on the security
629	   properties of the Manifest.
```

And again later:

```
676	   skip setting the Parameter to its argument.  This allows dependent
677	   Manifests to change the behavior of a Manifest, a Dependency that
678	   wishes to enforce a specific value of a Parameter MAY use suit-
679	   directive-override-parameters instead.
```

### Dependency Manifest Envelopes

```
439	   Dependency Manifest Envelopes.  SUIT_Dependencies is a map of
```

capitalized but not defined.

### Dependency Manifests are also Components

Perhaps introduce them in terminology upfront...

```
206	   *  Component: An updatable logical block of the Firmware, Software,
207	      configuration, or data of the Recipient.
```

later:

```
521	   *  Dependency Manifests are also Components.
```

I'm not an expert on suit, but this seems to confuse a manifest for firmware, with the firmware itself. 
Consider clarifying and consolidating terminology.


### Manifest -> Manifest Processor?


```
544	   As described in Section 5.1, each Manifest [Processor] must invoke each of its [Manifest] ...
```

Also "Manifest Processor" or "Manifest processor" ? ... in several places.


### When is this a MUST?

```
635	   current Manifest.  All Dependency Manifests SHOULD be fetched before
636	   any Payload is fetched to ensure that all Manifests are available and
637	   authenticated before any of the (larger) Payloads are acquired.
```

... when its ok to fail later?... consider making this a MUST.


### Manifest Processor MUST abort?

```
693	   If the current Component index does not have an entry in the suit-
694	   dependencies map, then this Command MUST Abort.
```

or based on:

```
703	   When SUIT_Process_Dependency completes, it forwards the last status
704	   code that occurred in the Dependency.
```

Perhaps the Command must produce an Abort status code?

Later, I see:

```
729	   If any of these steps fails, the Manifest Process MUST immediately
730	   Abort.
```

also all caps abort is the same thing right?

```
754	   or overwrite.  If the reference count of a component is non-zero, any
755	   command that alters that component MUST cause [the Manifest Processor to] ~an~ immediate[ly] ABORT.
```


### MUST NOT allow faults?

```
788	   WARNING: This can cause faults where there are loose Dependencies
789	   (e.g., version range matching, see
790	   [I-D.ietf-suit-update-management]), since a Component can be removed
791	   while it is depended upon by another Component.  To avoid Dependency
792	   faults, a Manifest author MAY use explicit Dependencies where
793	   possible, or a Manifest processor MAY track references to loose
794	   Dependencies via reference counting in the same way as explicit
795	   Dependencies, as described in Section 5.6.5.
```

Why not MUST? Is there some other mechanism that authors would be better able to use to not produce faults?


### Can implement without parse?

```
828	   images are already validated when suit-install is invoked.  This
829	   makes suit-candidate-verification OPTIONAL to implement and OPTIONAL
830	   to parse.
```

I don't understand why the need for the double optionals here.

### Security Considerations

```
1185	10.  Security Considerations
```

The introduction states:

```
13	   This specification describes extensions to the SUIT Manifest format
14	   for use in deployments with multiple trust domains.  A device has
```

Are there no security considerations that are unique to deployments with multiple trust domains?

## Nits

### Reads awk

```
155	   By using Dependencies, Components such as Software, configuration,
156	   and other Resource data authenticated by different Trust Anchors can
157	   be delivered to devices.
```