< draft-ietf-suit-manifest-08.txt   draft-ietf-suit-manifest-09.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Standards Track Arm Limited Intended status: Standards Track Arm Limited
Expires: January 13, 2021 H. Birkholz Expires: January 14, 2021 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
K. Zandberg K. Zandberg
Inria Inria
July 12, 2020 July 13, 2020
A Concise Binary Object Representation (CBOR)-based Serialization Format A Concise Binary Object Representation (CBOR)-based Serialization Format
for the Software Updates for Internet of Things (SUIT) Manifest for the Software Updates for Internet of Things (SUIT) Manifest
draft-ietf-suit-manifest-08 draft-ietf-suit-manifest-09
Abstract Abstract
This specification describes the format of a manifest. A manifest is This specification describes the format of a manifest. A manifest is
a bundle of metadata about the firmware for an IoT device, where to a bundle of metadata about the firmware for an IoT device, where to
find the firmware, the devices to which it applies, and cryptographic find the firmware, the devices to which it applies, and cryptographic
information protecting the manifest. Firmware updates and secure information protecting the manifest. Firmware updates and secure
boot both tend to use sequences of common operations, so the manifest boot both tend to use sequences of common operations, so the manifest
encodes those sequences of operations, rather than declaring the encodes those sequences of operations, rather than declaring the
metadata. The manifest also serves as a building block for secure metadata. The manifest also serves as a building block for secure
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2021. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5.4.2. Common . . . . . . . . . . . . . . . . . . . . . . . 13 5.4.2. Common . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.3. Command Sequences . . . . . . . . . . . . . . . . . . 14 5.4.3. Command Sequences . . . . . . . . . . . . . . . . . . 14
5.4.4. Integrity Check Values . . . . . . . . . . . . . . . 14 5.4.4. Integrity Check Values . . . . . . . . . . . . . . . 14
5.4.5. Human-Readable Text . . . . . . . . . . . . . . . . . 14 5.4.5. Human-Readable Text . . . . . . . . . . . . . . . . . 14
5.5. Severable Elements . . . . . . . . . . . . . . . . . . . 15 5.5. Severable Elements . . . . . . . . . . . . . . . . . . . 15
5.6. Integrated Dependencies and Payloads . . . . . . . . . . 15 5.6. Integrated Dependencies and Payloads . . . . . . . . . . 15
6. Interpreter Behavior . . . . . . . . . . . . . . . . . . . . 15 6. Interpreter Behavior . . . . . . . . . . . . . . . . . . . . 15
6.1. Interpreter Setup . . . . . . . . . . . . . . . . . . . . 16 6.1. Interpreter Setup . . . . . . . . . . . . . . . . . . . . 16
6.2. Required Checks . . . . . . . . . . . . . . . . . . . . . 17 6.2. Required Checks . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Minimizing Signature Verifications . . . . . . . . . 18 6.2.1. Minimizing Signature Verifications . . . . . . . . . 18
6.3. Interpreter Fundamental Properties . . . . . . . . . . . 18 6.3. Interpreter Fundamental Properties . . . . . . . . . . . 19
6.4. Abstract Machine Description . . . . . . . . . . . . . . 19 6.4. Abstract Machine Description . . . . . . . . . . . . . . 19
6.5. Serialized Processing Interpreter . . . . . . . . . . . . 21 6.5. Special Cases of Component Index and Dependency Index . . 21
6.6. Parallel Processing Interpreter . . . . . . . . . . . . . 21 6.6. Serialized Processing Interpreter . . . . . . . . . . . . 22
6.7. Processing Dependencies . . . . . . . . . . . . . . . . . 22 6.7. Parallel Processing Interpreter . . . . . . . . . . . . . 22
6.8. Multiple Manifest Processors . . . . . . . . . . . . . . 22 6.8. Processing Dependencies . . . . . . . . . . . . . . . . . 23
7. Creating Manifests . . . . . . . . . . . . . . . . . . . . . 23 6.9. Multiple Manifest Processors . . . . . . . . . . . . . . 23
7.1. Compatibility Check Template . . . . . . . . . . . . . . 24 7. Creating Manifests . . . . . . . . . . . . . . . . . . . . . 24
7.2. Secure Boot Template . . . . . . . . . . . . . . . . . . 24 7.1. Compatibility Check Template . . . . . . . . . . . . . . 25
7.3. Firmware Download Template . . . . . . . . . . . . . . . 25 7.2. Secure Boot Template . . . . . . . . . . . . . . . . . . 25
7.4. Install Template . . . . . . . . . . . . . . . . . . . . 25 7.3. Firmware Download Template . . . . . . . . . . . . . . . 26
7.5. Integrated Payload Template . . . . . . . . . . . . . . . 26 7.4. Install Template . . . . . . . . . . . . . . . . . . . . 26
7.6. Load from Nonvolatile Storage Template . . . . . . . . . 26 7.5. Integrated Payload Template . . . . . . . . . . . . . . . 27
7.7. Load & Decompress from Nonvolatile Storage Template . . . 26 7.6. Load from Nonvolatile Storage Template . . . . . . . . . 27
7.8. Dependency Template . . . . . . . . . . . . . . . . . . . 27 7.7. Load & Decompress from Nonvolatile Storage Template . . . 27
7.8.1. Composite Manifests . . . . . . . . . . . . . . . . . 27 7.8. Dependency Template . . . . . . . . . . . . . . . . . . . 28
7.9. Encrypted Manifest Template . . . . . . . . . . . . . . . 28 7.8.1. Composite Manifests . . . . . . . . . . . . . . . . . 28
7.10. A/B Image Template . . . . . . . . . . . . . . . . . . . 28 7.9. Encrypted Manifest Template . . . . . . . . . . . . . . . 29
8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 29 7.10. A/B Image Template . . . . . . . . . . . . . . . . . . . 29
8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 30 8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 30
8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 30 8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 31
8.3. Delegation Chains . . . . . . . . . . . . . . . . . . . . 30 8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4. Authenticated Manifests . . . . . . . . . . . . . . . . . 31 8.3. Delegation Chains . . . . . . . . . . . . . . . . . . . . 31
8.5. Encrypted Manifests . . . . . . . . . . . . . . . . . . . 31 8.4. Authenticated Manifests . . . . . . . . . . . . . . . . . 32
8.6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 31 8.5. Encrypted Manifests . . . . . . . . . . . . . . . . . . . 32
8.6.1. suit-manifest-version . . . . . . . . . . . . . . . . 32 8.6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 32
8.6.2. suit-manifest-sequence-number . . . . . . . . . . . . 32 8.6.1. suit-manifest-version . . . . . . . . . . . . . . . . 33
8.6.3. suit-reference-uri . . . . . . . . . . . . . . . . . 32 8.6.2. suit-manifest-sequence-number . . . . . . . . . . . . 33
8.6.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 33 8.6.3. suit-reference-uri . . . . . . . . . . . . . . . . . 33
8.7. text-version-required . . . . . . . . . . . . . . . . . . 34 8.6.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 34
8.7.1. suit-coswid . . . . . . . . . . . . . . . . . . . . . 34 8.7. text-version-required . . . . . . . . . . . . . . . . . . 35
8.7.2. suit-common . . . . . . . . . . . . . . . . . . . . . 35 8.7.1. suit-coswid . . . . . . . . . . . . . . . . . . . . . 35
8.7.3. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 36 8.7.2. suit-common . . . . . . . . . . . . . . . . . . . . . 36
8.7.4. Reporting Policy . . . . . . . . . . . . . . . . . . 39 8.7.3. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 37
8.7.5. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 40 8.7.4. Reporting Policy . . . . . . . . . . . . . . . . . . 40
8.7.6. SUIT_Condition . . . . . . . . . . . . . . . . . . . 50 8.7.5. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 41
8.7.7. SUIT_Directive . . . . . . . . . . . . . . . . . . . 54 8.7.6. SUIT_Condition . . . . . . . . . . . . . . . . . . . 51
8.7.8. Integrity Check Values . . . . . . . . . . . . . . . 60 8.7.7. SUIT_Directive . . . . . . . . . . . . . . . . . . . 55
8.8. Severable Elements . . . . . . . . . . . . . . . . . . . 61 8.7.8. Integrity Check Values . . . . . . . . . . . . . . . 62
9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 61 8.8. Severable Elements . . . . . . . . . . . . . . . . . . . 62
10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 62 9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 63
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 63
11.1. SUIT Commands . . . . . . . . . . . . . . . . . . . . . 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
11.2. SUIT Parameters . . . . . . . . . . . . . . . . . . . . 64 11.1. SUIT Commands . . . . . . . . . . . . . . . . . . . . . 64
11.3. SUIT Text Values . . . . . . . . . . . . . . . . . . . . 66 11.2. SUIT Parameters . . . . . . . . . . . . . . . . . . . . 65
11.4. SUIT Component Text Values . . . . . . . . . . . . . . . 66 11.3. SUIT Text Values . . . . . . . . . . . . . . . . . . . . 67
11.5. SUIT Algorithm Identifiers . . . . . . . . . . . . . . . 66 11.4. SUIT Component Text Values . . . . . . . . . . . . . . . 67
11.5.1. SUIT Digest Algorithm Identifiers . . . . . . . . . 66 11.5. SUIT Algorithm Identifiers . . . . . . . . . . . . . . . 67
11.5.2. SUIT Compression Algorithm Identifiers . . . . . . . 67 11.5.1. SUIT Digest Algorithm Identifiers . . . . . . . . . 67
11.5.3. Unpack Algorithms . . . . . . . . . . . . . . . . . 67 11.5.2. SUIT Compression Algorithm Identifiers . . . . . . . 68
12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 11.5.3. Unpack Algorithms . . . . . . . . . . . . . . . . . 68
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 69
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69
14.1. Normative References . . . . . . . . . . . . . . . . . . 68 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
14.2. Informative References . . . . . . . . . . . . . . . . . 69 14.1. Normative References . . . . . . . . . . . . . . . . . . 69
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 70 14.2. Informative References . . . . . . . . . . . . . . . . . 70
A. Full CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . 71 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 A. Full CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.1. Example 0: Secure Boot . . . . . . . . . . . . . . . . . 82 B. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.1. Example 0: Secure Boot . . . . . . . . . . . . . . . . . 83
B.2. Example 1: Simultaneous Download and Installation of B.2. Example 1: Simultaneous Download and Installation of
Payload . . . . . . . . . . . . . . . . . . . . . . . . . 84 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.3. Example 2: Simultaneous Download, Installation, Secure B.3. Example 2: Simultaneous Download, Installation, Secure
Boot, Severed Fields . . . . . . . . . . . . . . . . . . 87 Boot, Severed Fields . . . . . . . . . . . . . . . . . . 88
B.4. Example 3: A/B images . . . . . . . . . . . . . . . . . . 91 B.4. Example 3: A/B images . . . . . . . . . . . . . . . . . . 92
B.5. Example 4: Load and Decompress from External Storage . . 95 B.5. Example 4: Load and Decompress from External Storage . . 96
B.6. Example 5: Two Images . . . . . . . . . . . . . . . . . . 99 B.6. Example 5: Two Images . . . . . . . . . . . . . . . . . . 100
C. Design Rational . . . . . . . . . . . . . . . . . . . . . . . 102 C. Design Rational . . . . . . . . . . . . . . . . . . . . . . . 103
C.1. C.1 Design Rationale: Envelope . . . . . . . . . . . . . 103 C.1. C.1 Design Rationale: Envelope . . . . . . . . . . . . . 104
C.2. C.2 Byte String Wrappers . . . . . . . . . . . . . . . . 104 C.2. C.2 Byte String Wrappers . . . . . . . . . . . . . . . . 105
D. Implementation Conformance Matrix . . . . . . . . . . . . . . 105 D. Implementation Conformance Matrix . . . . . . . . . . . . . . 106
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109
1. Introduction 1. Introduction
A firmware update mechanism is an essential security feature for IoT A firmware update mechanism is an essential security feature for IoT
devices to deal with vulnerabilities. While the transport of devices to deal with vulnerabilities. While the transport of
firmware images to the devices themselves is important there are firmware images to the devices themselves is important there are
already various techniques available. Equally important is the already various techniques available. Equally important is the
inclusion of metadata about the conveyed firmware image (in the form inclusion of metadata about the conveyed firmware image (in the form
of a manifest) and the use of a security wrapper to provide end-to- of a manifest) and the use of a security wrapper to provide end-to-
end security protection to detect modifications and (optionally) to end security protection to detect modifications and (optionally) to
skipping to change at page 16, line 46 skipping to change at page 16, line 46
- Dependency not available. - Dependency not available.
- Application crashed when executed. - Application crashed when executed.
- Watchdog timeout occurred. - Watchdog timeout occurred.
- Dependency or Payload verification failed. - Dependency or Payload verification failed.
- Missing component from a set. - Missing component from a set.
- Required parameter not supplied.
These failure reasons MAY be combined with retry mechanisms prior to These failure reasons MAY be combined with retry mechanisms prior to
marking a manifest as invalid. marking a manifest as invalid.
Following these initial tests, the interpreter clears all parameter Following these initial tests, the interpreter clears all parameter
storage. This ensures that the interpreter begins without any leaked storage. This ensures that the interpreter begins without any leaked
data. data.
6.2. Required Checks 6.2. Required Checks
The RECOMMENDED process is to verify the signature of the manifest The RECOMMENDED process is to verify the signature of the manifest
skipping to change at page 17, line 35 skipping to change at page 17, line 39
Once a valid, authentic manifest has been selected, the interpreter Once a valid, authentic manifest has been selected, the interpreter
MUST examine the component list and verify that its maximum number of MUST examine the component list and verify that its maximum number of
components is not exceeded and that each listed component ID is components is not exceeded and that each listed component ID is
supported. supported.
For each listed component, the interpreter MUST provide storage for For each listed component, the interpreter MUST provide storage for
the supported parameters. If the interpreter does not have the supported parameters. If the interpreter does not have
sufficient temporary storage to process the parameters for all sufficient temporary storage to process the parameters for all
components, it MAY process components serially for each command components, it MAY process components serially for each command
sequence. See Section 6.5 for more details. sequence. See Section 6.6 for more details.
The interpreter SHOULD check that the common section contains at The interpreter SHOULD check that the common section contains at
least one vendor ID check and at least one class ID check. least one vendor ID check and at least one class ID check.
If the manifest contains more than one component, each command If the manifest contains more than one component, each command
sequence MUST begin with a Set Current Component command. sequence MUST begin with a Set Current Component command.
If a dependency is specified, then the interpreter MUST perform the If a dependency is specified, then the interpreter MUST perform the
following checks: following checks:
skipping to change at page 21, line 23 skipping to change at page 21, line 27
| Swap | swap(current, current.params[src-component]) | | Swap | swap(current, current.params[src-component]) |
| | | | | |
| Wait For Event | until event(arg), wait | | Wait For Event | until event(arg), wait |
| | | | | |
| Run Sequence | exec(arg) | | Run Sequence | exec(arg) |
| | | | | |
| Run with | run(current, arg) | | Run with | run(current, arg) |
| Arguments | | | Arguments | |
+-------------------+-----------------------------------------------+ +-------------------+-----------------------------------------------+
6.5. Serialized Processing Interpreter 6.5. Special Cases of Component Index and Dependency Index
The interpreter MUST support a special case of Component Index if
more than two or more components are supported: setting Component
Index to True is allowed. When a command is invoked and the
Component Index is True, the command MUST be invoked once for each
Component, in the order listed in the array of Component Identifiers.
The interpreter MUST support a special case of Dependency Index when
two or more dependencies are supported. When a command is invoked
and the Dependency Index is True, the command MUST be invoked once
for each Dependency, in the order listed in the array of
Dependencies.
This is represented by the following pseudocode.
if iscomponent(current):
if current is true:
cmd(component) for-each component in components
else:
cmd(current)
else:
if current is true:
cmd(dependency) for-each dependency in dependencies
else:
cmd(current)
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. They are only invoked with integer indices.
The interpreter loops over the whole sequence, setting the Component
Index or Dependency Index to each possible index in turn.
6.6. Serialized Processing Interpreter
In highly constrained devices, where storage for parameters is In highly constrained devices, where storage for parameters is
limited, the manifest processor MAY handle one component at a time, limited, the manifest processor MAY handle one component at a time,
traversing the manifest tree once for each listed component. In this traversing the manifest tree once for each listed component. In this
mode, the interpreter ignores any commands executed while the mode, the interpreter ignores any commands executed while the
component index is not the current component. This reduces the component index is not the current component. This reduces the
overall volatile storage required to process the update so that the overall volatile storage required to process the update so that the
only limit on number of components is the size of the manifest. only limit on number of components is the size of the manifest.
However, this approach requires additional processing power. However, this approach requires additional processing power.
In order to operate in this mode, the manifest processor loops on In order to operate in this mode, the manifest processor loops on
each section for every supported component, simply ignoring commands each section for every supported component, simply ignoring commands
when the current component is not selected. when the current component is not selected.
6.6. Parallel Processing Interpreter 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.
6.7. Parallel Processing Interpreter
Advanced Recipients MAY make use of the Strict Order parameter and Advanced Recipients MAY make use of the Strict Order parameter and
enable parallel processing of some Command Sequences, or it may enable parallel processing of some Command Sequences, or it may
reorder some Command Sequences. To perform parallel processing, once reorder some Command Sequences. To perform parallel processing, once
the Strict Order parameter is set to False, the Recipient may fork a the Strict Order parameter is set to False, the Recipient may fork a
process for each command until the Strict Order parameter is returned process for each command until the Strict Order parameter is returned
to True or the Command Sequence ends. Then, it joins all forked to True or the Command Sequence ends. Then, it joins all forked
processes before continuing processing of commands. To perform out- processes before continuing processing of commands. To perform out-
of-order processing, a similar approach is used, except the Recipient of-order processing, a similar approach is used, except the Recipient
consumes all commands after the Strict Order parameter is set to consumes all commands after the Strict Order parameter is set to
skipping to change at page 22, line 31 skipping to change at page 23, line 25
each sequence MUST begin with a Set Component Index directive. The each sequence MUST begin with a Set Component Index directive. The
interpreter MUST track each Set Component Index directive, and cause interpreter MUST track each Set Component Index directive, and cause
an Abort if more than one Set Component Index directive targets the an Abort if more than one Set Component Index directive targets the
same Component Index. When Strict Order = False, each suit- same Component Index. When Strict Order = False, each suit-
directive-run-sequence MUST begin with a Set Component Index directive-run-sequence MUST begin with a Set Component Index
directive. Any further Set Component Index directives MUST cause an directive. Any further Set Component Index directives MUST cause an
Abort. This allows the interpreter that forks suit-directive-run- Abort. This allows the interpreter that forks suit-directive-run-
sequence processes to check that the first element is correct, then sequence processes to check that the first element is correct, then
fork a process to handle the remainder of the sequence. fork a process to handle the remainder of the sequence.
6.7. Processing Dependencies 6.8. Processing Dependencies
As described in Section 6.2, each manifest must invoke each of its As described in Section 6.2, each manifest must invoke each of its
dependencies sections from the corresponding section of the dependencies sections from the corresponding section of the
dependent. Any changes made to parameters by the dependency persist dependent. Any changes made to parameters by the dependency persist
in the dependent. in the dependent.
When a Process Dependency command is encountered, the interpreter When a Process Dependency command is encountered, the interpreter
loads the dependency identified by the Current Dependency Index. The loads the dependency identified by the Current Dependency Index. The
interpreter first executes the common-sequence section of the interpreter first executes the common-sequence section of the
identified dependency, then it executes the section of the dependency identified dependency, then it executes the section of the dependency
that corresponds to the currently executing section of the dependent. that corresponds to the currently executing section of the dependent.
The Manifest Processor MUST also support a Dependency Index of True,
which applies to every dependency, as described in Section 6.5
The interpreter also performs the checks described in Section 6.2 to The interpreter also performs the checks described in Section 6.2 to
ensure that the dependent is processing the dependency correctly. ensure that the dependent is processing the dependency correctly.
6.8. Multiple Manifest Processors 6.9. Multiple Manifest Processors
When a system has multiple security domains they MAY require When a system has multiple security domains they MAY require
independent verification of authenticity or security policies. independent verification of authenticity or security policies.
Security domains may be divided by separation technology such as Arm Security domains may be divided by separation technology such as Arm
TrustZone, or Intel SGX. Security domains may also be divided into TrustZone, or Intel SGX. Security domains may also be divided into
separate processors and memory spaces, with a communication interface separate processors and memory spaces, with a communication interface
between them. between them.
For example, an application processor may have an attached For example, an application processor may have an attached
communications module that contains a processor. The communications communications module that contains a processor. The communications
skipping to change at page 24, line 7 skipping to change at page 25, line 5
calculating cryptographic values and compiling desired system state calculating cryptographic values and compiling desired system state
into a sequence of operations required to achieve that state. The into a sequence of operations required to achieve that state. The
process of constructing COSE structures and the calculation of process of constructing COSE structures and the calculation of
cryptographic values is covered in [RFC8152]. cryptographic values is covered in [RFC8152].
Compiling desired system state into a sequence of operations can be Compiling desired system state into a sequence of operations can be
accomplished in many ways. Several templates are provided below to accomplished in many ways. Several templates are provided below to
cover common use-cases. These templates can be combined to produce cover common use-cases. These templates can be combined to produce
more complex behavior. more complex behavior.
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, Set Current NOTE: On systems that support only a single component, Set Current
Component has no effect and can be omitted. Component has no effect and can be omitted.
NOTE: *A digest MUST always be set using Override Parameters, since NOTE: *A digest MUST always be set using Override Parameters, since
this prevents a less-privileged dependent from replacing the digest.* this prevents a less-privileged dependent from replacing the digest.*
7.1. Compatibility Check Template 7.1. Compatibility Check Template
The compatibility check ensures that Recipients only install The compatibility check ensures that Recipients only install
compatible images. In this template all information is contained in compatible images. In this template all information is contained in
skipping to change at page 36, line 23 skipping to change at page 37, line 23
component hierarchy. This element is OPTIONAL. component hierarchy. This element is OPTIONAL.
A dependency prefix can be used with a component identifier. This A dependency prefix can be used with a component identifier. This
allows complex systems to understand where dependencies need to be allows complex systems to understand where dependencies need to be
applied. The dependency prefix can be used in one of two ways. The applied. The dependency prefix can be used in one of two ways. The
first simply prepends the prefix to all Component Identifiers in the first simply prepends the prefix to all Component Identifiers in the
dependency. dependency.
A dependency prefix can also be used to indicate when a dependency A dependency prefix can also be used to indicate when a dependency
manifest needs to be processed by a secondary manifest processor, as manifest needs to be processed by a secondary manifest processor, as
described in Section 6.8. described in Section 6.9.
8.7.2.2. SUIT_Component_Identifier 8.7.2.2. SUIT_Component_Identifier
A component is a unit of code or data that can be targeted by an A component is a unit of code or data that can be targeted by an
update. To facilitate composite devices, components are identified update. To facilitate composite devices, components are identified
by a list of CBOR byte strings, which allows construction of by a list of CBOR byte strings, which allows construction of
hierarchical component structures. A dependency MAY declare a prefix hierarchical component structures. A dependency MAY declare a prefix
to the components defined in the dependency manifest. Components are to the components defined in the dependency manifest. Components are
identified by Component Identifiers, i.e. arrays of binary strings, identified by Component Identifiers, i.e. arrays of binary strings,
but referenced in commands but referenced in commands
skipping to change at page 39, line 7 skipping to change at page 40, line 7
To facilitate optional conditions, a special directive, To facilitate optional conditions, a special directive,
Section 8.7.7.4, is provided. It runs several new lists of Section 8.7.7.4, is provided. It runs several new lists of
conditions/directives, one after another, that are contained as an conditions/directives, one after another, that are contained as an
argument to the directive. By default, it assumes that a failure of argument to the directive. By default, it assumes that a failure of
a condition should not indicate a failure of the update/boot, but a a condition should not indicate a failure of the update/boot, but a
parameter is provided to override this behavior. See parameter is provided to override this behavior. See
Section 8.7.5.22. Section 8.7.5.22.
8.7.4. Reporting Policy 8.7.4. Reporting Policy
TODO: Records, bitfield
To facilitate construction of Reports that describe the success, or To facilitate construction of Reports that describe the success, or
failure of a given Procedure, each command is given a Reporting failure of a given Procedure, each command is given a Reporting
Policy. This is an integer bitfield that follows the command and Policy. This is an integer bitfield that follows the command and
indicates what the Recipient should do with the Record of executing indicates what the Recipient should do with the Record of executing
the command. The options are summarized in the table below. the command. The options are summarized in the table below.
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Policy | Description | | Policy | Description |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| suit-send-record-on-success | Record when the command succeeds | | suit-send-record-on-success | Record when the command succeeds |
skipping to change at page 39, line 31 skipping to change at page 40, line 29
| | | | | |
| suit-send-sysinfo-success | Add system information when the | | suit-send-sysinfo-success | Add system information when the |
| | command succeeds | | | command succeeds |
| | | | | |
| suit-send-sysinfo-failure | Add system information when the | | suit-send-sysinfo-failure | Add system information when the |
| | command fails | | | command fails |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
Any or all of these policies may be enabled at once. Any or all of these policies may be enabled at once.
If the component index is set to True 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. If the dependency index is set to True 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.
SUIT does NOT REQUIRE a particular format of Records or Reports. SUIT does NOT REQUIRE a particular format of Records or Reports.
SUIT only defines hints to the Reporting engine for which Records it SUIT only defines hints to the Reporting engine for which Records it
should aggregate into the Report. should aggregate into the Report.
For example, a system using DICE certificates MAY use instances of
suit-send-sysinfo-success to construct its certificates.
An OPTIONAL Record format, SUIT_Record is defined in [full-cddl]. It An OPTIONAL Record format, SUIT_Record is defined in [full-cddl]. It
is encoded as a map, with the following elements. is encoded as a map, with the following elements.
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Element | Description | | Element | Description |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| suit-record-success | The boolean or integer success | | suit-record-success | The boolean or integer success |
| | or failure code of the command. | | | or failure code of the command. |
| | | | | |
| suit-record-component-id | The current component when the | | suit-record-component-id | The current component when the |
skipping to change at page 49, line 24 skipping to change at page 50, line 24
that have a sensitivity to order of updates to choose the order in 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 which they are executed. It also allows for more advanced systems to
parallelize their handling of updates. Strict Order defaults to parallelize their handling of updates. Strict Order defaults to
True. It MAY be set to False when the order of operations does not 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 matter. When arriving at the end of a command sequence, ALL commands
MUST have completed, regardless of the state of MUST have completed, regardless of the state of
SUIT_Parameter_Strict_Order. If SUIT_Parameter_Strict_Order is SUIT_Parameter_Strict_Order. If SUIT_Parameter_Strict_Order is
returned to True, ALL preceding commands MUST complete before the returned to True, ALL preceding commands MUST complete before the
next command is executed. next command is executed.
See Section 6.6 for behavioral description of Strict Order. See Section 6.7 for behavioral description of Strict Order.
8.7.5.22. suit-parameter-soft-failure 8.7.5.22. suit-parameter-soft-failure
When executing a command sequence inside Section 8.7.7.4 or When executing a command sequence inside Section 8.7.7.4 or
Section 8.7.7.13 and a condition failure occurs, the manifest Section 8.7.7.13 and a condition failure occurs, the manifest
processor aborts the sequence. For suit-directive-try-each, if Soft processor aborts the sequence. For suit-directive-try-each, if Soft
Failure is True, the next sequence in Try Each is invoked, otherwise Failure is True, the next sequence in Try Each is invoked, otherwise
suit-directive-try-each fails with the condition failure code. In suit-directive-try-each fails with the condition failure code. In
suit-directive-run-sequence, if Soft Failure is True the suit- suit-directive-run-sequence, if Soft Failure is True the suit-
directive-run-sequence simply halts with no side-effects and the directive-run-sequence simply halts with no side-effects and the
skipping to change at page 56, line 14 skipping to change at page 57, line 14
When a Recipient executes a Directive, it MUST report a result code. When a Recipient executes a Directive, it MUST report a result code.
If the Directive reports failure, then the current Command Sequence If the Directive reports failure, then the current Command Sequence
MUST terminate. MUST terminate.
8.7.7.1. suit-directive-set-component-index 8.7.7.1. suit-directive-set-component-index
Set Component Index defines the component to which successive Set Component Index defines the component to which successive
directives and conditions will apply. The supplied argument MUST be directives and conditions will apply. The supplied argument MUST be
either a boolean or an unsigned integer index into suit-components. either a boolean or an unsigned integer index into suit-components.
If the following directives apply to ALL components, then the boolean If the following commands apply to ALL components, then the boolean
value "True" is used instead of an index. If the following value "True" is used instead of an index. If the following commands
directives apply to NO components, then the boolean value "False" is apply to NO components, then the boolean value "False" is used. When
used. When suit-directive-set-dependency-index is used, suit- suit-directive-set-dependency-index is used, suit-directive-set-
directive-set-component-index = False is implied. When suit- component-index = False is implied. When suit-directive-set-
directive-set-component-index is used, suit-directive-set-dependency- component-index is used, suit-directive-set-dependency-index = False
index = False is implied. is implied.
If component index is set to True when a command is invoked, then the
command applies to all components, in the order they appear in suit-
common-components. When the Manifest Processor invokes a command
while the component index is set to True, it must execute the command
once for each possible component index, ensuring that the command
receives the parameters corresponding to that component index.
8.7.7.2. suit-directive-set-dependency-index 8.7.7.2. suit-directive-set-dependency-index
Set Dependency Index defines the manifest to which successive Set Dependency Index defines the manifest to which successive
directives and conditions will apply. The supplied argument MUST be directives and conditions will apply. The supplied argument MUST be
either a boolean or an unsigned integer index into the dependencies. either a boolean or an unsigned integer index into the dependencies.
If the following directives apply to ALL dependencies, then the If the following directives apply to ALL dependencies, then the
boolean value "True" is used instead of an index. If the following boolean value "True" is used instead of an index. If the following
directives apply to NO dependencies, then the boolean value "False" directives apply to NO dependencies, then the boolean value "False"
is used. When suit-directive-set-component-index is used, suit- is used. When suit-directive-set-component-index is used, suit-
directive-set-dependency-index = False is implied. When suit- directive-set-dependency-index = False is implied. When suit-
directive-set-dependency-index is used, suit-directive-set-component- directive-set-dependency-index is used, suit-directive-set-component-
index = False is implied. 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, it must execute
the command once for each possible dependency index, ensuring that
the command receives the parameters corresponding to that dependency
index.
Typical operations that require suit-directive-set-dependency-index Typical operations that require suit-directive-set-dependency-index
include setting a source URI or Encryption Information, invoking include setting a source URI or Encryption Information, invoking
"Fetch," or invoking "Process Dependency" for an individual "Fetch," or invoking "Process Dependency" for an individual
dependency. dependency.
8.7.7.3. suit-directive-abort 8.7.7.3. suit-directive-abort
Unconditionally fail. This operation is typically used in Unconditionally fail. This operation is typically used in
conjunction with suit-directive-try-each. conjunction with suit-directive-try-each.
 End of changes. 23 change blocks. 
88 lines changed or deleted 164 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/