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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/