Draft: draft-ietf-suit-manifest

Commentary: Can we keep suit - dependency - resolution since we are using them in our teep protocol implementation . This is the PR at TEEP protocol for adding examples of suit manifest formats . 
 Unfortunately , this is one of the elements that was deemed too complex to explain in the core specification during IETF111 . I plan to submit a draft shortly that covers this as an extension . 
 Oh , I see , no problem if it is going to be in the extension doc . Sorry I was not participating right after ietf110 to ietf111 .
It is assumed that the reader is familiar with the high-level
firmware update architecture I-D.ietf-suit-architecture and the
threats, requirements, and user stories in I-D.ietf-suit-information-
model.
It is assumed that the reader is familiar with the high-level
firmware update architecture RFC9019 and the threats, requirements,
and user stories in I-D.ietf-suit-information-model.
In this document, these operations are called commands.  Commands are
classed as either conditions or directives.  Conditions have no side-
effects, while directives do have side-effects.  Conceptually, a
sequence of commands is like a script but the used language is
tailored to software updates and Trusted Invocation.
In this document, these operations are called commands.  Commands are
classed as either conditions or directives.  Conditions have no side-
effects, while directives do have side-effects.  Conceptually, a
sequence of commands is like a script but the language is tailored to
software updates and Trusted Invocation.
While the SUIT manifest is informed by and optimized for firmware
update and Trusted Invocation use cases, there is nothing in the I-
D.ietf-suit-information-model that restricts its use to only those
use cases.  Other use cases include the management of trusted
applications (TAs) in a Trusted Execution Environment (TEE), as
discussed in I-D.ietf-teep-architecture.
While the SUIT manifest is informed by and optimized for firmware
update and Trusted Invocation use cases, there is nothing in the SUIT
Information Model (I-D.ietf-suit-information-model) that restricts
its use to only those use cases.  Other use cases include the
management of trusted applications (TAs) in a Trusted Execution
Environment (TEE), as discussed in I-D.ietf-teep-architecture.
Distributing software updates to diverse devices with diverse trust
anchors in a coordinated system presents unique challenges.  Devices
have a broad set of constraints, requiring different metadata to make
appropriate decisions.  There may be many actors in production IoT
systems, each of whom has some authority.  Distributing firmware in
such a multi-party environment presents additional challenges.  Each
party requires a different subset of data.  Some data may not be
accessible to all parties.  Multiple signatures may be required from
parties with different authorities.  This topic is covered in more
depth in I-D.ietf-suit-architecture.  The security aspects are
described in I-D.ietf-suit-information-model.
Distributing software updates to diverse devices with diverse trust
anchors in a coordinated system presents unique challenges.  Devices
have a broad set of constraints, requiring different metadata to make
appropriate decisions.  There may be many actors in production IoT
systems, each of whom has some authority.  Distributing firmware in
such a multi-party environment presents additional challenges.  Each
party requires a different subset of data.  Some data may not be
accessible to all parties.  Multiple signatures may be required from
parties with different authorities.  This topic is covered in more
depth in RFC9019.  The security aspects are described in I-D.ietf-
suit-information-model.
All dependency manifests should be present before any payload is
fetched.
All dependencies and payloads must be validated prior to loading.
All payloads must be validated prior to loading.
Resolve dependencies.
When multiple manifests are used for an update, each manifest's steps
occur in a lockstep fashion; all manifests have dependency resolution
performed before any manifest performs a payload fetch, etc.
The Envelope (see ovr-envelope) contains Delegation Chains, the
Authentication Block, the Manifest, any Severable Elements, and
any Integrated Payloads or Dependencies.
Delegation Chains (see ovr-delegation) allow a Recipient to work
from one of its Trust Anchors to an authority of the
Authentication Block.
The Envelope (see ovr-envelope) contains the Authentication Block,
the Manifest, any Severable Elements, and any Integrated Payloads.
Common metadata, including lists of dependencies and affected
components.
Common metadata, such as affected components.
Integrated dependencies (see ovr-integrated).
The SUIT Envelope is a container that encloses Delegation Chains, the
Authentication Block, the Manifest, any Severable Elements, and any
integrated payloads or dependencies.  The Envelope is used instead of
conventional cryptographic envelopes, such as COSE_Envelope because
it allows modular processing, severing of elements, and integrated
payloads in a way that would add substantial complexity with existing
solutions.  See design-rationale-envelope for a description of the
reasoning for this.
Delegation Chains allow a Recipient to establish a chain of trust
from a Trust Anchor to the signer of a manifest by validating
delegation claims.  Each delegation claim is a RFC8392 CBOR Web
Tokens (CWTs).  The first claim in each list is signed by a Trust
Anchor.  Each subsequent claim in a list is signed by the public key
claimed in the preceding list element.  The last element in each list
claims a public key that can be used to verify a signature in the
Authentication Block (ovr-auth).
See delegation-info for more detail.
The SUIT Envelope is a container that encloses the Authentication
Block, the Manifest, any Severable Elements, and any integrated
payloads.  The Envelope is used instead of conventional cryptographic
envelopes, such as COSE_Envelope because it allows modular
processing, severing of elements, and integrated payloads in a way
that would add substantial complexity with existing solutions.  See
design-rationale-envelope for a description of the reasoning for
this.
Some metadata is used repeatedly and in more than one command
sequence.  In order to reduce the size of the manifest, this metadata
is collected into the Common section.  Common is composed of three
parts: a list of dependencies, a list of components referenced by the
manifest, and a command sequence to execute prior to each other
command sequence.  The common command sequence is typically used to
set commonly used values and perform compatibility checks.  The
common command sequence MUST NOT have any side-effects outside of
setting parameter values.
See manifest-common, and SUIT_Dependency for more detail.
Some metadata is used repeatedly and in more than one command
sequence.  In order to reduce the size of the manifest, this metadata
is collected into the Common section.  Common is composed of two
parts: a list of components referenced by the manifest, and a command
sequence to execute prior to each other command sequence.  The common
command sequence is typically used to set commonly used values and
perform compatibility checks.  The common command sequence MUST NOT
have any side-effects outside of setting parameter values.
See manifest-common for more detail.
Update Command Sequences are: Dependency Resolution, Payload Fetch,
and Payload Installation.  An Update Procedure is the complete set of
each Update Command Sequence, each preceded by the Common Command
Sequence.
Invocation Command Sequences are: System Validation, Image Loading,
and Image Invocation.  A Invocation Procedure is the complete set of
each Invocation Command Sequence, each preceded by the Common Command
Sequence.
Command Sequences are grouped into these sets to ensure that there is
common coordination between dependencies and dependents on when to
execute each command.
To enable ovr-severable, there needs to be a mechanism to verify
integrity of any metadata outside the manifest.  Integrity Check
Values are used to verify the integrity of metadata that is not
contained in the manifest.  This MAY include Severable Command
Sequences, Concise Software Identifiers (I-D.ietf-sacm-coswid), or
Text data.  Integrated Dependencies and Integrated Payloads are
integrity-checked using Command Sequences, so they do not have
Integrity Check Values present in the Manifest.
Update Command Sequences are: Payload Fetch, and Payload
Installation.  An Update Procedure is the complete set of each Update
Command Sequence, each preceded by the Common Command Sequence.
Invocation Command Sequences are: System Validation, Image Loading,
and Image Invocation.  An Invocation Procedure is the complete set of
each Invocation Command Sequence, each preceded by the Common Command
Sequence.
Command Sequences are grouped into these sets to ensure that there is
common coordination between dependencies and dependents on when to
execute each command (dependencies are not defined in this
specification).
To enable ovr-severable, there needs to be a mechanism to verify
integrity of any metadata outside the manifest.  Integrity Check
Values are used to verify the integrity of metadata that is not
contained in the manifest.  This MAY include Severable Command
Sequences, or Text data.  Integrated Payloads are integrity-checked
using Command Sequences, so they do not have Integrity Check Values
present in the Manifest.
A management system severs the Text and CoSWID sections before
sending an Envelope to a constrained Recipient, which saves
Recipient bandwidth.
When a manifest requires encryption, it must be referenced as a
dependency, so a trivial manifest may be used to enclose the
encrypted manifest.  The encrypted manifest may be contained in
the dependent manifest's envelope.
See composite-manifests, encrypted-manifests for more detail.
A management system severs the Text sections before sending an
Envelope to a constrained Recipient, which saves Recipient
bandwidth.
See template-integrated-payload for more detail.
Dependency not available.
Dependency or Payload verification failed.
Missing component from a set.
Payload verification failed.
Missing required component from a Component Set.
Selecting an older manifest in the event of failure of the latest
valid manifest is a robustness mechanism that is necessary for
supporting the requirements in I-D.ietf-suit-architecture, section
Trusted Execution Environments MAY require a failure to invoke a new
installation, rather than a rollback approach.  See I-D.ietf-suit-
information-model, Section 4.2.1 for more discussion on the security
considerations that apply to rollback.
Selecting an older manifest in the event of failure of the latest
valid manifest is a robustness mechanism that is necessary for
supporting the requirements in RFC9019, section 3.5.  It may not be
appropriate for all applications.  In particular Trusted Execution
Environments MAY require a failure to invoke a new installation,
rather than a rollback approach.  See I-D.ietf-suit-information-
model, Section 4.2.1 for more discussion on the security
considerations that apply to rollback.
When validating authenticity of manifests, the manifest processor MAY
use an ACL (see access-control-lists) to determine the extent of the
rights conferred by that authenticity.  Where a device supports only
one level of access, it MAY choose to skip signature verification of
dependencies, since they are referenced by digest.  Where a device
supports more than one trusted party, it MAY choose to defer the
verification of signatures of dependencies until the list of affected
components is known so that it can skip redundant signature
verifications.  For example, a dependency signed by the same author
as the dependent does not require a signature verification.
Similarly, if the signer of the dependent has full rights to the
device, according to the ACL, then no signature verification is
necessary on the dependency.
When validating authenticity of manifests, the manifest processor MAY
use an ACL (see access-control-lists) to determine the extent of the
rights conferred by that authenticity.
If the manifest contains more than one component and/or dependency,
each command sequence MUST begin with a Set Component Index or Set
Dependency Index command.
At the beginning of each section in the dependent: all previous
sections of each dependency have been executed.
At the end of each section in the dependent: The corresponding
section in each dependency has been executed.
If the interpreter does not support dependencies and a manifest
specifies a dependency, then the interpreter MUST reject the
manifest.
specify a digest and a payload for every Component in the
Component Set.
The single dependent manifest is sometimes called a Root Manifest.
If the manifest contains more than one component, each command
sequence MUST begin with a Set Component Index.
specifies a digest and a payload for every Component in the
Component Set.
When executing Common prior to authenticity validation, the Manifest
Processor MUST first evaluate the integrity of the manifest using the
SUIT_Digest present in the authentication block.
The guidelines in Creating Manifests (creating-manifests) require
that the common section contains the applicability checks, so this
section is sufficient for applicability verification.  The parser
MUST restrict acceptable commands to conditions and the following
directives: Override Parameters, Set Parameters, Try Each, and Run
Sequence ONLY.  The manifest parser MUST NOT execute any command with
side-effects outside the parser (for example, Run, Copy, Swap, or
Fetch commands) prior to authentication and any such command MUST
Abort.  The Common Sequence MUST be executed again in its entirety
after authenticity validation.
When executing Common prior to authenticity validation, the Manifest
Processor MUST evaluate the integrity of the manifest using the
SUIT_Digest present in the authentication block.
Alternatively, a Recipient MAY rely on network infrastructure to
filter inapplicable manifests.
The guidelines in Creating Manifests (creating-manifests) require
that the common section contains the applicability checks, so this
section is sufficient for applicability verification.  The parser
MUST restrict acceptable commands to conditions and the following
directives: Override Parameters, Set Parameters, Try Each, and Run
Sequence ONLY.  The manifest parser MUST NOT execute any command with
side-effects outside the parser (for example, Run, Copy, Swap, or
Fetch commands) prior to authentication and any such command MUST
Abort.  The Common Sequence MUST be executed again, in its entirety,
after authenticity validation.
A Recipient MAY rely on network infrastructure to filter inapplicable
manifests.
The heart of the manifest is the list of commands, which are
processed by a Manifest Processor-a form of interpreter.  This
Manifest Processor can be modeled as a simple abstract machine.  This
machine consists of several data storage locations that are modified
by commands.
The heart of the manifest is the list of commands, which are
processed by a Manifest Processor--a form of interpreter.  This
Manifest Processor can be modeled as a simple abstract machine.  This
machine consists of several data storage locations that are modified
by commands.
There are two types of commands, namely those that modify state
(directives) and those that perform tests (conditions).  Parameters
are used as the inputs to commands.  Some directives offer control
flow operations.  Directives target a specific component or
dependency.  A dependency is another SUIT_Envelope that describes
additional components.  Dependencies are identified by digest, but
referenced in commands by Dependency Index, the index into the array
of Dependencies.  A component is a unit of code or data that can be
targeted by an update.  Components are identified by Component
Identifiers, but referenced in commands by Component Index; Component
Identifiers are arrays of binary strings and a Component Index is an
index into the array of Component Identifiers.
There are two types of commands, namely those that modify state
(directives) and those that perform tests (conditions).  Parameters
are used as the inputs to commands.  Some directives offer control
flow operations.  Directives target a specific component.  A
component is a unit of code or data that can be targeted by an
update.  Components are identified by Component Identifiers, but
referenced in commands by Component Index; Component Identifiers are
arrays of binary strings and a Component Index is an index into the
array of Component Identifiers.
As a result, Set Component Index is described as current :=
components[arg].  The actual operation performed for Set Component
Index is described by the following pseudocode, however, because of
the definition of current (above), these are semantically equivalent.
The following table describes the behavior of each command. "params"
represents the parameters for the current component or dependency.
Most commands operate on either a component or a dependency.  Setting
the Component Index clears the Dependency Index.  Setting the
Dependency Index clears the Component Index.
As a result, Set Component Index is described as current :=
components[arg].
The following table describes the behavior of each command. "params"
represents the parameters for the current component.  Most commands
operate on a component.
Integers MUST always be supported by Set Component Index and Set
Dependency Index.  Arrays of integers MUST be supported by Set
Component Index and Set Dependency Index if the Recipient supports 3
or more components or 3 or more dependencies, respectively.  True
MUST be supported by Set Component Index and Set Dependency Index if
the Recipient supports 2 or more components or 2 or more
dependencies, respectively.  Each of these operates on the list of
components or list of dependencies declared in the manifest.
Integer indices are the default case as described in the previous
section.  An array of integers represents a list of the components
(Set Component Index) or a list of dependencies (Set Dependency
Index) to which each subsequent command applies.  The value True
replaces the list of component indices or dependency indices with the
full list of components or the full list of dependencies,
respectively, as defined in the manifest.
Try Each and Run Sequence are affected in the same way as other
commands: they are invoked once for each possible Component or
Dependency.  This means that the sequences that are arguments to Try
Each and Run Sequence are NOT invoked with Component Index = True or
Dependency Index = True, nor are they invoked with array indices.
They are only invoked with integer indices.  The interpreter loops
over the whole sequence, setting the Component Index or Dependency
Index to each index in turn.
Integers MUST always be supported by Set Component Index.  Arrays of
integers MUST be supported by Set Component Index if the Recipient
supports 3 or more components.  True MUST be supported by Set
Component Index if the Recipient supports 2 or more components.  Each
of these operates on the list of components declared in the manifest.
Integer indices are the default case as described in the previous
section.  An array of integers represents a list of the components
(Set Component Index) to which each subsequent command applies.  The
value True replaces the list of component indices with the full list
of components, as defined in the manifest.
Try Each and Run Sequence are affected in the same way as other
commands: they are invoked once for each possible Component.  This
means that the sequences that are arguments to Try Each and Run
Sequence are NOT invoked with Component Index = True, nor are they
invoked with array indices.  They are only invoked with integer
indices.  The interpreter loops over the whole sequence, setting the
Component Index to each index in turn.
When a serialized Manifest Processor encounters a component or
dependency index of True, it does not ignore any commands.  It
applies them to the current component or dependency on each
iteration.
When a serialized Manifest Processor encounters a component index of
True, it does not ignore any commands.  It applies them to the
current component on each iteration.
Set Dependency Index.
To perform more useful parallel operations, a manifest author may
collect sequences of commands in a Run Sequence command.  Then, each
of these sequences MAY be run in parallel.  Each sequence defaults to
Strict Order = True.  To isolate each sequence from each other
sequence, each sequence MUST begin with a Set Component Index or Set
Dependency Index directive with the following exception: when the
index is either True or an array of indices, the Set Component Index
or Set Dependency Index is implied.  Any further Set Component Index
directives MUST cause an Abort.  This allows the interpreter that
issues Run Sequence commands to check that the first element is
correct, then issue the sequence to a parallel execution context to
handle the remainder of the sequence.
As described in required-checks, each manifest must invoke each of
its dependencies sections from the corresponding section of the
dependent.  Any changes made to parameters by the dependency persist
in the dependent.
When a Process Dependency command is encountered, the interpreter
loads the dependency identified by the Current Dependency Index.  The
interpreter first executes the common-sequence section of the
identified dependency, then it executes the section of the dependency
that corresponds to the currently executing section of the dependent.
If the specified dependency does not contain the current section,
Process Dependency succeeds immediately.
The interpreter also performs the checks described in required-checks
to ensure that the dependent is processing the dependency correctly.
When a system has multiple security domains, each domain might
require independent verification of authenticity or security
policies.  Security domains might be divided by separation technology
such as Arm TrustZone, Intel SGX, or another TEE technology.
Security domains might also be divided into separate processors and
memory spaces, with a communication interface between them.
For example, an application processor may have an attached
communications module that contains a processor.  The communications
module might require metadata signed by a specific Trust Authority
for regulatory approval.  This may be a different Trust Authority
than the application processor.
When there are two or more security domains (see I-D.ietf-teep-
architecture), a manifest processor might be required in each.  The
first manifest processor is the normal manifest processor as
described for the Recipient in command-behavior.  The second manifest
processor only executes sections when the first manifest processor
requests it.  An API interface is provided from the second manifest
processor to the first.  This allows the first manifest processor to
request a limited set of operations from the second.  These
operations are limited to: setting parameters, inserting an Envelope,
invoking a Manifest Command Sequence.  The second manifest processor
declares a prefix to the first, which tells the first manifest
processor when it should delegate to the second.  These rules are
enforced by underlying separation of privilege infrastructure, such
as TEEs, or physical separation.
When the first manifest processor encounters a dependency prefix,
that informs the first manifest processor that it should provide the
second manifest processor with the corresponding dependency Envelope.
This is done when the dependency is fetched.  The second manifest
processor immediately verifies any authentication information in the
dependency Envelope.  When a parameter is set for any component that
matches the prefix, this parameter setting is passed to the second
manifest processor via an API.  As the first manifest processor works
through the Procedure (set of command sequences) it is executing,
each time it sees a Process Dependency command that is associated
with the prefix declared by the second manifest processor, it uses
the API to ask the second manifest processor to invoke that
dependency section instead.
This mechanism ensures that the two or more manifest processors do
not need to trust each other, except in a very limited case.  When
parameter setting across security domains is used, it must be very
carefully considered.  Only parameters that do not have an effect on
security properties should be allowed.  The dependency manifest MAY
control which parameters are allowed to be set by using the Override
Parameters directive.  The second manifest processor MAY also control
which parameters may be set by the first manifest processor by means
of an ACL that lists the allowed parameters.  For example, a URI may
be set by a dependent without a substantial impact on the security
properties of the manifest.
To perform more useful parallel operations, a manifest author may
collect sequences of commands in a Run Sequence command.  Then, each
of these sequences MAY be run in parallel.  Each sequence defaults to
Strict Order = True.  To isolate each sequence from each other
sequence, each sequence MUST begin with a Set Component Index
directive with the following exception: when the index is either True
or an array of indices, the Set Component Index is implied.  Any
further Set Component Index directives MUST cause an Abort.  This
allows the interpreter that issues Run Sequence commands to check
that the first element is correct, then issue the sequence to a
parallel execution context to handle the remainder of the sequence.
The author MUST ensure that all parameters consumed by a command are
set prior to invoking that command.  Where Component Index = True or
Dependency Index = True, this means that the parameters consumed by
each command MUST have been set for each Component or Dependency,
respectively.
NOTE: On systems that support only a single component and no
dependencies, Set Component Index has no effect and can be omitted.
The author MUST ensure that all parameters consumed by a command are
set prior to invoking that command.  Where Component Index = True,
this means that the parameters consumed by each command MUST have
been set for each Component.
NOTE: On systems that support only a single component, Set Component
Index has no effect and can be omitted.
Optionally, the Set Parameters directive in the install sequence MAY
also contain Encryption Info (see suit-parameter-encryption-info),
Compression Info (see suit-parameter-compression-info), or Unpack
Info (see suit-parameter-unpack-info) to perform simultaneous
download and decryption, decompression, or unpacking, respectively.
The goal of the Install and Transform template is to use an image
already stored in an identified component to decompress, decrypt, or
unpack at time of installation.
This template is typically used with the Component Download template,
however a modification to that template is required: all Component
Download operations are moved from the common sequence and the
install sequence to the fetch sequence.  The Component Download
template targets a download component identifier, while the Install
and Transform template uses an install component identifier.  In-
place unpacking, decompression, and decryption is complex and
vulnerable to power failure.  Therefore, these identifiers SHOULD be
different; in-place installation SHOULD NOT be used without
establishing guarantees of robustness to power failure.
The goal of the Integrated Payload template is to install a payload
that is included in the manifest envelope.  It is identical to the
Component Download template (firmware-download-template) except that
it places an added restriction on the URI passed to the Set
Parameters directive.
An implementer MAY choose to place a payload in the envelope of a
manifest.  The payload envelope key MAY be a positive or negative
integer.  The payload envelope key MUST NOT be a value between 0 and
24 and it MUST NOT be used by any other envelope element in the
manifest.  The payload MUST be serialized in a bstr element.
The URI for a payload enclosed in this way MUST be expressed as a
fragment-only reference, as defined in RFC3986, Section 4.4.  The
fragment identifier is the stringified envelope key of the payload.
For example, an envelope that contains a payload a key 42 would use a
URI "#42", key -73 would use a URI "#-73".
The goal of the Integrated Payload template is to install a payload
that is included in the manifest envelope.  It is identical to the
Component Download template (firmware-download-template).
An implementer MAY choose to place a payload in the envelope of a
manifest.  The payload envelope key MUST be a string.  The payload
MUST be serialized in a bstr element.
The URI for a payload enclosed in this way MAY be expressed as a
fragment-only reference, as defined in RFC3986, Section 4.4.
A distributor MAY choose to pre-fetch a payload and add it to the
manifest envelope, using the URI as the key.
The goal of the Load & Decompress from Nonvolatile Storage template
is to load an image from a non-volatile component into a volatile
component, decompressing on-the-fly, for example loading a firmware
image from external Flash into RAM.
This template is similar to template-load-ext but additionally
performs decompression.  Hence, the only difference is in setting the
Compression Info parameter.
This template can be modified for decryption or unpacking by adding
Decryption Info or Unpack Info to the Set Parameters directive.
The goal of the Dependency template is to obtain, verify, and process
a dependency manifest as appropriate.
NOTE: Any changes made to parameters in a dependency persist in the
dependent.
An implementer MAY choose to place a dependency's envelope in the
envelope of its dependent.  The dependent envelope key for the
dependency envelope MUST NOT be a value between 0 and 24 and it MUST
NOT be used by any other envelope element in the dependent manifest.
The URI for a dependency enclosed in this way MUST be expressed as a
fragment-only reference, as defined in RFC3986, Section 4.4.  The
fragment identifier is the stringified envelope key of the
dependency.  For example, an envelope that contains a dependency at
key 42 would use a URI "#42", key -73 would use a URI "#-73".
The goal of the Encrypted Manifest template is to fetch and decrypt a
manifest so that it can be used as a dependency.  To use an encrypted
manifest, create a plaintext dependent, and add the encrypted
manifest as a dependency.  The dependent can include very little
information.
A plaintext manifest and its encrypted dependency may also form a
composite manifest (composite-manifests).
If Trusted Invocation (template-secure-boot) is used, only the run
sequence is added to this template, since the common sequence is
populated by this template.
The metadata for SUIT updates is composed of several primary
constituent parts: the Envelope, Delegation Chains, Authentication
Information, Manifest, and Severable Elements.
The metadata for SUIT updates is composed of several primary
constituent parts: the Envelope, Authentication Information,
Manifest, and Severable Elements.
The suit-delegation element MAY carry one or more CBOR Web Tokens
(CWTs) RFC8392, with RFC8747 cnf claims.  They can be used to perform
enhanced authorization decisions.  The CWTs are arranged into a list
of lists.  Each list starts with a CWT authorized by a Trust Anchor,
and finishes with a key used to authenticate the Manifest (see
authentication-info).  This allows an Update Authority to delegate
from a long term Trust Anchor, down through intermediaries, to a
delegate without any out-of-band provisioning of Trust Anchors or
intermediary keys.
A Recipient MAY choose to cache intermediaries and/or delegates.  If
an Update Distributor knows that a targeted Recipient has cached some
intermediaries or delegates, it MAY choose to strip any cached
intermediaries or delegates from the Delegation Chains in order to
reduce bandwidth and energy.
The suit-authentication-wrapper contains a list containing a SUIT
Digest Container (see SUIT_Digest) and one or more cryptographic
authentication wrappers for the Manifest.  These blocks are
implemented as COSE_Mac_Tagged or COSE_Sign_Tagged structures.  Each
of these blocks contains a SUIT_Digest of the Manifest.  This enables
modular processing of the manifest.  The COSE_Mac_Tagged and
COSE_Sign_Tagged blocks are described in RFC 8152 RFC8152.  The suit-
authentication-wrapper MUST come before any element in the
SUIT_Envelope, except for the OPTIONAL suit-delegation, regardless of
canonical encoding of CBOR.  All validators MUST reject any
SUIT_Envelope that begins with any element other than a suit-
authentication-wrapper or suit-delegation.
The suit-authentication-wrapper contains a list containing a SUIT
Digest Container (see SUIT_Digest) and one or more cryptographic
authentication wrappers for the Manifest.  These blocks are
implemented as COSE_Mac_Tagged or COSE_Sign_Tagged structures with
null payloads, indicating that the payload to be used is the SUIT
Digest Container.  This enables modular processing of the manifest.
The COSE_Mac_Tagged and COSE_Sign_Tagged blocks are described in RFC
8152 RFC8152.  The suit-authentication-wrapper MUST come before any
element in the SUIT_Envelope, regardless of canonical encoding of
CBOR.  All validators MUST reject any SUIT_Envelope that begins with
any element other than a suit-authentication-wrapper (NOTE: key
delegation MAY relax this requirement to include a delegation
structure as well).
To use an encrypted manifest, it must be a dependency of a plaintext
manifest.  This allows fine-grained control of what information is
accessible to intermediate systems for the purposes of management,
while still preserving the confidentiality of the manifest contents.
This also means that a Recipient can process an encrypted manifest in
the same way as an encrypted payload, allowing code reuse.
A template for using an encrypted manifest is covered in Encrypted
Manifest Template (template-encrypted-manifest).
The CoSWID, Text section, or any Command Sequence of the Update
Procedure (Dependency Resolution, Image Fetch, Image Installation)
can be either a CBOR structure or a SUIT_Digest.  In each of these
cases, the SUIT_Digest provides for a severable element.  Severable
elements are RECOMMENDED to implement.  In particular, the human-
readable text SHOULD be severable, since most useful text elements
occupy more space than a SUIT_Digest, but are not needed by the
Recipient.  Because SUIT_Digest is a CBOR Array and each severable
element is a CBOR bstr, it is straight-forward for a Recipient to
determine whether an element has been severed.  The key used for a
severable element is the same in the SUIT_Manifest and in the
SUIT_Envelope so that a Recipient can easily identify the correct
data in the envelope.  See integrity-checks for more detail.
The suit-manifest-sequence-number is a monotonically increasing anti-
rollback counter.  It also helps Recipients to determine which in a
set of manifests is the "root" manifest in a given update.  Each
manifest MUST have a sequence number higher than each of its
dependencies.  Each Recipient MUST reject any manifest that has a
sequence number lower than its current sequence number.  For
convenience, an implementer MAY use a UTC timestamp in seconds as the
sequence number. suit-manifest-sequence-number is REQUIRED to
implement.
The Text section, or any Command Sequence of the Update Procedure
(Image Fetch, Image Installation) can be either a CBOR structure or a
SUIT_Digest.  In each of these cases, the SUIT_Digest provides for a
severable element.  Severable elements are RECOMMENDED to implement.
In particular, the human-readable text SHOULD be severable, since
most useful text elements occupy more space than a SUIT_Digest, but
are not needed by the Recipient.  Because SUIT_Digest is a CBOR Array
and each severable element is a CBOR bstr, it is straight-forward for
a Recipient to determine whether an element has been severed.  The
key used for a severable element is the same in the SUIT_Manifest and
in the SUIT_Envelope so that a Recipient can easily identify the
correct data in the envelope.  See integrity-checks for more detail.
The suit-manifest-sequence-number is a monotonically increasing anti-
rollback counter.  Each Recipient MUST reject any manifest that has a
sequence number lower than its current sequence number.  For
convenience, an implementer MAY use a UTC timestamp in seconds as the
sequence number. suit-manifest-sequence-number is REQUIRED to
implement.
Each SUIT_Component_Identifier => map entry contains a map of integer
=> text values.  All SUIT_Component_Identifiers present in suit-text
MUST also be present in suit-common (manifest-common) or the suit-
common of a dependency.
Each SUIT_Component_Identifier => map entry contains a map of integer
=> text values.  All SUIT_Component_Identifiers present in suit-text
MUST also be present in suit-common (manifest-common).
suit-text-version-required is used to represent a version-based
dependency on suit-parameter-version as described in suit-parameter-
version and suit-condition-version.  To describe a version
dependency, a Manifest Author SHOULD populate the suit-text map with
a SUIT_Component_Identifier key for the dependency component, and
place in the corresponding map a suit-text-version-required key with
a free text expression that is representative of the version
constraints placed on the dependency.  This text SHOULD be expressive
enough that a device operator can be expected to understand the
dependency.  This is a free text field and there are no specific
formatting rules.
By way of example only, to express a dependency on a component "['x',
'y']", where the version should be any v1.x later than v1.2.5, but
not v2.0 or above, the author would add the following structure to
the suit-text element.  Note that this text is in cbor-diag notation.
suit-coswid contains a Concise Software Identifier (CoSWID) as
defined in I-D.ietf-sacm-coswid.  This element SHOULD be made
severable so that it can be discarded by the Recipient or an
intermediary if it is not required by the Recipient.
suit-coswid typically requires no processing by the Recipient.
However all Recipients MUST NOT fail if a suit-coswid is present.
suit-common encodes all the information that is shared between each
of the command sequences, including: suit-dependencies, suit-
components, and suit-common-sequence. suit-common is REQUIRED to
implement.
suit-dependencies is a list of SUIT_Dependency blocks that specify
manifests that must be present before the current manifest can be
processed. suit-dependencies is OPTIONAL to implement.
suit-components is a list of suit-component-identifier blocks that
specify the component identifiers that will be affected by the
content of the current manifest. suit-components is REQUIRED to
implement; at least one manifest in a dependency tree MUST contain a
suit-components block.
suit-common encodes all the information that is shared between each
of the command sequences, including: suit-components, and suit-
common-sequence. suit-common is REQUIRED to implement.
suit-components is a list of suit-component-identifier blocks that
specify the component identifiers that will be affected by the
content of the current manifest. suit-components is REQUIRED to
implement.
SUIT_Dependency specifies a manifest that describes a dependency of
the current manifest.  The Manifest is identified, but the Recipient
should expect an Envelope when it acquires the dependency.  This is
because the Manifest is the one invariant element of the Envelope,
where other elements may change by countersigning, adding
authentication blocks, or severing elements.
The suit-dependency-digest specifies the dependency manifest uniquely
by identifying a particular Manifest structure.  This is identical to
the digest that would be present as the payload of any suit-
authentication-block in the dependency's Envelope.  The digest is
calculated over the Manifest structure instead of the COSE
Sig_structure or Mac_structure.  This is necessary to ensure that
removing a signature from a manifest does not break dependencies due
to missing signature elements.  This is also necessary to support the
trusted intermediary use case, where an intermediary re-signs the
Manifest, removing the original signature, potentially with a
different algorithm, or trading COSE_Sign for COSE_Mac.
The suit-dependency-prefix element contains a
SUIT_Component_Identifier (see suit-component-identifier).  This
specifies the scope at which the dependency operates.  This allows
the dependency to be forwarded on to a component that is capable of
parsing its own manifests.  It also allows one manifest to be
deployed to multiple dependent Recipients without those Recipients
needing consistent component hierarchy.  This element is OPTIONAL for
Recipients to implement.
A dependency prefix can be used with a component identifier.  This
allows complex systems to understand where dependencies need to be
applied.  The dependency prefix can be used in one of two ways.  The
first simply prepends the prefix to all Component Identifiers in the
dependency.
A dependency prefix can also be used to indicate when a dependency
manifest needs to be processed by a secondary manifest processor, as
described in hierarchical-interpreters.
A component is a unit of code or data that can be targeted by an
update.  To facilitate composite devices, components are identified
by a list of CBOR byte strings, which allows construction of
hierarchical component structures.  A dependency MAY declare a prefix
to the components defined in the dependency manifest.  Components are
identified by Component Identifiers, but referenced in commands by
Component Index; Component Identifiers are arrays of binary strings
and a Component Index is an index into the array of Component
Identifiers.
A component is a unit of code or data that can be targeted by an
update.  To facilitate composite devices, components are identified
by a list of CBOR byte strings, which allows construction of
hierarchical component structures.  Components are identified by
Component Identifiers, but referenced in commands by Component Index;
Component Identifiers are arrays of binary strings and a Component
Index is an index into the array of Component Identifiers.
Dependency Resolution: suit-dependency-resolution is a
SUIT_Command_Sequence to execute in order to perform dependency
resolution.  Typical actions include configuring URIs of
dependency manifests, fetching dependency manifests, and
validating dependency manifests' contents. suit-dependency-
resolution is REQUIRED to implement and to use when suit-
dependencies is present.
Image Validation: suit-validate is a SUIT_Command_Sequence to
execute in order to validate that the result of applying the
update is correct.  Typical actions involve image validation and
manifest validation. suit-validate is REQUIRED to implement.  If
the manifest contains dependencies, one process-dependency
invocation per dependency or one process-dependency invocation
targeting all dependencies SHOULD be present in validate.
Image Validation: suit-validate is a SUIT_Command_Sequence to
execute in order to validate that the result of applying the
update is correct.  Typical actions involve image validation.
suit-validate is REQUIRED to implement.
Run or Boot: suit-run is a SUIT_Command_Sequence to execute in
order to run an image. suit-run typically contains a single
instruction: either the "run" directive for the invocable manifest
or the "process dependencies" directive for any dependents of the
invocable manifest. suit-run is OPTIONAL to implement.
Goals 1,2,3 form the Update Procedure.  Goals 4,5,6 form the
Invocation Procedure.
Run or Boot: suit-run is a SUIT_Command_Sequence to execute in
order to run an image. suit-run typically contains a single
instruction: the "run" directive. suit-run is OPTIONAL to
implement.
Goals 1,2 form the Update Procedure.  Goals 4,5,6 form the Invocation
Procedure.
Many conditions and directives apply to a given component, and these
generally grouped together.  Therefore, a special command to set the
current component index is provided with a matching command to set
the current dependency index.  This index is a numeric index into the
Component Identifier tables defined at the beginning of the manifest.
For the purpose of setting the index, the two Component Identifier
tables are considered to be concatenated together.
Many conditions and directives apply to a given component, and these
generally grouped together.  Therefore, a special command to set the
current component index is provided.  This index is a numeric index
into the Component Identifier table defined at the beginning of the
manifest.
To facilitate construction of Reports that describe the success, or
failure of a given Procedure, each command is given a Reporting
Policy.  This is an integer bitfield that follows the command and
indicates what the Recipient should do with the Record of executing
the command.  The options are summarized in the table below.
To facilitate construction of Reports that describe the success or
failure of a given Procedure, each command is given a Reporting
Policy.  This is an integer bitfield that follows the command and
indicates what the Recipient should do with the Record of executing
the command.  The options are summarized in the table below.
If the component index is set to True or an array when a command is
executed with a non-zero reporting policy, then the Reporting Engine
MUST receive one Record for each Component, in the order expressed in
the Components list or the component index array.  If the dependency
index is set to True or an array when a command is executed with a
non-zero reporting policy, then the Reporting Engine MUST receive one
Record for each Dependency, in the order expressed in the
Dependencies list or the component index array, respectively.
If the component index is set to True or an array when a command is
executed with a non-zero reporting policy, then the Reporting Engine
MUST receive one Record for each Component, in the order expressed in
the Components list or the component index array.
Many conditions and directives require additional information.  That
information is contained within parameters that can be set in a
consistent way.  This allows reduction of manifest size and
replacement of parameters from one manifest to the next.
Many conditions and directives require additional information.  That
information is contained within parameters that can be set in a
consistent way.  This allows reuse of parameters between commands,
thus reducing manifest size.
CBOR-encoded object parameters are still wrapped in a bstr.  This is
because it allows a parser that is aggregating parameters to
reference the object with a single pointer and traverse it without
understanding the contents.  This is important for modularization and
division of responsibility within a pull parser.  The same
consideration does not apply to Directives because those elements are
invoked with their arguments immediately.
An expiry date for the use of the manifest encoded as the positive
integer number of seconds since 1970-01-01.  Implementations that use
this parameter MUST use a 64-bit internal representation of the
integer.
Encryption Info defines the keys and algorithm information Fetch or
Copy has to use to decrypt the confidentiality protected data.
SUIT_Parameter_Encryption_Info is encoded as a COSE_Encrypt_Tagged
structure wrapped in a bstr.  A separate document will profile the
COSE specification for use of manifest and firmware encrytion.
SUIT_Compression_Info defines any information that is required for a
Recipient to perform decompression operations.  SUIT_Compression_Info
is a map containing this data.  The only element defined for the map
in this specification is the suit-compression-algorithm.  This
document defines the following suit-compression-algorithm's: ZLIB
RFC1950, Brotli RFC7932, and ZSTD RFC8878.
Additional suit-compression-algorithm's can be registered through the
IANA-maintained registry.  If such a format requires more data than
an algorithm identifier, one or more new elements MUST be introduced
by specifying an element for SUIT_Compression_Info-extensions.
SUIT_Unpack_Info defines the information required for a Recipient to
interpret a packed format.  This document defines the use of the
following binary encodings: Intel HEX HEX, Motorola S-record SREC,
Executable and Linkable Format (ELF) ELF, and Common Object File
Format (COFF) COFF.
Additional packing formats can be registered through the IANA-
maintained registry.
A URI from which to fetch a resource, encoded as a text string.  CBOR
Tag 32 is not used because the meaning of the text string is
unambiguous in this context.
A URI Reference (RFC3986) from which to fetch a resource, encoded as
a text string.  CBOR Tag 32 is not used because the meaning of the
text string is unambiguous in this context.
This parameter sets the minimum battery level in mWh.  This parameter
is encoded as a positive integer.  Used with suit-condition-minimum-
battery (suit-condition-minimum-battery).
This parameter sets the priority of the update.  This parameter is
encoded as an integer.  It is used along with suit-condition-update-
authorized (suit-condition-update-authorized) to ask an application
for permission to initiate an update.  This does not constitute a
privilege inversion because an explicit request for authorization has
been provided by the Update Authority in the form of the suit-
condition-update-authorized command.
Applications MAY define their own meanings for the update priority.
For example, critical reliability & vulnerability fixes MAY be given
negative numbers, while bug fixes MAY be given small positive
numbers, and feature additions MAY be given larger positive numbers,
which allows an application to make an informed decision about
whether and when to allow an update to proceed.
Indicates allowable versions for the specified component.  Allowable
versions can be specified, either with a list or with range matching.
This parameter is compared with version asserted by the current
component when suit-condition-version (suit-condition-version) is
invoked.  The current component may assert the current version in
many ways, including storage in a parameter storage database, in a
metadata object, or in a known location within the component itself.
Greater.
Greater or Equal.
Equal.
Lesser or Equal.
Lesser.
Versions are encoded as a CBOR list of integers.  Comparisons are
done on each integer in sequence.  Comparison stops after all
integers in the list defined by the manifest have been consumed OR
after a non-equal match has occurred.  For example, if the manifest
defines a comparison, "Equal [1]", then this will match all version
sequences starting with 1.  If a manifest defines both "Greater or
Equal [1,0]" and "Lesser [1,10]", then it will match versions 1.0.x
up to, but not including 1.10.
While the exact encoding of versions is application-defined, semantic
versions map conveniently.  For example,
1.2.3 = [1,2,3].
1.2-rc3 = [1,2,-1,3].
1.2-beta = [1,2,-2].
1.2-alpha = [1,2,-3].
1.2-alpha4 = [1,2,-3,4].
suit-condition-version is OPTIONAL to implement.
The first integer represents the major number.  This indicates
breaking changes to the component.
The second integer represents the minor number.  This is typically
reserved for new features or large, non-breaking changes.
The third integer is the patch version.  This is typically
reserved for bug fixes.
The fourth integer is the build number.
Where Alpha (-3), Beta (-2), and Release Candidate (-1) are used,
they are inserted as a negative number between Minor and Patch
numbers.  This allows these releases to compare correctly with final
releases.  For example, Version 2.0, RC1 should be lower than Version
2.0.0 and higher than any Version 1.x.  By encoding RC as -1, this
works correctly: [2,0,-1,1] compares as lower than [2,0,0].
Similarly, beta (-2) is lower than RC and alpha (-3) is lower than
RC.
suit-directive-wait (suit-directive-wait) directs the manifest
processor to pause until a specified event occurs.  The suit-
parameter-wait-info encodes the parameters needed for the directive.
The exact implementation of the pause is implementation-defined.  For
example, this could be done by blocking on a semaphore, registering
an event handler and suspending the manifest processor, polling for a
notification, or aborting the update entirely, then restarting when a
notification is received.
suit-parameter-wait-info is encoded as a map of wait events.  When
ALL wait events are satisfied, the Manifest Processor continues.  The
wait events currently defined are described in the following table.
suit-wait-event-other-device-version reuses the encoding of suit-
parameter-version-match.  It is encoded as a sequence that contains
an implementation-defined bstr identifier for the other device, and a
list of one or more SUIT_Parameter_Version_Match.
Indicates a list of URIs from which to fetch a resource.  The URI
list is encoded as a list of text string, in priority order.  CBOR
Tag 32 is not used because the meaning of the text string is
unambiguous in this context.  The Recipient should attempt to fetch
the resource from each URI in turn, ruling out each, in order, if the
resource is inaccessible or it is otherwise undesirable to fetch from
that URI. suit-parameter-uri-list is consumed by suit-directive-
fetch-uri-list (suit-directive-fetch-uri-list).
The Strict Order Parameter allows a manifest to govern when
directives can be executed out-of-order.  This allows for systems
that have a sensitivity to order of updates to choose the order in
which they are executed.  It also allows for more advanced systems to
parallelize their handling of updates.  Strict Order defaults to
True.  It MAY be set to False when the order of operations does not
matter.  When arriving at the end of a command sequence, ALL commands
MUST have completed, regardless of the state of
SUIT_Parameter_Strict_Order.  SUIT_Process_Dependency must preserve
and restore the state of SUIT_Parameter_Strict_Order.  If
SUIT_Parameter_Strict_Order is returned to True, ALL preceding
commands MUST complete before the next command is executed.
The Strict Order Parameter allows a manifest to govern when
directives can be executed out-of-order.  This allows for systems
that have a sensitivity to order of updates to choose the order in
which they are executed.  It also allows for more advanced systems to
parallelize their handling of updates.  Strict Order defaults to
True.  It MAY be set to False when the order of operations does not
matter.  When arriving at the end of a command sequence, ALL commands
MUST have completed, regardless of the state of
SUIT_Parameter_Strict_Order.  If SUIT_Parameter_Strict_Order is
returned to True, ALL preceding commands MUST complete before the
next command is executed.
Verify that the current component does not match the suit-parameter-
image-digest (suit-parameter-image-digest).  If no digest is
specified, the condition fails. suit-condition-image-not-match is
OPTIONAL to implement.
Verify that the current time is BEFORE the specified time. suit-
condition-use-before is used to specify the last time at which an
update should be installed.  The recipient evaluates the current time
against the suit-parameter-use-before parameter (suit-parameter-use-
before), which must have already been set as a parameter, encoded as
seconds after 1970-01-01 00:00:00 UTC.  Timestamp conditions MUST be
evaluated in 64 bits, regardless of encoded CBOR size. suit-
condition-use-before is OPTIONAL to implement.
suit-condition-minimum-battery provides a mechanism to test a
Recipient's battery level before installing an update.  This
condition is primarily for use in primary-cell applications, where
the battery is only ever discharged.  For batteries that are charged,
suit-directive-wait is more appropriate, since it defines a "wait"
until the battery level is sufficient to install the update. suit-
condition-minimum-battery is specified in mWh. suit-condition-
minimum-battery is OPTIONAL to implement. suit-condition-minimum-
battery consumes suit-parameter-minimum-battery (suit-parameter-
minimum-battery).
Request Authorization from the application and fail if not
authorized.  This can allow a user to decline an update. suit-
parameter-update-priority (suit-parameter-update-priority) provides
an integer priority level that the application can use to determine
whether or not to authorize the update.  Priorities are application
defined. suit-condition-update-authorized is OPTIONAL to implement.
If the following commands apply to NO components, then the boolean
value "False" is used.  When suit-directive-set-dependency-index is
used, suit-directive-set-component-index = False is implied.  When
suit-directive-set-component-index is used, suit-directive-set-
dependency-index = False is implied.
Set Dependency Index defines the manifest to which successive
directives and conditions will apply.  The supplied argument MUST be
either a boolean or an unsigned integer index into the dependencies,
or an array of unsigned integer indices into the list of
dependencies.  If the following directives apply to ALL dependencies,
then the boolean value "True" is used instead of an index.  If the
following directives apply to NO dependencies, then the boolean value
"False" is used.  When suit-directive-set-component-index is used,
suit-directive-set-dependency-index = False is implied.  When suit-
directive-set-dependency-index is used, suit-directive-set-component-
index = False is implied.
If dependency index is set to True when a command is invoked, then
the command applies to all dependencies, in the order they appear in
suit-common-components.  When the Manifest Processor invokes a
command while the dependency index is set to True, the Manifest
Processor MUST execute the command once for each possible dependency
index, ensuring that the command receives the parameters
corresponding to that dependency index.  If the dependency index is
set to an array of unsigned integers, then the Manifest Processor
MUST execute the command once for each listed dependency index,
ensuring that the command receives the parameters corresponding to
that dependency index.
See index-true for more details.
Typical operations that require suit-directive-set-dependency-index
include setting a source URI or Encryption Information, invoking
"Fetch," or invoking "Process Dependency" for an individual
dependency.
Execute the commands in the common section of the current dependency,
followed by the commands in the equivalent section of the current
dependency.  For example, if the current section is "fetch payload,"
this will execute "common" in the current dependency, then "fetch
payload" in the current dependency.  Once this is complete, the
command following suit-directive-process-dependency will be
processed.
If the current dependency is False, this directive has no effect.  If
the current dependency is True, then this directive applies to all
dependencies.  If the current section is "common," then the command
sequence MUST be terminated with an error.
When SUIT_Process_Dependency completes, it forwards the last status
code that occurred in the dependency.
suit-directive-set-parameters allows the manifest to configure
behavior of future directives by changing parameters that are read by
those directives.  When dependencies are used, suit-directive-set-
parameters also allows a manifest to modify the behavior of its
dependencies.
Available parameters are defined in secparameters.
If a parameter is already set, suit-directive-set-parameters will
skip setting the parameter to its argument.  This provides the core
of the override mechanism, allowing dependent manifests to change the
behavior of a manifest.
suit-directive-set-parameters does not specify a reporting policy.
suit-directive-fetch can target one or more manifests and one or more
payloads. suit-directive-fetch retrieves each component and each
manifest listed in component-index and dependency-index,
respectively.  If component-index or dependency-index is True,
instead of an integer, then all current manifest components/manifests
are fetched.  The current manifest's dependent-components are not
automatically fetched.  In order to pre-fetch these, they MUST be
specified in a component-index integer.
suit-directive-fetch can target one or more payloads. suit-directive-
fetch retrieves each component listed in component-index.  If
component-index is True, instead of an integer, then all current
manifest components are fetched.  If component-index is an array,
then all listed components are fetched.
The behavior of suit-directive-fetch can be modified by setting one
or more of SUIT_Parameter_Encryption_Info,
SUIT_Parameter_Compression_Info, SUIT_Parameter_Unpack_Info.  These
three parameters each activate and configure a processing step that
can be applied to the data that is transferred during suit-directive-
fetch.
suit-directive-fetch-uri-list uses the same semantics as suit-
directive-fetch (suit-directive-fetch), except that it iterates over
the URI List (suit-parameter-uri-list) to select a URI to fetch from.
suit-directive-copy instructs the manifest processor to obtain one or
more payloads, as specified by the component index.  As described in
index-true component index may be a single integer, a list of
integers, or True. suit-directive-copy retrieves each component
specified by the current component-index, respectively.  The current
manifest's dependent-components are not automatically copied.  In
order to copy these, they MUST be specified in a component-index
integer.
The behavior of suit-directive-copy can be modified by setting one or
more of SUIT_Parameter_Encryption_Info,
SUIT_Parameter_Compression_Info, SUIT_Parameter_Unpack_Info.  These
three parameters each activate and configure a processing step that
can be applied to the data that is transferred during suit-directive-
copy.
suit-directive-copy instructs the manifest processor to obtain one or
more payloads, as specified by the component index.  As described in
index-true component index may be a single integer, a list of
integers, or True. suit-directive-copy retrieves each component
specified by the current component-index, respectively.
Once the current Command Sequence is complete, the manifest
processors checks each marked component to see whether any other
manifests have referenced it.  Those marked components with no other
references are deleted.  The manifest processor MAY choose to ignore
a Unlink directive depending on device policy.
suit-directive-unlink is OPTIONAL to implement in manifest
processors.
When the CoSWID, Text section, or any Command Sequence of the Update
Procedure is made severable, it is moved to the Envelope and replaced
with a SUIT_Digest.  The SUIT_Digest is computed over the entire bstr
enclosing the Manifest element that has been moved to the Envelope.
Each element that is made severable from the Manifest is placed in
the Envelope.  The keys for the envelope elements have the same
values as the keys for the manifest elements.
When the Text section or any Command Sequence of the Update Procedure
is made severable, it is moved to the Envelope and replaced with a
SUIT_Digest.  The SUIT_Digest is computed over the entire bstr
enclosing the Manifest element that has been moved to the Envelope.
Each element that is made severable from the Manifest is placed in
the Envelope.  The keys for the envelope elements have the same
values as the keys for the manifest elements.
This document is about a manifest format protecting and describing
how to retrieve, install, and invoke firmware images and as such it
is part of a larger solution for delivering firmware updates to IoT
devices.  A detailed security treatment can be found in the
architecture RFC9019 and in the information model I-D.ietf-suit-
information-model documents.