draft-ietf-suit-manifest-06.txt   draft-ietf-suit-manifest-07.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: December 4, 2020 H. Birkholz Expires: December 11, 2020 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
K. Zandberg K. Zandberg
Inria Inria
June 02, 2020 June 09, 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-06 draft-ietf-suit-manifest-07
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 December 4, 2020. This Internet-Draft will expire on December 11, 2020.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. How to use this Document . . . . . . . . . . . . . . . . . . 7 3. How to use this Document . . . . . . . . . . . . . . . . . . 6
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IoT Firmware Update Constraints . . . . . . . . . . . . . 8 4.1. IoT Firmware Update Constraints . . . . . . . . . . . . . 7
4.2. Update Workflow Model . . . . . . . . . . . . . . . . . . 8 4.2. Update Workflow Model . . . . . . . . . . . . . . . . . . 8
5. Severed Fields . . . . . . . . . . . . . . . . . . . . . . . 9 5. Severed Fields . . . . . . . . . . . . . . . . . . . . . . . 9
6. Interpreter Behavior . . . . . . . . . . . . . . . . . . . . 10 6. Interpreter Behavior . . . . . . . . . . . . . . . . . . . . 10
6.1. Interpreter Setup . . . . . . . . . . . . . . . . . . . . 10 6.1. Interpreter Setup . . . . . . . . . . . . . . . . . . . . 10
6.2. Required Checks . . . . . . . . . . . . . . . . . . . . . 11 6.2. Required Checks . . . . . . . . . . . . . . . . . . . . . 11
6.3. Interpreter Fundamental Properties . . . . . . . . . . . 12 6.3. Interpreter Fundamental Properties . . . . . . . . . . . 12
6.4. Abstract Machine Description . . . . . . . . . . . . . . 13 6.4. Abstract Machine Description . . . . . . . . . . . . . . 12
6.5. Serialized Processing Interpreter . . . . . . . . . . . . 14 6.5. Serialized Processing Interpreter . . . . . . . . . . . . 14
6.6. Parallel Processing Interpreter . . . . . . . . . . . . . 15 6.6. Parallel Processing Interpreter . . . . . . . . . . . . . 14
6.7. Processing Dependencies . . . . . . . . . . . . . . . . . 15 6.7. Processing Dependencies . . . . . . . . . . . . . . . . . 15
7. Creating Manifests . . . . . . . . . . . . . . . . . . . . . 16 7. Creating Manifests . . . . . . . . . . . . . . . . . . . . . 15
7.1. Compatibility Check Template . . . . . . . . . . . . . . 16 7.1. Compatibility Check Template . . . . . . . . . . . . . . 16
7.2. Secure Boot Template . . . . . . . . . . . . . . . . . . 16 7.2. Secure Boot Template . . . . . . . . . . . . . . . . . . 16
7.3. Firmware Download Template . . . . . . . . . . . . . . . 17 7.3. Firmware Download Template . . . . . . . . . . . . . . . 16
7.4. Load from External Storage Template . . . . . . . . . . . 17 7.4. Load from External Storage Template . . . . . . . . . . . 17
7.5. Load & Decompress from External Storage Template . . . . 18 7.5. Load & Decompress from External Storage Template . . . . 17
7.6. Dependency Template . . . . . . . . . . . . . . . . . . . 18 7.6. Dependency Template . . . . . . . . . . . . . . . . . . . 18
8. Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Authenticated Manifests . . . . . . . . . . . . . . . . . 19 8.1. Authenticated Manifests . . . . . . . . . . . . . . . . . 19
8.2. Encrypted Manifests . . . . . . . . . . . . . . . . . . . 20 8.2. Encrypted Manifests . . . . . . . . . . . . . . . . . . . 20
8.3. Delegation Info . . . . . . . . . . . . . . . . . . . . . 20 8.3. Delegation Info . . . . . . . . . . . . . . . . . . . . . 20
8.4. Severable Fields . . . . . . . . . . . . . . . . . . . . 20 8.4. Severable Fields . . . . . . . . . . . . . . . . . . . . 20
8.5. Human-Readable Text . . . . . . . . . . . . . . . . . . . 20 8.5. Human-Readable Text . . . . . . . . . . . . . . . . . . . 20
8.6. COSWID . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.6. COSWID . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.7. Encoding Considerations . . . . . . . . . . . . . . . . . 21 8.7. Encoding Considerations . . . . . . . . . . . . . . . . . 21
8.8. SUIT_Envelope CDDL . . . . . . . . . . . . . . . . . . . 22 9. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. suit-manifest-version . . . . . . . . . . . . . . . . . . 22
9.1. suit-manifest-version . . . . . . . . . . . . . . . . . . 24 9.2. suit-manifest-sequence-number . . . . . . . . . . . . . . 23
9.2. suit-manifest-sequence-number . . . . . . . . . . . . . . 24 9.3. suit-reference-uri . . . . . . . . . . . . . . . . . . . 23
9.3. suit-reference-uri . . . . . . . . . . . . . . . . . . . 24 9.4. suit-text . . . . . . . . . . . . . . . . . . . . . . . . 23
9.4. suit-text . . . . . . . . . . . . . . . . . . . . . . . . 25 9.5. suit-coswid . . . . . . . . . . . . . . . . . . . . . . . 23
9.5. suit-coswid . . . . . . . . . . . . . . . . . . . . . . . 25 9.6. Dependencies . . . . . . . . . . . . . . . . . . . . . . 23
9.6. Dependencies . . . . . . . . . . . . . . . . . . . . . . 25 9.7. SUIT_Component_Reference . . . . . . . . . . . . . . . . 24
9.7. SUIT_Component_Reference . . . . . . . . . . . . . . . . 25 9.8. SUIT_Command_Sequence . . . . . . . . . . . . . . . . . . 24
9.8. SUIT_Command_Sequence . . . . . . . . . . . . . . . . . . 26 9.8.1. suit-common . . . . . . . . . . . . . . . . . . . . . 26
9.8.1. suit-common . . . . . . . . . . . . . . . . . . . . . 28 9.8.2. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 26
9.8.2. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 29 9.8.3. SUIT_Condition . . . . . . . . . . . . . . . . . . . 31
9.8.3. SUIT_Condition . . . . . . . . . . . . . . . . . . . 34 9.8.4. SUIT_Directive . . . . . . . . . . . . . . . . . . . 36
9.8.4. SUIT_Directive . . . . . . . . . . . . . . . . . . . 40 10. Access Control Lists . . . . . . . . . . . . . . . . . . . . 42
9.9. SUIT_Manifest CDDL . . . . . . . . . . . . . . . . . . . 50 11. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 43
10. Access Control Lists . . . . . . . . . . . . . . . . . . . . 50 12. Creating Conditional Sequences . . . . . . . . . . . . . . . 43
11. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 51 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
12. Creating Conditional Sequences . . . . . . . . . . . . . . . 52 13.1. SUIT Directives . . . . . . . . . . . . . . . . . . . . 45
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 13.2. SUIT Conditions . . . . . . . . . . . . . . . . . . . . 46
13.1. SUIT Directives . . . . . . . . . . . . . . . . . . . . 54 13.3. SUIT Parameters . . . . . . . . . . . . . . . . . . . . 46
13.2. SUIT Conditions . . . . . . . . . . . . . . . . . . . . 55 13.4. SUIT Text Values . . . . . . . . . . . . . . . . . . . . 48
13.3. SUIT Parameters . . . . . . . . . . . . . . . . . . . . 56 13.5. SUIT Algorithm Identifiers . . . . . . . . . . . . . . . 48
13.4. SUIT Text Values . . . . . . . . . . . . . . . . . . . . 58 13.5.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 48
13.5. SUIT Algorithm Identifiers . . . . . . . . . . . . . . . 58 13.5.2. Unpack Algorithms . . . . . . . . . . . . . . . . . 49
14. Security Considerations . . . . . . . . . . . . . . . . . . . 58 14. Security Considerations . . . . . . . . . . . . . . . . . . . 49
15. Mailing List Information . . . . . . . . . . . . . . . . . . 58 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 16.1. Normative References . . . . . . . . . . . . . . . . . . 50
17.1. Normative References . . . . . . . . . . . . . . . . . . 59 16.2. Informative References . . . . . . . . . . . . . . . . . 51
17.2. Informative References . . . . . . . . . . . . . . . . . 60 A. Full CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . 53
17.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 61 B. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A. Full CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . 62 B.1. Example 0: Secure Boot . . . . . . . . . . . . . . . . . 61
B. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
B.1. Example 0: Secure Boot . . . . . . . . . . . . . . . . . 70
B.2. Example 1: Simultaneous Download and Installation of B.2. Example 1: Simultaneous Download and Installation of
Payload . . . . . . . . . . . . . . . . . . . . . . . . . 72 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.3. Example 2: Simultaneous Download, Installation, and B.3. Example 2: Simultaneous Download, Installation, and
Secure Boot . . . . . . . . . . . . . . . . . . . . . . . 75 Secure Boot . . . . . . . . . . . . . . . . . . . . . . . 66
B.4. Example 3: Load from External Storage . . . . . . . . . . 77 B.4. Example 3: Load from External Storage . . . . . . . . . . 68
B.5. Example 4: Load and Decompress from External Storage . . 80 B.5. Example 4: Load and Decompress from External Storage . . 71
B.6. Example 5: Compatibility Test, Download, Installation, B.6. Example 5: Compatibility Test, Download, Installation,
and Secure Boot . . . . . . . . . . . . . . . . . . . . . 82 and Secure Boot . . . . . . . . . . . . . . . . . . . . . 73
B.7. Example 6: Two Images . . . . . . . . . . . . . . . . . . 76
B.7. Example 6: Two Images . . . . . . . . . . . . . . . . . . 85 C. Design Rational . . . . . . . . . . . . . . . . . . . . . . . 79
C. Design Rational . . . . . . . . . . . . . . . . . . . . . . . 88 D. Implementation Conformance Matrix . . . . . . . . . . . . . . 80
D. Implementation Confirmance Matrix . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93
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 22, line 13 skipping to change at page 22, line 13
detection of several common software errors that are caused by detection of several common software errors that are caused by
uninitialised variables. Positive numbers in enumerations are uninitialised variables. Positive numbers in enumerations are
reserved for IANA registration. Negative numbers are used to reserved for IANA registration. Negative numbers are used to
identify application-specific implementations. identify application-specific implementations.
All elements of the envelope must be wrapped in a bstr to minimize All elements of the envelope must be wrapped in a bstr to minimize
the complexity of the code that evaluates the cryptographic integrity the complexity of the code that evaluates the cryptographic integrity
of the element and to ensure correct serialization for integrity and of the element and to ensure correct serialization for integrity and
authenticity checks. authenticity checks.
8.8. SUIT_Envelope CDDL
CDDL names are hyphenated and CDDL structures follow the convention
adopted in COSE [RFC8152]: SUIT_Structure_Name.
The CDDL that describes the envelope is below.
SUIT_Envelope = {
suit-delegation => bstr .cbor SUIT_Delegation
suit-authentication-wrapper
=> bstr .cbor SUIT_Authentication_Wrapper / nil,
$$SUIT_Manifest_Wrapped,
* $$SUIT_Severed_Fields,
}
SUIT_Delegation = [ + [ + CWT ] ]
SUIT_Authentication_Wrapper = [ + bstr .cbor SUIT_Authentication_Block ]
SUIT_Authentication_Block /= COSE_Mac_Tagged
SUIT_Authentication_Block /= COSE_Sign_Tagged
SUIT_Authentication_Block /= COSE_Mac0_Tagged
SUIT_Authentication_Block /= COSE_Sign1_Tagged
$$SUIT_Manifest_Wrapped //= (suit-manifest => bstr .cbor SUIT_Manifest)
$$SUIT_Manifest_Wrapped //= (
suit-manifest-encryption-info => bstr .cbor SUIT_Encryption_Wrapper,
suit-manifest-encrypted => bstr
)
SUIT_Encryption_Wrapper = COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged
$$SUIT_Severed_Fields //= ( suit-dependency-resolution =>
bstr .cbor SUIT_Command_Sequence)
$$SUIT_Severed_Fields //= (suit-payload-fetch =>
bstr .cbor SUIT_Command_Sequence)
$$SUIT_Severed_Fields //= (suit-install =>
bstr .cbor SUIT_Command_Sequence)
$$SUIT_Severed_Fields //= (suit-text =>
bstr .cbor SUIT_Text_Map)
$$SUIT_Severed_Fields //= (suit-coswid =>
bstr .cbor concise-software-identity)
9. Manifest 9. Manifest
The manifest contains: The manifest contains:
- a version number (see Section 9.1) - a version number (see Section 9.1)
- a sequence number (see Section 9.2) - a sequence number (see Section 9.2)
- a common structure with information that is shared between command - a common structure with information that is shared between command
sequences (see Section 9.8.1) sequences (see Section 9.8.1)
skipping to change at page 25, line 22 skipping to change at page 23, line 40
suit-coswid is a digest that uniquely identifies the content of the suit-coswid is a digest that uniquely identifies the content of the
concise-software-identifier that is packaged in the SUIT_Envelope. concise-software-identifier that is packaged in the SUIT_Envelope.
suit-coswid is OPTIONAL to implement. suit-coswid is OPTIONAL to implement.
9.6. Dependencies 9.6. Dependencies
SUIT_Dependency specifies a manifest that describes a dependency of SUIT_Dependency specifies a manifest that describes a dependency of
the current manifest. the current manifest.
The following CDDL describes the SUIT_Dependency structure.
SUIT_Dependency = {
suit-dependency-digest => SUIT_Digest,
? suit-dependency-prefix => SUIT_Component_Identifier,
}
The suit-dependency-digest specifies the dependency manifest uniquely The suit-dependency-digest specifies the dependency manifest uniquely
by identifying a particular Manifest structure. The digest is by identifying a particular Manifest structure. The digest is
calculated over the Manifest structure instead of the COSE calculated over the Manifest structure instead of the COSE
Sig_structure or Mac_structure. This means that a digest may need to Sig_structure or Mac_structure. This means that a digest may need to
be calculated more than once, however this is necessary to ensure be calculated more than once, however this is necessary to ensure
that removing a signature from a manifest does not break dependencies that removing a signature from a manifest does not break dependencies
due to missing signature elements. This is also necessary to support due to missing signature elements. This is also necessary to support
the trusted intermediary use case, where an intermediary re-signs the the trusted intermediary use case, where an intermediary re-signs the
Manifest, removing the original signature, potentially with a Manifest, removing the original signature, potentially with a
different algorithm, or trading COSE_Sign for COSE_Mac. different algorithm, or trading COSE_Sign for COSE_Mac.
skipping to change at page 26, line 6 skipping to change at page 24, line 17
without those devices needing consistent component hierarchy. This without those devices needing consistent component hierarchy. This
element is OPTIONAL. element is OPTIONAL.
9.7. SUIT_Component_Reference 9.7. SUIT_Component_Reference
The SUIT_Component_Reference describes an image that is defined by The SUIT_Component_Reference describes an image that is defined by
another manifest. This is useful for overriding the behavior of another manifest. This is useful for overriding the behavior of
another manifest, for example by directing the recipient to look at a another manifest, for example by directing the recipient to look at a
different URI for the image or by changing the expected format, such different URI for the image or by changing the expected format, such
as when a gateway performs decryption on behalf of a constrained as when a gateway performs decryption on behalf of a constrained
device. The following CDDL describes the SUIT_Component_Reference. device.
SUIT_Component_Reference = {
suit-component-identifier => SUIT_Component_Identifier,
suit-component-dependency-index => uint
}
9.8. SUIT_Command_Sequence 9.8. SUIT_Command_Sequence
A SUIT_Command_Sequence defines a series of actions that the A SUIT_Command_Sequence defines a series of actions that the
Recipient MUST take to accomplish a particular goal. These goals are Recipient MUST take to accomplish a particular goal. These goals are
defined in the manifest and include: defined in the manifest and include:
1. Dependency Resolution: suit-dependency-resolution is a 1. Dependency Resolution: suit-dependency-resolution is a
SUIT_Command_Sequence to execute in order to perform dependency SUIT_Command_Sequence to execute in order to perform dependency
resolution. Typical actions include configuring URIs of resolution. Typical actions include configuring URIs of
skipping to change at page 27, line 24 skipping to change at page 25, line 30
Each of these follows exactly the same structure to ensure that the Each of these follows exactly the same structure to ensure that the
parser is as simple as possible. parser is as simple as possible.
Lists of commands are constructed from two kinds of element: Lists of commands are constructed from two kinds of element:
1. Conditions that MUST be true-any failure is treated as a failure 1. Conditions that MUST be true-any failure is treated as a failure
of the update/load/boot of the update/load/boot
2. Directives that MUST be executed. 2. Directives that MUST be executed.
The lists of commands are logically structured into sequences of zero Each condition is a command code identifier, followed by Nil.
or more conditions followed by zero or more directives. The
*logical* structure is described by the following CDDL:
Command_Sequence = {
conditions => [ * Condition],
directives => [ * Directive]
}
This introduces significant complexity in the parser, however, so the
structure is flattened to make parsing simpler:
SUIT_Command_Sequence = [ + (SUIT_Condition/SUIT_Directive) ]
Each condition is a command code identifier, followed by Nil. Each Each directive is composed of:
directive is composed of:
1. A command code identifier 1. A command code identifier
2. An argument block or Nil 2. An argument block or Nil
Argument blocks are defined for each type of directive. Argument blocks are defined for each type of directive.
Many conditions and directives apply to a given component, and these Many conditions and directives apply to a given component, and these
generally grouped together. Therefore, a special command to set the generally grouped together. Therefore, a special command to set the
current component index is provided with a matching command to set current component index is provided with a matching command to set
skipping to change at page 31, line 21 skipping to change at page 29, line 7
The size of the firmware image in bytes. The size of the firmware image in bytes.
9.8.2.5. suit-parameter-use-before 9.8.2.5. suit-parameter-use-before
An expire date for the use of the manifest encoded as a POSIX An expire date for the use of the manifest encoded as a POSIX
timestamp. timestamp.
9.8.2.6. suit-parameter-component-offset 9.8.2.6. suit-parameter-component-offset
Offset of the component This parameter sets the offset in a component.
9.8.2.7. suit-parameter-encryption-info 9.8.2.7. suit-parameter-encryption-info
Encryption Info defines the mechanism that Fetch or Copy should use Encryption Info defines the mechanism that Fetch or Copy should use
to decrypt the data they transfer. SUIT_Parameter_Encryption_Info is to decrypt the data they transfer. SUIT_Parameter_Encryption_Info is
encoded as a COSE_Encrypt_Tagged or a COSE_Encrypt0_Tagged, wrapped encoded as a COSE_Encrypt_Tagged or a COSE_Encrypt0_Tagged, wrapped
in a bstr. in a bstr.
9.8.2.8. suit-parameter-compression-info 9.8.2.8. suit-parameter-compression-info
skipping to change at page 32, line 7 skipping to change at page 29, line 39
interpret a packed format. This document defines the use of the interpret a packed format. This document defines the use of the
following binary encodings: Intel HEX [HEX], Motorola S-record following binary encodings: Intel HEX [HEX], Motorola S-record
[SREC], Executable and Linkable Format (ELF) [ELF], and Common Object [SREC], Executable and Linkable Format (ELF) [ELF], and Common Object
File Format (COFF) [COFF]. File Format (COFF) [COFF].
Additional packing formats can be registered through the IANA- Additional packing formats can be registered through the IANA-
maintained registry. maintained registry.
9.8.2.10. suit-parameter-uri 9.8.2.10. suit-parameter-uri
A URI from which to fetch a resource A URI from which to fetch a resource.
9.8.2.11. suit-parameter-source-component 9.8.2.11. suit-parameter-source-component
A Component Index This parameter sets the source component.
9.8.2.12. suit-parameter-run-args 9.8.2.12. suit-parameter-run-args
An encoded set of arguments for Run This parameter contains an encoded set of arguments for Run.
9.8.2.13. suit-parameter-device-identifier 9.8.2.13. suit-parameter-device-identifier
A RFC4122 UUID representing the device or component A RFC 4122 UUID representing the device or component.
9.8.2.14. suit-parameter-minimum-battery 9.8.2.14. suit-parameter-minimum-battery
A minimum battery level in mWh This parameter sets the minimum battery level in mWh.
9.8.2.15. suit-parameter-update-priority 9.8.2.15. suit-parameter-update-priority
The priority of the update This parameter sets the priority of the update.
9.8.2.16. suit-parameter-version 9.8.2.16. suit-parameter-version
TBD. Allows to indicate the version numbers of firmware to which the
manifest applies, either with a list or with range matching.
9.8.2.17. suit-parameter-wait-info 9.8.2.17. suit-parameter-wait-info
TBD. suit-directive-wait Section 9.8.4.11 directs the manifest processor
to pause until a specified event occurs. The suit-parameter-wait-
info encodes the parameters needed for the directive.
9.8.2.18. suit-parameter-uri-list 9.8.2.18. suit-parameter-uri-list
TBD. Indicates a list of URIs from which to fetch a resource.
9.8.2.19. suit-parameter-strict-order 9.8.2.19. suit-parameter-strict-order
The Strict Order Parameter allows a manifest to govern when The Strict Order Parameter allows a manifest to govern when
directives can be executed out-of-order. This allows for systems directives can be executed out-of-order. This allows for systems
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
skipping to change at page 33, line 19 skipping to change at page 31, line 9
When executing a command sequence inside SUIT_Directive_Try_Each and When executing a command sequence inside SUIT_Directive_Try_Each and
a condition failure occurs, the manifest processor aborts the a condition failure occurs, the manifest processor aborts the
sequence. If Soft Failure is True, it returns Success. Otherwise, sequence. If Soft Failure is True, it returns Success. Otherwise,
it returns the original condition failure. it returns the original condition failure.
SUIT_Parameter_Soft_Failure is scoped to the enclosing SUIT_Parameter_Soft_Failure is scoped to the enclosing
SUIT_Command_Sequence. Its value is discarded when SUIT_Command_Sequence. Its value is discarded when
SUIT_Command_Sequence terminates. SUIT_Command_Sequence terminates.
9.8.2.21. suit-parameter-custom 9.8.2.21. suit-parameter-custom
TBD. This parameter is an extension point for any proprietary, application
specific conditions and directives.
9.8.2.22. SUIT_Parameters CDDL
The following CDDL describes all SUIT_Parameters.
SUIT_Parameters //= (suit-parameter-vendor-identifier => RFC4122_UUID)
SUIT_Parameters //= (suit-parameter-class-identifier => RFC4122_UUID)
SUIT_Parameters //= (suit-parameter-image-digest
=> bstr .cbor SUIT_Digest)
SUIT_Parameters //= (suit-parameter-image-size => uint)
SUIT_Parameters //= (suit-parameter-use-before => uint)
SUIT_Parameters //= (suit-parameter-component-offset => uint)
SUIT_Parameters //= (suit-parameter-encryption-info
=> bstr .cbor SUIT_Encryption_Info)
SUIT_Parameters //= (suit-parameter-compression-info
=> bstr .cbor SUIT_Compression_Info)
SUIT_Parameters //= (suit-parameter-unpack-info
=> bstr .cbor SUIT_Unpack_Info)
SUIT_Parameters //= (suit-parameter-uri => tstr)
SUIT_Parameters //= (suit-parameter-source-component => uint)
SUIT_Parameters //= (suit-parameter-run-args => bstr)
SUIT_Parameters //= (suit-parameter-device-identifier => RFC4122_UUID)
SUIT_Parameters //= (suit-parameter-minimum-battery => uint)
SUIT_Parameters //= (suit-parameter-update-priority => uint)
SUIT_Parameters //= (suit-parameter-version =>
SUIT_Parameter_Version_Match)
SUIT_Parameters //= (suit-parameter-wait-info =>
bstr .cbor SUIT_Wait_Events)
SUIT_Parameters //= (suit-parameter-uri-list
=> bstr .cbor SUIT_Component_URI_List)
SUIT_Parameters //= (suit-parameter-custom => int/bool/tstr/bstr)
SUIT_Parameters //= (suit-parameter-strict-order => bool)
SUIT_Parameters //= (suit-parameter-soft-failure => bool)
RFC4122_UUID = bstr .size 16
SUIT_Condition_Version_Comparison_Value = [+int]
SUIT_Encryption_Info = COSE_Encrypt_Tagged/COSE_Encrypt0_Tagged
SUIT_Compression_Info = {
suit-compression-algorithm => SUIT_Compression_Algorithms,
? suit-compression-parameters => bstr
}
SUIT_Compression_Algorithms /= SUIT_Compression_Algorithm_zlib
SUIT_Compression_Algorithms /= SUIT_Compression_Algorithm_brotli
SUIT_Compression_Algorithms /= SUIT_Compression_Algorithm_zstd
SUIT_Unpack_Info = {
suit-unpack-algorithm => SUIT_Unpack_Algorithms,
? suit-unpack-parameters => bstr
}
SUIT_Unpack_Algorithms /= SUIT_Unpack_Algorithm_Hex
SUIT_Unpack_Algorithms /= SUIT_Unpack_Algorithm_Elf
SUIT_Unpack_Algorithms /= SUIT_Unpack_Algorithm_Coff
SUIT_Unpack_Algorithms /= SUIT_Unpack_Algorithm_Srec
9.8.3. SUIT_Condition 9.8.3. SUIT_Condition
Conditions are used to define mandatory properties of a system in Conditions are used to define mandatory properties of a system in
order for an update to be applied. They can be pre-conditions or order for an update to be applied. They can be pre-conditions or
post-conditions of any directive or series of directives, depending post-conditions of any directive or series of directives, depending
on where they are placed in the list. Conditions never take on where they are placed in the list. Conditions never take
arguments; conditions should test using parameters instead. arguments; conditions should test using parameters instead.
Conditions include: Conditions include:
skipping to change at page 39, line 14 skipping to change at page 36, line 14
Versions are encoded as a CBOR list of integers. Comparisons are Versions are encoded as a CBOR list of integers. Comparisons are
done on each integer in sequence. Comparison stops after all done on each integer in sequence. Comparison stops after all
integers in the list defined by the manifest have been consumed OR integers in the list defined by the manifest have been consumed OR
after a non-equal match has occurred. For example, if the manifest after a non-equal match has occurred. For example, if the manifest
defines a comparison, "Equal [1]", then this will match all version defines a comparison, "Equal [1]", then this will match all version
sequences starting with 1. If a manifest defines both "Greater or 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 Equal [1,0]" and "Lesser [1,10]", then it will match versions 1.0.x
up to, but not including 1.10. up to, but not including 1.10.
The following CDDL describes SUIT_Condition_Version_Argument
SUIT_Condition_Version_Argument = [
suit-condition-version-comparison-type:
SUIT_Condition_Version_Comparison_Types,
suit-condition-version-comparison-value:
SUIT_Condition_Version_Comparison_Value
]
SUIT_Condition_Version_Comparison_Types /=
suit-condition-version-comparison-greater
SUIT_Condition_Version_Comparison_Types /=
suit-condition-version-comparison-greater-equal
SUIT_Condition_Version_Comparison_Types /=
suit-condition-version-comparison-equal
SUIT_Condition_Version_Comparison_Types /=
suit-condition-version-comparison-lesser-equal
SUIT_Condition_Version_Comparison_Types /=
suit-condition-version-comparison-lesser
SUIT_Condition_Version_Comparison_Value = [+int]
While the exact encoding of versions is application-defined, semantic While the exact encoding of versions is application-defined, semantic
versions map conveniently. For example, versions map conveniently. For example,
- 1.2.3 = [1,2,3]. - 1.2.3 = [1,2,3].
- 1.2-rc3 = [1,2,-1,3]. - 1.2-rc3 = [1,2,-1,3].
- 1.2-beta = [1,2,-2]. - 1.2-beta = [1,2,-2].
- 1.2-alpha = [1,2,-3]. - 1.2-alpha = [1,2,-3].
skipping to change at page 40, line 14 skipping to change at page 36, line 38
9.8.3.9. SUIT_Condition_Custom 9.8.3.9. SUIT_Condition_Custom
SUIT_Condition_Custom describes any proprietary, application specific SUIT_Condition_Custom describes any proprietary, application specific
condition. This is encoded as a negative integer, chosen by the condition. This is encoded as a negative integer, chosen by the
firmware developer. If additional information must be provided to firmware developer. If additional information must be provided to
the condition, it should be encoded in a custom parameter (a nint) as the condition, it should be encoded in a custom parameter (a nint) as
described in Section 9.8.2. SUIT_Condition_Custom is OPTIONAL to described in Section 9.8.2. SUIT_Condition_Custom is OPTIONAL to
implement. implement.
9.8.3.10. SUIT_Condition CDDL
The following CDDL describes SUIT_Condition:
SUIT_Condition //= (suit-condition-vendor-identifier, nil)
SUIT_Condition //= (suit-condition-class-identifier, nil)
SUIT_Condition //= (suit-condition-device-identifier, nil)
SUIT_Condition //= (suit-condition-image-match, nil)
SUIT_Condition //= (suit-condition-image-not-match, nil)
SUIT_Condition //= (suit-condition-use-before, nil)
SUIT_Condition //= (suit-condition-component-offset, nil)
SUIT_Condition //= (suit-condition-minimum-battery, nil)
SUIT_Condition //= (suit-condition-update-authorized, nil)
SUIT_Condition //= (suit-condition-version, nil)
SUIT_Condition //= (suit-condition-component-offset, nil)
9.8.4. SUIT_Directive 9.8.4. SUIT_Directive
Directives are used to define the behavior of the recipient. Directives are used to define the behavior of the recipient.
Directives include: Directives include:
+---------------+-------------------------------------+-------------+ +---------------+-------------------------------------+-------------+
| Name | CDDL Structure | Reference | | Name | CDDL Structure | Reference |
+---------------+-------------------------------------+-------------+ +---------------+-------------------------------------+-------------+
| Set Component | suit-directive-set-component-index | Section | | Set Component | suit-directive-set-component-index | Section |
| Index | | 9.8.4.1 | | Index | | 9.8.4.1 |
skipping to change at page 42, line 19 skipping to change at page 38, line 19
either a boolean or an unsigned integer index into the concatenation either a boolean or an unsigned integer index into the concatenation
of suit-components and suit-dependency-components. If the following of suit-components and suit-dependency-components. If the following
directives apply to ALL components, then the boolean value "True" is directives apply to ALL components, then the boolean value "True" is
used instead of an index. True does not apply to dependency used instead of an index. True does not apply to dependency
components. If the following directives apply to NO components, then components. If the following directives apply to NO components, then
the boolean value "False" is used. When suit-directive-set- the boolean value "False" is used. When suit-directive-set-
dependency-index is used, suit-directive-set-component-index = False dependency-index is used, suit-directive-set-component-index = False
is implied. When suit-directive-set-component-index is used, suit- is implied. When suit-directive-set-component-index is used, suit-
directive-set-dependency-index = False is implied. directive-set-dependency-index = False is implied.
The following CDDL describes the argument to suit-directive-set-
component-index.
SUIT_Directive_Set_Component_Index_Argument = uint/bool
9.8.4.2. suit-directive-set-dependency-index 9.8.4.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.
Typical operations that require suit-directive-set-dependency-index Typical operations that require suit-directive-set-dependency-index
include setting a source URI, invoking "Fetch," or invoking "Process include setting a source URI, invoking "Fetch," or invoking "Process
Dependency" for an individual dependency. Dependency" for an individual dependency.
The following CDDL describes the argument to suit-directive-set-
dependency-index.
SUIT_Directive_Set_Manifest_Index_Argument = uint/bool
9.8.4.3. suit-directive-abort 9.8.4.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.
9.8.4.4. suit-directive-try-each 9.8.4.4. suit-directive-try-each
This command runs several SUIT_Command_Sequence, one after another, This command runs several SUIT_Command_Sequence, one after another,
in a strict order. Use this command to implement a "try/catch-try/ in a strict order. Use this command to implement a "try/catch-try/
catch" sequence. Manifest processors MAY implement this command. catch" sequence. Manifest processors MAY implement this command.
SUIT_Parameter_Soft_Failure is initialized to True at the beginning SUIT_Parameter_Soft_Failure is initialized to True at the beginning
of each sequence. If one sequence aborts due to a condition failure, of each sequence. If one sequence aborts due to a condition failure,
the next is started. If no sequence completes without condition the next is started. If no sequence completes without condition
failure, then suit-directive-try-each returns an error. If a failure, then suit-directive-try-each returns an error. If a
particular application calls for all sequences to fail and still particular application calls for all sequences to fail and still
continue, then an empty sequence (nil) can be added to the Try Each continue, then an empty sequence (nil) can be added to the Try Each
Argument. Argument.
The following CDDL describes the SUIT_Try_Each argument.
SUIT_Directive_Try_Each_Argument = [
+ bstr .cbor SUIT_Command_Sequence,
nil / bstr .cbor SUIT_Command_Sequence
]
9.8.4.5. suit-directive-process-dependency 9.8.4.5. suit-directive-process-dependency
Execute the commands in the common section of the current dependency, Execute the commands in the common section of the current dependency,
followed by the commands in the equivalent section of the current followed by the commands in the equivalent section of the current
dependency. For example, if the current section is "fetch payload," dependency. For example, if the current section is "fetch payload,"
this will execute "common" in the current dependency, then "fetch this will execute "common" in the current dependency, then "fetch
payload" in the current dependency. Once this is complete, the payload" in the current dependency. Once this is complete, the
command following suit-directive-process-dependency will be command following suit-directive-process-dependency will be
processed. processed.
If the current dependency is False, this directive has no effect. If If the current dependency is False, this directive has no effect. If
the current dependency is True, then this directive applies to all the current dependency is True, then this directive applies to all
dependencies. If the current section is "common," this directive dependencies. If the current section is "common," this directive
MUST have no effect. MUST have no effect.
When SUIT_Process_Dependency completes, it forwards the last status When SUIT_Process_Dependency completes, it forwards the last status
code that occurred in the dependency. code that occurred in the dependency.
The argument to suit-directive-process-dependency is defined in the
following CDDL.
SUIT_Directive_Process_Dependency_Argument = nil
9.8.4.6. suit-directive-set-parameters 9.8.4.6. suit-directive-set-parameters
suit-directive-set-parameters allows the manifest to configure suit-directive-set-parameters allows the manifest to configure
behavior of future directives by changing parameters that are read by behavior of future directives by changing parameters that are read by
those directives. When dependencies are used, suit-directive-set- those directives. When dependencies are used, suit-directive-set-
parameters also allows a manifest to modify the behavior of its parameters also allows a manifest to modify the behavior of its
dependencies. dependencies.
Available parameters are defined in Section 9.8.2. Available parameters are defined in Section 9.8.2.
If a parameter is already set, suit-directive-set-parameters will If a parameter is already set, suit-directive-set-parameters will
skip setting the parameter to its argument. This provides the core skip setting the parameter to its argument. This provides the core
of the override mechanism, allowing dependent manifests to change the of the override mechanism, allowing dependent manifests to change the
behavior of a manifest. behavior of a manifest.
The argument to suit-directive-set-parameters is defined in the
following CDDL.
SUIT_Directive_Set_Parameters_Argument = {+ SUIT_Parameters}
N.B.: A directive code is reserved for an optimization: a way to set
a parameter to the contents of another parameter, optionally with
another component ID.
9.8.4.7. suit-directive-override-parameters 9.8.4.7. suit-directive-override-parameters
suit-directive-override-parameters replaces any listed parameters suit-directive-override-parameters replaces any listed parameters
that are already set with the values that are provided in its that are already set with the values that are provided in its
argument. This allows a manifest to prevent replacement of critical argument. This allows a manifest to prevent replacement of critical
parameters. parameters.
Available parameters are defined in Section 9.8.2. Available parameters are defined in Section 9.8.2.
The argument to suit-directive-override-parameters is defined in the
following CDDL.
SUIT_Directive_Override_Parameters_Argument = {+ SUIT_Parameters}
9.8.4.8. suit-directive-fetch 9.8.4.8. suit-directive-fetch
suit-directive-fetch instructs the manifest processor to obtain one suit-directive-fetch instructs the manifest processor to obtain one
or more manifests or payloads, as specified by the manifest index and or more manifests or payloads, as specified by the manifest index and
component index, respectively. component index, respectively.
suit-directive-fetch can target one or more manifests and one or more suit-directive-fetch can target one or more manifests and one or more
payloads. suit-directive-fetch retrieves each component and each payloads. suit-directive-fetch retrieves each component and each
manifest listed in component-index and manifest-index, respectively. manifest listed in component-index and manifest-index, respectively.
If component-index or manifest-index is True, instead of an integer, If component-index or manifest-index is True, instead of an integer,
skipping to change at page 45, line 23 skipping to change at page 40, line 34
suit-directive-fetch reads the URI or URI List parameter to find the suit-directive-fetch reads the URI or URI List parameter to find the
source of the fetch it performs. source of the fetch it performs.
The behavior of suit-directive-fetch can be modified by setting one The behavior of suit-directive-fetch can be modified by setting one
or more of SUIT_Parameter_Encryption_Info, or more of SUIT_Parameter_Encryption_Info,
SUIT_Parameter_Compression_Info, SUIT_Parameter_Unpack_Info. These SUIT_Parameter_Compression_Info, SUIT_Parameter_Unpack_Info. These
three parameters each activate and configure a processing step that three parameters each activate and configure a processing step that
can be applied to the data that is transferred during suit-directive- can be applied to the data that is transferred during suit-directive-
fetch. fetch.
The argument to suit-directive-fetch is defined in the following
CDDL.
SUIT_Directive_Fetch_Argument = nil/bstr
9.8.4.9. suit-directive-copy 9.8.4.9. suit-directive-copy
suit-directive-copy instructs the manifest processor to obtain one or suit-directive-copy instructs the manifest processor to obtain one or
more payloads, as specified by the component index. suit-directive- more payloads, as specified by the component index. suit-directive-
copy retrieves each component listed in component-index, copy retrieves each component listed in component-index,
respectively. If component-index is True, instead of an integer, respectively. If component-index is True, instead of an integer,
then all current manifest components are copied. The current then all current manifest components are copied. The current
manifest's dependent-components are not automatically copied. In manifest's dependent-components are not automatically copied. In
order to copy these, they MUST be specified in a component-index order to copy these, they MUST be specified in a component-index
integer. integer.
skipping to change at page 46, line 5 skipping to change at page 41, line 11
three parameters each activate and configure a processing step that three parameters each activate and configure a processing step that
can be applied to the data that is transferred during suit-directive- can be applied to the data that is transferred during suit-directive-
copy. copy.
*N.B.* Fetch and Copy are very similar. Merging them into one *N.B.* Fetch and Copy are very similar. Merging them into one
command may be appropriate. command may be appropriate.
suit-directive-copy reads its source from suit-directive-copy reads its source from
SUIT_Parameter_Source_Component. SUIT_Parameter_Source_Component.
The argument to suit-directive-copy is defined in the following CDDL.
SUIT_Directive_Copy_Argument = nil
9.8.4.10. suit-directive-run 9.8.4.10. suit-directive-run
suit-directive-run directs the manifest processor to transfer suit-directive-run directs the manifest processor to transfer
execution to the current Component Index. When this is invoked, the execution to the current Component Index. When this is invoked, the
manifest processor MAY be unloaded and execution continues in the manifest processor MAY be unloaded and execution continues in the
Component Index. Arguments provided to Run are forwarded to the Component Index. Arguments provided to Run are forwarded to the
executable code located in Component Index, in an application- executable code located in Component Index, in an application-
specific way. For example, this could form the Linux Kernel Command specific way. For example, this could form the Linux Kernel Command
Line if booting a Linux device. Line if booting a Linux device.
If the executable code at Component Index is constructed in such a If the executable code at Component Index is constructed in such a
way that it does not unload the manifest processor, then the manifest way that it does not unload the manifest processor, then the manifest
processor may resume execution after the executable completes. This processor may resume execution after the executable completes. This
allows the manifest processor to invoke suitable helpers and to allows the manifest processor to invoke suitable helpers and to
verify them with image conditions. verify them with image conditions.
The argument to suit-directive-run is defined in the following CDDL.
SUIT_Directive_Run_Argument = nil/bstr
9.8.4.11. suit-directive-wait 9.8.4.11. suit-directive-wait
suit-directive-wait directs the manifest processor to pause until a suit-directive-wait directs the manifest processor to pause until a
specified event occurs. Some possible events include: specified event occurs. Some possible events include:
1. Authorization 1. Authorization
2. External Power 2. External Power
3. Network availability 3. Network availability
4. Other Device Firmware Version 4. Other Device Firmware Version
5. Time 5. Time
6. Time of Day 6. Time of Day
7. Day of Week 7. Day of Week
The following CDDL defines the encoding of these events.
SUIT_Wait_Events //= (suit-wait-event-authorization => int)
SUIT_Wait_Events //= (suit-wait-event-power => int)
SUIT_Wait_Events //= (suit-wait-event-network => int)
SUIT_Wait_Events //= (suit-wait-event-other-device-version
=> SUIT_Wait_Event_Argument_Other_Device_Version)
SUIT_Wait_Events //= (suit-wait-event-time => uint); Timestamp
SUIT_Wait_Events //= (suit-wait-event-time-of-day
=> uint); Time of Day (seconds since 00:00:00)
SUIT_Wait_Events //= (suit-wait-event-day-of-week
=> uint); Days since Sunday
SUIT_Wait_Event_Argument_Authorization = int ; priority
SUIT_Wait_Event_Argument_Power = int ; Power Level
SUIT_Wait_Event_Argument_Network = int ; Network State
SUIT_Wait_Event_Argument_Other_Device_Version = [
other-device: bstr,
other-device-version: [+int]
]
SUIT_Wait_Event_Argument_Time = uint ; Timestamp
SUIT_Wait_Event_Argument_Time_Of_Day = uint ; Time of Day
; (seconds since 00:00:00)
SUIT_Wait_Event_Argument_Day_Of_Week = uint ; Days since Sunday
9.8.4.12. suit-directive-run-sequence 9.8.4.12. suit-directive-run-sequence
To enable conditional commands, and to allow several strictly ordered To enable conditional commands, and to allow several strictly ordered
sequences to be executed out-of-order, suit-directive-run-sequence sequences to be executed out-of-order, suit-directive-run-sequence
allows the manifest processor to execute its argument as a allows the manifest processor to execute its argument as a
SUIT_Command_Sequence. The argument must be wrapped in a bstr. SUIT_Command_Sequence. The argument must be wrapped in a bstr.
When a sequence is executed, any failure of a condition causes When a sequence is executed, any failure of a condition causes
immediate termination of the sequence. immediate termination of the sequence.
The following CDDL describes the SUIT_Run_Sequence argument.
SUIT_Directive_Run_Sequence_Argument = bstr .cbor SUIT_Command_Sequence
When suit-directive-run-sequence completes, it forwards the last When suit-directive-run-sequence completes, it forwards the last
status code that occurred in the sequence. If the Soft Failure status code that occurred in the sequence. If the Soft Failure
parameter is true, then suit-directive-run-sequence only fails when a parameter is true, then suit-directive-run-sequence only fails when a
directive in the argument sequence fails. directive in the argument sequence fails.
SUIT_Parameter_Soft_Failure defaults to False when suit-directive- SUIT_Parameter_Soft_Failure defaults to False when suit-directive-
run-sequence begins. Its value is discarded when suit-directive-run- run-sequence begins. Its value is discarded when suit-directive-run-
sequence terminates. sequence terminates.
9.8.4.13. suit-directive-swap 9.8.4.13. suit-directive-swap
skipping to change at page 48, line 20 skipping to change at page 42, line 32
directive-copy except that suit-directive-swap replaces the source directive-copy except that suit-directive-swap replaces the source
with the current contents of the destination in an application- with the current contents of the destination in an application-
defined way. If SUIT_Parameter_Compression_Info or defined way. If SUIT_Parameter_Compression_Info or
SUIT_Parameter_Encryption_Info are present, they must be handled in a SUIT_Parameter_Encryption_Info are present, they must be handled in a
symmetric way, so that the source is decompressed into the symmetric way, so that the source is decompressed into the
destination and the destination is compressed into the source. The destination and the destination is compressed into the source. The
source is decrypted into the destination and the destination is source is decrypted into the destination and the destination is
encrypted into the source. suit-directive-swap is OPTIONAL to encrypted into the source. suit-directive-swap is OPTIONAL to
implement. implement.
9.8.4.14. SUIT_Directive CDDL
The following CDDL describes SUIT_Directive:
SUIT_Directive //= (suit-directive-set-component-index, uint/bool)
SUIT_Directive //= (suit-directive-set-dependency-index, uint/bool)
SUIT_Directive //= (suit-directive-run-sequence,
bstr .cbor SUIT_Command_Sequence)
SUIT_Directive //= (suit-directive-try-each,
SUIT_Directive_Try_Each_Argument)
SUIT_Directive //= (suit-directive-process-dependency, nil)
SUIT_Directive //= (suit-directive-set-parameters,
{+ SUIT_Parameters})
SUIT_Directive //= (suit-directive-override-parameters,
{+ SUIT_Parameters})
SUIT_Directive //= (suit-directive-fetch, nil)
SUIT_Directive //= (suit-directive-copy, nil)
SUIT_Directive //= (suit-directive-run, nil)
SUIT_Directive //= (suit-directive-wait,
{ + SUIT_Wait_Events })
SUIT_Directive_Try_Each_Argument = [
+ bstr .cbor SUIT_Command_Sequence,
nil / bstr .cbor SUIT_Command_Sequence
]
SUIT_Wait_Events //= (suit-wait-event-authorization => int)
SUIT_Wait_Events //= (suit-wait-event-power => int)
SUIT_Wait_Events //= (suit-wait-event-network => int)
SUIT_Wait_Events //= (suit-wait-event-other-device-version
=> SUIT_Wait_Event_Argument_Other_Device_Version)
SUIT_Wait_Events //= (suit-wait-event-time => uint); Timestamp
SUIT_Wait_Events //= (suit-wait-event-time-of-day
=> uint); Time of Day (seconds since 00:00:00)
SUIT_Wait_Events //= (suit-wait-event-day-of-week
=> uint); Days since Sunday
SUIT_Wait_Event_Argument_Authorization = int ; priority
SUIT_Wait_Event_Argument_Power = int ; Power Level
SUIT_Wait_Event_Argument_Network = int ; Network State
SUIT_Wait_Event_Argument_Other_Device_Version = [
other-device: bstr,
other-device-version: [+int]
]
SUIT_Wait_Event_Argument_Time = uint ; Timestamp
SUIT_Wait_Event_Argument_Time_Of_Day = uint ; Time of Day
; (seconds since 00:00:00)
SUIT_Wait_Event_Argument_Day_Of_Week = uint ; Days since Sunday
9.9. SUIT_Manifest CDDL
The following CDDL fragment defines the manifest.
SUIT_Manifest = {
suit-manifest-version => 1,
suit-manifest-sequence-number => uint,
suit-common => bstr .cbor SUIT_Common,
? suit-reference-uri => #6.32(tstr),
* $$SUIT_Severable_Command_Sequences,
* $$SUIT_Command_Sequences,
* $$SUIT_Protected_Elements,
}
$$SUIT_Severable_Command_Sequences //= (suit-dependency-resolution =>
SUIT_Severable_Command_Segment)
$$SUIT_Severable_Command_Segments //= (suit-payload-fetch =>
SUIT_Severable_Command_Sequence)
$$SUIT_Severable_Command_Segments //= (suit-install =>
SUIT_Severable_Command_Sequence)
SUIT_Severable_Command_Sequence =
SUIT_Digest / bstr .cbor SUIT_Command_Sequence
$$SUIT_Command_Sequences //= ( suit-validate =>
bstr .cbor SUIT_Command_Sequence )
$$SUIT_Command_Sequences //= ( suit-load =>
bstr .cbor SUIT_Command_Sequence )
$$SUIT_Command_Sequences //= ( suit-run =>
bstr .cbor SUIT_Command_Sequence )
$$SUIT_Protected_Elements //= ( suit-text => SUIT_Digest )
$$SUIT_Protected_Elements //= ( suit-coswid => SUIT_Digest )
SUIT_Common = {
? suit-dependencies => bstr .cbor SUIT_Dependencies,
? suit-components => bstr .cbor SUIT_Components,
? suit-dependency-components
=> bstr .cbor SUIT_Component_References,
? suit-common-sequence => bstr .cbor SUIT_Command_Sequence,
}
10. Access Control Lists 10. Access Control Lists
To manage permissions in the manifest, there are three models that To manage permissions in the manifest, there are three models that
can be used. can be used.
First, the simplest model requires that all manifests are First, the simplest model requires that all manifests are
authenticated by a single trusted key. This mode has the advantage authenticated by a single trusted key. This mode has the advantage
that only a root manifest needs to be authenticated, since all of its that only a root manifest needs to be authenticated, since all of its
dependencies have digests included in the root manifest. dependencies have digests included in the root manifest.
skipping to change at page 51, line 31 skipping to change at page 43, line 16
controls: The ACL lists the component ID or component ID prefix that controls: The ACL lists the component ID or component ID prefix that
an identity may use, and also lists the commands that the identity an identity may use, and also lists the commands that the identity
may use in combination with that component ID. may use in combination with that component ID.
11. SUIT Digest Container 11. SUIT Digest Container
RFC 8152 [RFC8152] provides containers for signature, MAC, and RFC 8152 [RFC8152] provides containers for signature, MAC, and
encryption, but no basic digest container. The container needed for encryption, but no basic digest container. The container needed for
a digest requires a type identifier and a container for the raw a digest requires a type identifier and a container for the raw
digest data. Some forms of digest may require additional parameters. digest data. Some forms of digest may require additional parameters.
These can be added following the digest. This structure is described These can be added following the digest.
by the following CDDL.
The algorithms listed are sufficient for verifying integrity of The algorithms listed are sufficient for verifying integrity of
Firmware Updates as of this writing, however this may change over Firmware Updates as of this writing, however this may change over
time. time.
SUIT_Digest = [
suit-digest-algorithm-id : $suit-digest-algorithm-ids,
suit-digest-bytes : bytes,
? suit-digest-parameters : any
]
digest-algorithm-ids /= algorithm-id-sha224
digest-algorithm-ids /= algorithm-id-sha256
digest-algorithm-ids /= algorithm-id-sha384
digest-algorithm-ids /= algorithm-id-sha512
digest-algorithm-ids /= algorithm-id-sha3-224
digest-algorithm-ids /= algorithm-id-sha3-256
digest-algorithm-ids /= algorithm-id-sha3-384
digest-algorithm-ids /= algorithm-id-sha3-512
algorithm-id-sha224 = 1
algorithm-id-sha256 = 2
algorithm-id-sha384 = 3
algorithm-id-sha512 = 4
algorithm-id-sha3-224 = 5
algorithm-id-sha3-256 = 6
algorithm-id-sha3-384 = 7
algorithm-id-sha3-512 = 8
12. Creating Conditional Sequences 12. Creating Conditional Sequences
For some use cases, it is important to provide a sequence that can For some use cases, it is important to provide a sequence that can
fail without terminating an update. For example, a dual-image XIP fail without terminating an update. For example, a dual-image XIP
MCU may require an update that can be placed at one of two offsets. MCU may require an update that can be placed at one of two offsets.
This has two implications, first, the digest of each offset will be This has two implications, first, the digest of each offset will be
different. Second, the image fetched for each offset will have a different. Second, the image fetched for each offset will have a
different URI. Conditional sequences allow this to be resolved in a different URI. Conditional sequences allow this to be resolved in a
simple way. simple way.
skipping to change at page 57, line 47 skipping to change at page 47, line 47
| 26 | Minimum Battery | | 26 | Minimum Battery |
| | | | | |
| 27 | Update Priority | | 27 | Update Priority |
| | | | | |
| 28 | Version | | 28 | Version |
| | | | | |
| 29 | Wait Info | | 29 | Wait Info |
| | | | | |
| 30 | URI List | | 30 | URI List |
| | | | | |
| 31 | Component Index |
| | |
| nint | Custom | | nint | Custom |
+-------+------------------+ +-------+------------------+
13.4. SUIT Text Values 13.4. SUIT Text Values
+-------+--------------------------------+ +-------+--------------------------------+
| Label | Name | | Label | Name |
+-------+--------------------------------+ +-------+--------------------------------+
| 1 | Manifest Description | | 1 | Manifest Description |
| | | | | |
skipping to change at page 58, line 33 skipping to change at page 48, line 33
| | | | | |
| 8 | Manifest JSON Source | | 8 | Manifest JSON Source |
| | | | | |
| 9 | Manifest YAML Source | | 9 | Manifest YAML Source |
| | | | | |
| 10 | Component Version Dependencies | | 10 | Component Version Dependencies |
+-------+--------------------------------+ +-------+--------------------------------+
13.5. SUIT Algorithm Identifiers 13.5. SUIT Algorithm Identifiers
TBD. 13.5.1. Hash Algorithms
+-------+----------+
| Label | Name |
+-------+----------+
| 1 | SHA224 |
| | |
| 2 | SHA256 |
| | |
| 3 | SHA384 |
| | |
| 4 | SHA512 |
| | |
| 5 | SHA3-224 |
| | |
| 6 | SHA3-256 |
| | |
| 7 | SHA3-384 |
| | |
| 8 | SHA3-512 |
+-------+----------+
13.5.2. Unpack Algorithms
+-------+------+
| Label | Name |
+-------+------+
| 1 | HEX |
| | |
| 2 | ELF |
| | |
| 3 | COFF |
| | |
| 4 | SREC |
+-------+------+
14. Security Considerations 14. Security Considerations
This document is about a manifest format describing and protecting This document is about a manifest format describing and protecting
firmware images and as such it is part of a larger solution for firmware images and as such it is part of a larger solution for
offering a standardized way of delivering firmware updates to IoT offering a standardized way of delivering firmware updates to IoT
devices. A detailed discussion about security can be found in the devices. A detailed security treatment can be found in the
architecture document [I-D.ietf-suit-architecture] and in architecture [I-D.ietf-suit-architecture] and in the information
[I-D.ietf-suit-information-model]. model [I-D.ietf-suit-information-model] documents.
15. Mailing List Information
RFC EDITOR: PLEASE REMOVE THIS SECTION
The discussion list for this document is located at the e-mail
address suit@ietf.org [1]. Information on the group and information
on how to subscribe to the list is at
https://www1.ietf.org/mailman/listinfo/suit [2]
Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/suit/current/index.html [3]
16. Acknowledgements 15. Acknowledgements
We would like to thank the following persons for their support in We would like to thank the following persons for their support in
designing this mechanism: designing this mechanism:
- Milosch Meriac - Milosch Meriac
- Geraint Luff - Geraint Luff
- Dan Ros - Dan Ros
skipping to change at page 59, line 38 skipping to change at page 50, line 31
- Krzysztof Chruściński - Krzysztof Chruściński
- Andrzej Puzdrowski - Andrzej Puzdrowski
- Michael Richardson - Michael Richardson
- David Brown - David Brown
- Emmanuel Baccelli - Emmanuel Baccelli
17. References 16. References
17.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
17.2. Informative References 16.2. Informative References
[COFF] Wikipedia, ., "Common Object File Format (COFF)", 2020, [COFF] Wikipedia, ., "Common Object File Format (COFF)", 2020,
<https://en.wikipedia.org/wiki/COFF>. <https://en.wikipedia.org/wiki/COFF>.
[ELF] Wikipedia, ., "Executable and Linkable Format (ELF)", [ELF] Wikipedia, ., "Executable and Linkable Format (ELF)",
2020, <https://en.wikipedia.org/wiki/ 2020, <https://en.wikipedia.org/wiki/
Executable_and_Linkable_Format>. Executable_and_Linkable_Format>.
[HEX] Wikipedia, ., "Intel HEX", 2020, [HEX] Wikipedia, ., "Intel HEX", 2020,
<https://en.wikipedia.org/wiki/Intel_HEX>. <https://en.wikipedia.org/wiki/Intel_HEX>.
[I-D.ietf-suit-architecture] [I-D.ietf-suit-architecture]
Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things", Firmware Update Architecture for Internet of Things",
draft-ietf-suit-architecture-11 (work in progress), May draft-ietf-suit-architecture-11 (work in progress), May
2020. 2020.
[I-D.ietf-suit-information-model] [I-D.ietf-suit-information-model]
Moran, B., Tschofenig, H., and H. Birkholz, "An Moran, B., Tschofenig, H., and H. Birkholz, "An
Information Model for Firmware Updates in IoT Devices", Information Model for Firmware Updates in IoT Devices",
draft-ietf-suit-information-model-06 (work in progress), draft-ietf-suit-information-model-07 (work in progress),
June 2020. June 2020.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-08 (work in Architecture", draft-ietf-teep-architecture-08 (work in
progress), April 2020. progress), April 2020.
[I-D.kucherawy-rfc8478bis] [I-D.kucherawy-rfc8478bis]
Collet, Y. and M. Kucherawy, "Zstandard Compression and Collet, Y. and M. Kucherawy, "Zstandard Compression and
skipping to change at page 61, line 16 skipping to change at page 53, line 5
Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, Format", RFC 7932, DOI 10.17487/RFC7932, July 2016,
<https://www.rfc-editor.org/info/rfc7932>. <https://www.rfc-editor.org/info/rfc7932>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[SREC] Wikipedia, ., "SREC (file format)", 2020, [SREC] Wikipedia, ., "SREC (file format)", 2020,
<https://en.wikipedia.org/wiki/SREC_(file_format)>. <https://en.wikipedia.org/wiki/SREC_(file_format)>.
17.3. URIs
[1] mailto:suit@ietf.org
[2] https://www1.ietf.org/mailman/listinfo/suit
[3] https://www.ietf.org/mail-archive/web/suit/current/index.html
A. Full CDDL A. Full CDDL
In order to create a valid SUIT Manifest document the structure of In order to create a valid SUIT Manifest document the structure of
the corresponding CBOR message MUST adhere to the following CDDL data the corresponding CBOR message MUST adhere to the following CDDL data
definition. definition.
SUIT_Envelope = { SUIT_Envelope = {
? suit-delegation => bstr .cbor SUIT_Delegation ? suit-delegation => bstr .cbor SUIT_Delegation
? suit-authentication-wrapper ? suit-authentication-wrapper
=> bstr .cbor SUIT_Authentication_Wrapper / nil, => bstr .cbor SUIT_Authentication_Wrapper / nil,
skipping to change at page 89, line 42 skipping to change at page 80, line 42
Capability reporting is similarly simplified. A Recipient can report Capability reporting is similarly simplified. A Recipient can report
the Commands, Parameters, Algorithms, and Component Identifiers that the Commands, Parameters, Algorithms, and Component Identifiers that
it supports. This is sufficiently precise for a manifest author to it supports. This is sufficiently precise for a manifest author to
create a manifest that the Recipient can accept. create a manifest that the Recipient can accept.
The simplicity of design in the Recipient due to all of these The simplicity of design in the Recipient due to all of these
benefits allows even a highly constrained platform to use advanced benefits allows even a highly constrained platform to use advanced
update capabilities. update capabilities.
D. Implementation Confirmance Matrix D. Implementation Conformance Matrix
This section summarizes the functionality a minimal implementation This section summarizes the functionality a minimal implementation
needs to offer to claim conformance to this specification. needs to offer to claim conformance to this specification, in the
absence of an application profile standard specifying otherwise.
The subsequent table shows the conditions. The subsequent table shows the conditions.
+-------------------+-----------------+----------------+ +-------------------+-----------------+----------------+
| Name | Reference | Implementation | | Name | Reference | Implementation |
+-------------------+-----------------+----------------+ +-------------------+-----------------+----------------+
| Vendor Identifier | Section 9.8.3.1 | REQUIRED | | Vendor Identifier | Section 9.8.3.1 | REQUIRED |
| | | | | | | |
| Class Identifier | Section 9.8.3.1 | REQUIRED | | Class Identifier | Section 9.8.3.1 | REQUIRED |
| | | | | | | |
skipping to change at page 91, line 48 skipping to change at page 82, line 48
| Wait For Event | Section | OPTIONAL | | Wait For Event | Section | OPTIONAL |
| | 9.8.4.11 | | | | 9.8.4.11 | |
| | | | | | | |
| Run Sequence | Section | OPTIONAL | | Run Sequence | Section | OPTIONAL |
| | 9.8.4.12 | | | | 9.8.4.12 | |
| | | | | | | |
| Swap | Section | OPTIONAL | | Swap | Section | OPTIONAL |
| | 9.8.4.13 | | | | 9.8.4.13 | |
+-------------------+----------------+------------------------------+ +-------------------+----------------+------------------------------+
TThe subsequent table shows the parameters The subsequent table shows the parameters.
+------------------+------------------+----------------+ +------------------+------------------+----------------+
| Name | Reference | Implementation | | Name | Reference | Implementation |
+------------------+------------------+----------------+ +------------------+------------------+----------------+
| Vendor ID | Section 9.8.2.1 | TBD | | Vendor ID | Section 9.8.2.1 | REQUIRED |
| | | | | | | |
| Class ID | Section 9.8.2.2 | TBD | | Class ID | Section 9.8.2.2 | REQUIRED |
| | | | | | | |
| Image Digest | Section 9.8.2.3 | TBD | | Image Digest | Section 9.8.2.3 | REQUIRED |
| | | | | | | |
| Image Size | Section 9.8.2.4 | TBD | | Image Size | Section 9.8.2.4 | REQUIRED |
| | | | | | | |
| Use Before | Section 9.8.2.5 | TBD | | Use Before | Section 9.8.2.5 | OPTIONAL |
| | | | | | | |
| Component Offset | Section 9.8.2.6 | TBD | | Component Offset | Section 9.8.2.6 | OPTIONAL |
| | | | | | | |
| Encryption Info | Section 9.8.2.7 | TBD | | Encryption Info | Section 9.8.2.7 | OPTIONAL |
| | | | | | | |
| Compression Info | Section 9.8.2.8 | TBD | | Compression Info | Section 9.8.2.8 | OPTIONAL |
| | | | | | | |
| Unpack Info | Section 9.8.2.9 | TBD | | Unpack Info | Section 9.8.2.9 | OPTIONAL |
| | | | | | | |
| URI | Section 9.8.2.10 | TBD | | URI | Section 9.8.2.10 | OPTIONAL |
| | | | | | | |
| Source Component | Section 9.8.2.11 | TBD | | Source Component | Section 9.8.2.11 | OPTIONAL |
| | | | | | | |
| Run Args | Section 9.8.2.12 | TBD | | Run Args | Section 9.8.2.12 | OPTIONAL |
| | | | | | | |
| Device ID | Section 9.8.2.13 | TBD | | Device ID | Section 9.8.2.13 | OPTIONAL |
| | | | | | | |
| Minimum Battery | Section 9.8.2.14 | TBD | | Minimum Battery | Section 9.8.2.14 | OPTIONAL |
| | | | | | | |
| Update Priority | Section 9.8.2.15 | TBD | | Update Priority | Section 9.8.2.15 | OPTIONAL |
| | | | | | | |
| Version | Section 9.8.2.16 | TBD | | Version | Section 9.8.2.16 | OPTIONAL |
| | | | | | | |
| Wait Info | Section 9.8.2.17 | TBD | | Wait Info | Section 9.8.2.17 | OPTIONAL |
| | | | | | | |
| URI List | Section 9.8.2.18 | TBD | | URI List | Section 9.8.2.18 | OPTIONAL |
| | | | | | | |
| Strict Order | Section 9.8.2.19 | TBD | | Strict Order | Section 9.8.2.19 | OPTIONAL |
| | | | | | | |
| Soft Failure | Section 9.8.2.20 | TBD | | Soft Failure | Section 9.8.2.20 | OPTIONAL |
| | | | | | | |
| Custom | Section 9.8.2.21 | TBD | | Custom | Section 9.8.2.21 | OPTIONAL |
+------------------+------------------+----------------+ +------------------+------------------+----------------+
Authors' Addresses Authors' Addresses
Brendan Moran Brendan Moran
Arm Limited Arm Limited
EMail: Brendan.Moran@arm.com EMail: Brendan.Moran@arm.com
Hannes Tschofenig Hannes Tschofenig
 End of changes. 82 change blocks. 
499 lines changed or deleted 144 lines changed or added

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