< draft-ietf-suit-manifest-10.txt		draft-ietf-suit-manifest-11.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: May 6, 2021 H. Birkholz		Expires: June 11, 2021 H. Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	K. Zandberg		K. Zandberg
	Inria		Inria
	November 02, 2020		December 08, 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-10		draft-ietf-suit-manifest-11
	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 code/data obtained by a recipient (chiefly		a bundle of metadata about code/data obtained by a recipient (chiefly
	the firmware for an IoT device), where to find the that code/data,		the firmware for an IoT device), where to find the that code/data,
	the devices to which it applies, and cryptographic information		the devices to which it applies, and cryptographic information
	protecting the manifest. Software updates and Trusted Invocation		protecting the manifest. Software updates and Trusted Invocation
	both tend to use sequences of common operations, so the manifest		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
	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 May 6, 2021.		This Internet-Draft will expire on June 11, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	5.4.2. Common . . . . . . . . . . . . . . . . . . . . . . . 14		5.4.2. Common . . . . . . . . . . . . . . . . . . . . . . . 14
	5.4.3. Command Sequences . . . . . . . . . . . . . . . . . . 14		5.4.3. Command Sequences . . . . . . . . . . . . . . . . . . 14
	5.4.4. Integrity Check Values . . . . . . . . . . . . . . . 15		5.4.4. Integrity Check Values . . . . . . . . . . . . . . . 15
	5.4.5. Human-Readable Text . . . . . . . . . . . . . . . . . 15		5.4.5. Human-Readable Text . . . . . . . . . . . . . . . . . 15
	5.5. Severable Elements . . . . . . . . . . . . . . . . . . . 15		5.5. Severable Elements . . . . . . . . . . . . . . . . . . . 15
	5.6. Integrated Dependencies and Payloads . . . . . . . . . . 16		5.6. Integrated Dependencies and Payloads . . . . . . . . . . 16
	6. Manifest Processor Behavior . . . . . . . . . . . . . . . . . 16		6. Manifest Processor Behavior . . . . . . . . . . . . . . . . . 16
	6.1. Manifest Processor Setup . . . . . . . . . . . . . . . . 16		6.1. Manifest Processor Setup . . . . . . . . . . . . . . . . 16
	6.2. Required Checks . . . . . . . . . . . . . . . . . . . . . 17		6.2. Required Checks . . . . . . . . . . . . . . . . . . . . . 17
	6.2.1. Minimizing Signature Verifications . . . . . . . . . 19		6.2.1. Minimizing Signature Verifications . . . . . . . . . 19
	6.3. Interpreter Fundamental Properties . . . . . . . . . . . 19		6.3. Interpreter Fundamental Properties . . . . . . . . . . . 20
	6.4. Abstract Machine Description . . . . . . . . . . . . . . 20		6.4. Abstract Machine Description . . . . . . . . . . . . . . 20
	6.5. Special Cases of Component Index and Dependency Index . . 22		6.5. Special Cases of Component Index and Dependency Index . . 23
	6.6. Serialized Processing Interpreter . . . . . . . . . . . . 24		6.6. Serialized Processing Interpreter . . . . . . . . . . . . 24
	6.7. Parallel Processing Interpreter . . . . . . . . . . . . . 24		6.7. Parallel Processing Interpreter . . . . . . . . . . . . . 25
	6.8. Processing Dependencies . . . . . . . . . . . . . . . . . 25		6.8. Processing Dependencies . . . . . . . . . . . . . . . . . 25
	6.9. Multiple Manifest Processors . . . . . . . . . . . . . . 25		6.9. Multiple Manifest Processors . . . . . . . . . . . . . . 26
	7. Creating Manifests . . . . . . . . . . . . . . . . . . . . . 27		7. Creating Manifests . . . . . . . . . . . . . . . . . . . . . 27
	7.1. Compatibility Check Template . . . . . . . . . . . . . . 27		7.1. Compatibility Check Template . . . . . . . . . . . . . . 28
	7.2. Trusted Invocation Template . . . . . . . . . . . . . . . 28		7.2. Trusted Invocation Template . . . . . . . . . . . . . . . 28
	7.3. Component Download Template . . . . . . . . . . . . . . . 28		7.3. Component Download Template . . . . . . . . . . . . . . . 28
	7.4. Install Template . . . . . . . . . . . . . . . . . . . . 29		7.4. Install Template . . . . . . . . . . . . . . . . . . . . 29
	7.5. Install and Transform Template . . . . . . . . . . . . . 29		7.5. Install and Transform Template . . . . . . . . . . . . . 30
	7.6. Integrated Payload Template . . . . . . . . . . . . . . . 30		7.6. Integrated Payload Template . . . . . . . . . . . . . . . 31
	7.7. Load from Nonvolatile Storage Template . . . . . . . . . 31		7.7. Load from Nonvolatile Storage Template . . . . . . . . . 31
	7.8. Load & Decompress from Nonvolatile Storage Template . . . 31		7.8. Load & Decompress from Nonvolatile Storage Template . . . 31
	7.9. Dependency Template . . . . . . . . . . . . . . . . . . . 31		7.9. Dependency Template . . . . . . . . . . . . . . . . . . . 32
	7.9.1. Composite Manifests . . . . . . . . . . . . . . . . . 32		7.9.1. Composite Manifests . . . . . . . . . . . . . . . . . 33
	7.10. Encrypted Manifest Template . . . . . . . . . . . . . . . 32		7.10. Encrypted Manifest Template . . . . . . . . . . . . . . . 33
	7.11. A/B Image Template . . . . . . . . . . . . . . . . . . . 33		7.11. A/B Image Template . . . . . . . . . . . . . . . . . . . 34
	8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 35		8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 35
	8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 35		8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 35
	8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 35		8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 36
	8.3. Delegation Chains . . . . . . . . . . . . . . . . . . . . 35		8.3. Delegation Chains . . . . . . . . . . . . . . . . . . . . 36
	8.4. Authenticated Manifests . . . . . . . . . . . . . . . . . 36		8.4. Authenticated Manifests . . . . . . . . . . . . . . . . . 36
	8.5. Encrypted Manifests . . . . . . . . . . . . . . . . . . . 36		8.5. Encrypted Manifests . . . . . . . . . . . . . . . . . . . 37
	8.6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 36		8.6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 37
	8.6.1. suit-manifest-version . . . . . . . . . . . . . . . . 37		8.6.1. suit-manifest-version . . . . . . . . . . . . . . . . 38
	8.6.2. suit-manifest-sequence-number . . . . . . . . . . . . 37		8.6.2. suit-manifest-sequence-number . . . . . . . . . . . . 38
	8.6.3. suit-reference-uri . . . . . . . . . . . . . . . . . 38		8.6.3. suit-reference-uri . . . . . . . . . . . . . . . . . 38
	8.6.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 38		8.6.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 38
	8.7. text-version-required . . . . . . . . . . . . . . . . . . 40		8.7. text-version-required . . . . . . . . . . . . . . . . . . 40
	8.7.1. suit-coswid . . . . . . . . . . . . . . . . . . . . . 40		8.7.1. suit-coswid . . . . . . . . . . . . . . . . . . . . . 40
	8.7.2. suit-common . . . . . . . . . . . . . . . . . . . . . 40		8.7.2. suit-common . . . . . . . . . . . . . . . . . . . . . 40
	8.7.3. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 42		8.7.3. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 42
	8.7.4. Reporting Policy . . . . . . . . . . . . . . . . . . 44		8.7.4. Reporting Policy . . . . . . . . . . . . . . . . . . 44
	8.7.5. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 46		8.7.5. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 46
	8.7.6. SUIT_Condition . . . . . . . . . . . . . . . . . . . 56		8.7.6. SUIT_Condition . . . . . . . . . . . . . . . . . . . 56
	8.7.7. SUIT_Directive . . . . . . . . . . . . . . . . . . . 60		8.7.7. SUIT_Directive . . . . . . . . . . . . . . . . . . . 60
	8.7.8. Integrity Check Values . . . . . . . . . . . . . . . 67		8.7.8. Integrity Check Values . . . . . . . . . . . . . . . 67
	8.8. Severable Elements . . . . . . . . . . . . . . . . . . . 67		8.8. Severable Elements . . . . . . . . . . . . . . . . . . . 67
	9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 68		9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 68
	10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 68		10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 69
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
	11.1. SUIT Commands . . . . . . . . . . . . . . . . . . . . . 69		11.1. SUIT Commands . . . . . . . . . . . . . . . . . . . . . 69
	11.2. SUIT Parameters . . . . . . . . . . . . . . . . . . . . 71		11.2. SUIT Parameters . . . . . . . . . . . . . . . . . . . . 71
	11.3. SUIT Text Values . . . . . . . . . . . . . . . . . . . . 73		11.3. SUIT Text Values . . . . . . . . . . . . . . . . . . . . 73
	11.4. SUIT Component Text Values . . . . . . . . . . . . . . . 73		11.4. SUIT Component Text Values . . . . . . . . . . . . . . . 73
	11.5. SUIT Algorithm Identifiers . . . . . . . . . . . . . . . 73		11.5. SUIT Algorithm Identifiers . . . . . . . . . . . . . . . 73
	11.5.1. SUIT Digest Algorithm Identifiers . . . . . . . . . 73		11.5.1. SUIT Digest Algorithm Identifiers . . . . . . . . . 73
	11.5.2. SUIT Compression Algorithm Identifiers . . . . . . . 74		11.5.2. SUIT Compression Algorithm Identifiers . . . . . . . 74
	11.5.3. Unpack Algorithms . . . . . . . . . . . . . . . . . 74		11.5.3. Unpack Algorithms . . . . . . . . . . . . . . . . . 74
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 75		12. Security Considerations . . . . . . . . . . . . . . . . . . . 75
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 7 ¶
	2. At the end of each section in the dependent: The corresponding		2. At the end of each section in the dependent: The corresponding
	section in each dependency has been executed.		section in each dependency has been executed.
	If the interpreter does not support dependencies and a manifest		If the interpreter does not support dependencies and a manifest
	specifies a dependency, then the interpreter MUST reject the		specifies a dependency, then the interpreter MUST reject the
	manifest.		manifest.
	If a Recipient supports groups of interdependent components (a		If a Recipient supports groups of interdependent components (a
	Component Set), then it SHOULD verify that all Components in the		Component Set), then it SHOULD verify that all Components in the
	Component Set are specified by one update, where an update is		Component Set are specified by one update, that is: a single manifest
	composed of all the TODO: Wording		and all its dependencies that together:
	manifest and its dependencies. This manifest is called the Root		1. have sufficient permissions imparted by their signatures
	Manifest.
			2. specify a digest and a payload for every Component in the
			Component Set.
			The single dependent manifest is sometimes called a Root Manifest.
	6.2.1. Minimizing Signature Verifications		6.2.1. Minimizing Signature Verifications
	Signature verification can be energy and time expensive on a		Signature verification can be energy and time expensive on a
	constrained device. MAC verification is typically unaffected by		constrained device. MAC verification is typically unaffected by
	these concerns. A Recipient MAY choose to parse and execute only the		these concerns. A Recipient MAY choose to parse and execute only the
	SUIT_Common section of the manifest prior to signature verification,		SUIT_Common section of the manifest prior to signature verification,
	if all of the below apply:		if all of the below apply:
	- The Authentication Block contains a COSE_Sign_Tagged or		- The Authentication Block contains a COSE_Sign_Tagged or
	skipping to change at page 45, line 21 ¶		skipping to change at page 45, line 21 ¶
	| | |		| | |
	| suit-send-sysinfo-success | Add system information when the |		| suit-send-sysinfo-success | Add system information when the |
	| | command succeeds |		| | command succeeds |
	| | |		| | |
	| suit-send-sysinfo-failure | Add system information when the |		| suit-send-sysinfo-failure | Add system information when the |
	| | command fails |		| | command fails |
	+-----------------------------+-------------------------------------+		+-----------------------------+-------------------------------------+
	Any or all of these policies may be enabled at once.		Any or all of these policies may be enabled at once.
	At the completion of each command, a recipient MAY forward that		At the completion of each command, a Manifest Processor MAY forward
	command's reporting policy, the result of the command, the current		information about the command to a Reporting Engine, which is
	set of parameters, and the system information consumed by the command		responsible for reporting boot or update status to a third party.
	to a TODO		The Reporting Engine is entirely implementation-defined, the
			reporting policy simply facilitates the Reporting Engine's interface
			to the SUIT Manifest Processor.
	several information elements are provided to an implementation		The information elements provided to the Reporting Engine are:
	defined subsystem, the Reporting Engine:
	- The reporting policies		- The reporting policy
	- The result of the command		- The result of the command
	- The parameters consumed by the command		- The values of parameters consumed by the command
	- The system information consumed by the command		- The system information consumed by the command
			Together, these elements are called a Record. A group of Records is
			a Report.
	If the component index is set to True or an array when a command is		If the component index is set to True or an array when a command is
	executed with a non-zero reporting policy, then the Reporting Engine		executed with a non-zero reporting policy, then the Reporting Engine
	MUST receive one Record for each Component, in the order expressed in		MUST receive one Record for each Component, in the order expressed in
	the Components list or the component index array, respectively. If		the Components list or the component index array. If the dependency
	the dependency index is set to True or an array when a command is		index is set to True or an array when a command is executed with a
	executed with a non-zero reporting policy, then the Reporting Engine		non-zero reporting policy, then the Reporting Engine MUST receive one
	MUST receive one Record for each Dependency, in the order expressed		Record for each Dependency, in the order expressed in the
	in the Dependencies list or the component index array, respectively.		Dependencies list or the component index array, respectively.
	This specification does define a particular format of Records or		This specification does not define a particular format of Records or
	Reports. This specification only defines hints to the Reporting		Reports. This specification only defines hints to the Reporting
	Engine for which Records it should aggregate into the Report. The		Engine for which Records it should aggregate into the Report. The
	Reporting Engine MAY choose to ignore these hints and apply its own		Reporting Engine MAY choose to ignore these hints and apply its own
	policy instead.		policy instead.
	When used in a Invocation Process, the report MAY form the basis of		When used in a Invocation Procedure, the report MAY form the basis of
	an attestation report. When used in an Update Process, the report		an attestation report. When used in an Update Process, the report
	MAY form the basis for one or more log entries.		MAY form the basis for one or more log entries.
	8.7.5. SUIT_Parameters		8.7.5. SUIT_Parameters
	Many conditions and directives require additional information. That		Many conditions and directives require additional information. That
	information is contained within parameters that can be set in a		information is contained within parameters that can be set in a
	consistent way. This allows reduction of manifest size and		consistent way. This allows reduction of manifest size and
	replacement of parameters from one manifest to the next.		replacement of parameters from one manifest to the next.
	skipping to change at page 62, line 28 ¶		skipping to change at page 62, line 28 ¶
	components supported)		components supported)
	3. An array of unsigned integers (REQUIRED to implement in parser		3. An array of unsigned integers (REQUIRED to implement in parser
	ONLY IF 3 or more components supported)		ONLY IF 3 or more components supported)
	If the following commands apply to ONE component, an unsigned integer		If the following commands apply to ONE component, an unsigned integer
	index into the component list is used. If the following commands		index into the component list is used. If the following commands
	apply to ALL components, then the boolean value "True" is used		apply to ALL components, then the boolean value "True" is used
	instead of an index. If the following commands apply to more than		instead of an index. If the following commands apply to more than
	one, but not all components, then an array of unsigned integer		one, but not all components, then an array of unsigned integer
	indices into the component list is used. TODO: Component list		indices into the component list is used. See Section 6.5 for more
			details.
	If the following commands apply to NO components, then the boolean		If the following commands apply to NO components, then the boolean
	value "False" is used. When suit-directive-set-dependency-index is		value "False" is used. When suit-directive-set-dependency-index is
	used, suit-directive-set-component-index = False is implied. When		used, suit-directive-set-component-index = False is implied. When
	suit-directive-set-component-index is used, suit-directive-set-		suit-directive-set-component-index is used, suit-directive-set-
	dependency-index = False is implied.		dependency-index = False is implied.
	If component index is set to True when a command is invoked, then the		If component index is set to True when a command is invoked, then the
	command applies to all components, in the order they appear in suit-		command applies to all components, in the order they appear in suit-
	common-components. When the Manifest Processor invokes a command		common-components. When the Manifest Processor invokes a command
	while the component index is set to True, it must execute the command		while the component index is set to True, it must execute the command
	once for each possible component index, ensuring that the command		once for each possible component index, ensuring that the command
	receives the parameters corresponding to that component index.		receives the parameters corresponding to that component index.
	8.7.7.2. suit-directive-set-dependency-index		8.7.7.2. suit-directive-set-dependency-index
	Set Dependency Index defines the manifest to which successive		Set Dependency Index defines the manifest to which successive
	directives and conditions will apply. The supplied argument MUST be		directives and conditions will apply. The supplied argument MUST be
	either a boolean or an unsigned integer index into the dependencies.		either a boolean or an unsigned integer index into the dependencies,
	If the following directives apply to ALL dependencies, then the		or an array of unsigned integer indices into the list of
	boolean value "True" is used instead of an index. If the following		dependencies. If the following directives apply to ALL dependencies,
	directives apply to NO dependencies, then the boolean value "False"		then the boolean value "True" is used instead of an index. If the
	is used. When suit-directive-set-component-index is used, suit-		following directives apply to NO dependencies, then the boolean value
	directive-set-dependency-index = False is implied. When suit-		"False" is used. When suit-directive-set-component-index is used,
			suit-directive-set-dependency-index = False is implied. When suit-
	directive-set-dependency-index is used, suit-directive-set-component-		directive-set-dependency-index is used, suit-directive-set-component-
	index = False is implied. TODO: Component list|Dependency List		index = False is implied.
	If dependency index is set to True when a command is invoked, then		If dependency index is set to True when a command is invoked, then
	the command applies to all dependencies, in the order they appear in		the command applies to all dependencies, in the order they appear in
	suit-common-components. When the Manifest Processor invokes a		suit-common-components. When the Manifest Processor invokes a
	command while the dependency index is set to True, it must execute		command while the dependency index is set to True, the Manifest
	the command once for each possible dependency index, ensuring that		Processor MUST execute the command once for each possible dependency
	the command receives the parameters corresponding to that dependency		index, ensuring that the command receives the parameters
	index.		corresponding to that dependency index. If the dependency index is
			set to an array of unsigned integers, then the Manifest Processor
			MUST execute the command once for each listed dependency index,
			ensuring that the command receives the parameters corresponding to
			that dependency index.
			See Section 6.5 for more details.
	Typical operations that require suit-directive-set-dependency-index		Typical operations that require suit-directive-set-dependency-index
	include setting a source URI or Encryption Information, invoking		include setting a source URI or Encryption Information, invoking
	"Fetch," or invoking "Process Dependency" for an individual		"Fetch," or invoking "Process Dependency" for an individual
	dependency.		dependency.
	8.7.7.3. suit-directive-try-each		8.7.7.3. suit-directive-try-each
	This command runs several SUIT_Command_Sequence instances, one after		This command runs several SUIT_Command_Sequence instances, one after
	another, in a strict order. Use this command to implement a "try/		another, in a strict order. Use this command to implement a "try/
	skipping to change at page 76, line 38 ¶		skipping to change at page 76, line 38 ¶
	[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-cbor-tags-oid]		[I-D.ietf-cbor-tags-oid]
	Bormann, C. and S. Leonard, "Concise Binary Object		Bormann, C. and S. Leonard, "Concise Binary Object
	Representation (CBOR) Tags for Object Identifiers", draft-		Representation (CBOR) Tags for Object Identifiers", draft-
	ietf-cbor-tags-oid-02 (work in progress), October 2020.		ietf-cbor-tags-oid-03 (work in progress), November 2020.
	[I-D.ietf-sacm-coswid]		[I-D.ietf-sacm-coswid]
	Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.		Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
	Waltermire, "Concise Software Identification Tags", draft-		Waltermire, "Concise Software Identification Tags", draft-
	ietf-sacm-coswid-15 (work in progress), May 2020.		ietf-sacm-coswid-16 (work in progress), November 2020.
	[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-14 (work in progress),		draft-ietf-suit-architecture-14 (work in progress),
	October 2020.		October 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-08 (work in progress),		draft-ietf-suit-information-model-08 (work in progress),
	October 2020.		October 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-12 (work in		Architecture", draft-ietf-teep-architecture-13 (work in
	progress), July 2020.		progress), November 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
	the application/zstd Media Type", draft-kucherawy-		the application/zstd Media Type", draft-kucherawy-
	rfc8478bis-05 (work in progress), April 2020.		rfc8478bis-05 (work in progress), April 2020.
	[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950,		Specification version 3.3", RFC 1950,
	DOI 10.17487/RFC1950, May 1996,		DOI 10.17487/RFC1950, May 1996,
	<https://www.rfc-editor.org/info/rfc1950>.		<https://www.rfc-editor.org/info/rfc1950>.
End of changes. 31 change blocks.
	57 lines changed or deleted		73 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/