< draft-ietf-suit-information-model-02.txt		draft-ietf-suit-information-model-03.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: July 22, 2019 H. Birkholz		Expires: January 9, 2020 H. Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	January 18, 2019		July 08, 2019
	Firmware Updates for Internet of Things Devices - An Information Model		Firmware Updates for Internet of Things Devices - An Information Model
	for Manifests		for Manifests
	draft-ietf-suit-information-model-02		draft-ietf-suit-information-model-03
	Abstract		Abstract
	Vulnerabilities with Internet of Things (IoT) devices have raised the		Vulnerabilities with Internet of Things (IoT) devices have raised the
	need for a solid and secure firmware update mechanism that is also		need for a solid and secure firmware update mechanism that is also
	suitable for constrained devices. Incorporating such update		suitable for constrained devices. Incorporating such an update
	mechanism to fix vulnerabilities, to update configuration settings as		mechanism to fix vulnerabilities, to update configuration settings,
	well as adding new functionality is recommended by security experts.		as well as adding new functionality is recommended by security
			experts.
	One component of such a firmware update is the meta-data, or		One component of such a firmware update is a concise and machine-
	manifest, that describes the firmware image(s) and offers appropriate		processable meta-data document, or manifest, that describes the
	protection. This document describes all the information that must be		firmware image(s) and offers appropriate protection. This document
	present in the manifest.		describes the information that must be present in the manifest.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 July 22, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 31 ¶		skipping to change at page 2, line 31 ¶
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
	3. Manifest Information Elements . . . . . . . . . . . . . . . . 5		2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
	3.1. Manifest Element: version identifier of the manifest		3. Manifest Information Elements . . . . . . . . . . . . . . . . 6
	structure . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Manifest Element: Version ID of the manifest structure . 6
	3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6		3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6
	3.3. Manifest Element: Vendor ID Condition . . . . . . . . . . 6		3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 6
	3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 6		3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7
	3.4. Manifest Element: Class ID Condition . . . . . . . . . . 6		3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7
	3.4.1. Example 1: Different Classes . . . . . . . . . . . . 7		3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8
	3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 7		3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 8
	3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 8		3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9
	3.5. Manifest Element: Precursor Image Digest Condition . . . 8		3.5. Manifest Element: Precursor Image Digest Condition . . . 9
	3.6. Manifest Element: Required Image Version List . . . . . . 8		3.6. Manifest Element: Required Image Version List . . . . . . 9
	3.7. Manifest Element: Best-Before timestamp condition . . . . 9		3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10
	3.8. Manifest Element: Payload Format . . . . . . . . . . . . 9		3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10
	3.9. Manifest Element: Processing Steps . . . . . . . . . . . 9		3.9. Manifest Element: Processing Steps . . . . . . . . . . . 10
	3.10. Manifest Element: Storage Location . . . . . . . . . . . 9		3.10. Manifest Element: Storage Location . . . . . . . . . . . 11
	3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 10		3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11
	3.10.2. Example 2: File System . . . . . . . . . . . . . . . 10		3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11
	3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 10		3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 11
	3.11. Manifest Element: Component Identifier . . . . . . . . . 10		3.11. Manifest Element: Component Identifier . . . . . . . . . 11
	3.12. Manifest Element: URIs . . . . . . . . . . . . . . . . . 10		3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12
	3.13. Manifest Element: Payload Digest . . . . . . . . . . . . 11		3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 12
	3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 11		3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 12
	3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 11		3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13
	3.16. Manifest Element: Directives . . . . . . . . . . . . . . 11		3.16. Manifest Element: Additional installation instructions . 13
	3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 12		3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 13
	3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 12		3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 13
	3.19. Manifest Element: Content Key Distribution Method . . . . 12		3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14
	3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 12		3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14
	3.21. Manifest Element: Load-time metadata . . . . . . . . . . 13		3.21. Manifest Element: Load-time metadata . . . . . . . . . . 14
	4. Motivation for Manifest Fields . . . . . . . . . . . . . . . 13		3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 14
	4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13		3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15
	4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 13		3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15
	4.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 13		4. Motivation for Manifest Fields . . . . . . . . . . . . . . . 15
	4.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 14		4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 15
	4.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 14		4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16
	4.2.4. Threat MFT4: The target device misinterprets the type		4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16
	of payload . . . . . . . . . . . . . . . . . . . . . 15		4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old
	4.2.5. Threat MFT5: The target device installs the payload		Firmware . . . . . . . . . . . . . . . . . . . . . . 16
	to the wrong location . . . . . . . . . . . . . . . . 15		4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 16
	4.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 15		4.2.4. THREAT.IMG.FORMAT: The target device misinterprets
	4.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 16		the type of payload . . . . . . . . . . . . . . . . . 17
	4.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 16		4.2.5. THREAT.IMG.LOCATION: The target device installs the
	4.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 16		payload to the wrong location . . . . . . . . . . . . 17
	4.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 17		4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
	4.2.11. Threat MFT11: Reverse Engineering Of Firmware Image		payload hosting . . . . . . . . . . . . . . . . . . . 18
	for Vulnerability Analysis . . . . . . . . . . . . . 18		4.2.7. THREAT.NET.MITM . . . . . . . . . . . . . . . . . . . 18
	4.2.12. Threat MFT12: Overriding Critical Manifest Elements . 18		4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 18
	4.2.13. Threat MFT13: Manifest Element Exposure . . . . . . . 18		4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 18
	4.3. Security Requirements . . . . . . . . . . . . . . . . . . 19		4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
	4.3.1. Security Requirement MFSR1: Monotonic Sequence		images . . . . . . . . . . . . . . . . . . . . . . . 18
	Numbers . . . . . . . . . . . . . . . . . . . . . . . 19		4.2.11. THREAT.UPD.INTEROP: Unqualified Firmware . . . . . . 19
	4.3.2. Security Requirement MFSR2: Vendor, Device-type		4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of
	Identifiers . . . . . . . . . . . . . . . . . . . . . 19		Firmware Image for Vulnerability Analysis . . . . . . 20
	4.3.3. Security Requirement MFSR3: Best-Before Timestamps . 19		4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
	4.3.4. Security Requirement MFSR5: Cryptographic		Elements . . . . . . . . . . . . . . . . . . . . . . 20
	Authenticity . . . . . . . . . . . . . . . . . . . . 20		4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
	4.3.5. Security Requirement MFSR4a: Authenticated Payload		Exposure . . . . . . . . . . . . . . . . . . . . . . 21
	Type . . . . . . . . . . . . . . . . . . . . . . . . 20		4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 21
	4.3.6. Security Requirement MFSR4b: Authenticated Storage		4.3. Security Requirements . . . . . . . . . . . . . . . . . . 21
	Location . . . . . . . . . . . . . . . . . . . . . . 20		4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 21
	4.3.7. Security Requirement MFSR4c: Authenticated Remote		4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 22
	Resource Location . . . . . . . . . . . . . . . . . . 20		4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 22
	4.3.8. Security Requirement MFSR4d: Secure Boot . . . . . . 21		4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 22
	4.3.9. Security Requirement MFSR4e: Authenticated precursor		4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 22
	images . . . . . . . . . . . . . . . . . . . . . . . 21		4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC:
	4.3.10. Security Requirement MFSR4f: Authenticated Vendor and		Authenticated Storage Location . . . . . . . . . . . 23
	Class IDs . . . . . . . . . . . . . . . . . . . . . . 21		4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote
	4.3.11. Security Requirement MFSR4f: Authenticated Vendor and		Resource Location . . . . . . . . . . . . . . . . . . 23
	Class IDs . . . . . . . . . . . . . . . . . . . . . . 21		4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 23
			4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
	4.3.12. Security Requirement MFSR6: Rights Require		images . . . . . . . . . . . . . . . . . . . . . . . 23
	Authenticity . . . . . . . . . . . . . . . . . . . . 21		4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
	4.3.13. Security Requirement MFSR7: Firmware encryption . . . 22		Class IDs . . . . . . . . . . . . . . . . . . . . . . 23
	4.3.14. Security Requirement MFSR8: Access Control Lists . . 22		4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 24
	4.3.15. Security Requirement MFSR9: Encrypted Manifests . . . 22		4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 24
	4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 23		4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 24
	4.4.1. Use Case MFUS1: Installation Instructions . . . . . . 23		4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 25
	4.4.2. Use Case MFUS2: Override Non-Critical Manifest		4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 25
	Elements . . . . . . . . . . . . . . . . . . . . . . 23		4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 25
	4.4.3. Use Case MFUS3: Modular Update . . . . . . . . . . . 24		4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
	4.4.4. Use Case MFUS4: Multiple Authorisations . . . . . . . 24		Instructions . . . . . . . . . . . . . . . . . . . . 25
	4.4.5. Use Case MFUS5: Multiple Payload Formats . . . . . . 24		4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 26
	4.4.6. Use Case MFUS6: Prevent Confidential Information		4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest
	Disclosures . . . . . . . . . . . . . . . . . . . . . 24		Elements . . . . . . . . . . . . . . . . . . . . . . 26
	4.4.7. Use Case MFUS7: Prevent Devices from Unpacking		4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 27
	Unknown Formats . . . . . . . . . . . . . . . . . . . 24		4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 27
	4.4.8. Use Case MFUS8: Specify Version Numbers of Target		4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 27
	Firmware . . . . . . . . . . . . . . . . . . . . . . 25		4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
	4.4.9. Use Case MFUS9: Enable Devices to Choose Between		Information Disclosures . . . . . . . . . . . . . . . 27
	Images . . . . . . . . . . . . . . . . . . . . . . . 25		4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from
	4.4.10. Use Case MFUS10: Secure Boot Using Manifests . . . . 25		Unpacking Unknown Formats . . . . . . . . . . . . . . 27
	4.4.11. Use Case MFUS11: Decompress on Load . . . . . . . . . 25		4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version
	4.4.12. Use Case MFUS12: Payload in Manifest . . . . . . . . 26		Numbers of Target Firmware . . . . . . . . . . . . . 28
	4.4.13. Use Case MFUS13: Simple Parsing . . . . . . . . . . . 26		4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose
	4.5. Usability Requirements . . . . . . . . . . . . . . . . . 26		Between Images . . . . . . . . . . . . . . . . . . . 28
	4.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 26		4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
	4.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 26		Manifests . . . . . . . . . . . . . . . . . . . . . . 28
	4.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 27		4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 28
	4.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 28		4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 28
	4.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 28		4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 29
	4.5.6. Usability Requirement MFUR6 . . . . . . . . . . . . . 28		4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
	4.5.7. Usability Requirement MFUR7 . . . . . . . . . . . . . 28		Manifest . . . . . . . . . . . . . . . . . . . . . . 29
	4.5.8. Usability Requirement MFUR8 . . . . . . . . . . . . . 29		4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 29
	4.5.9. Usability Requirement MFUR9: Bootable Manifest . . . 29		4.5. Usability Requirements . . . . . . . . . . . . . . . . . 29
	4.5.10. Usability Requirement MFUR10: Load-Time Information . 29		4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 29
	4.5.11. Usability Requirement MFUR11: Payload in Manifest		4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
	Superstructure . . . . . . . . . . . . . . . . . . . 29		Resource Location . . . . . . . . . . . . . . . . . . 30
	4.5.12. Usability Requirement MFUR12: Simple Parsing . . . . 30		4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 30
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 30		4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 31
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 31
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 32
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 32
	8.1. Normative References . . . . . . . . . . . . . . . . . . 30		4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 32
	8.2. Informative References . . . . . . . . . . . . . . . . . 31		4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 32
	Appendix A. Mailing List Information . . . . . . . . . . . . . . 32		4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 33
			4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 33
			4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
			Manifest . . . . . . . . . . . . . . . . . . . . . . 33
			5. Security Considerations . . . . . . . . . . . . . . . . . . . 34
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
			7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
			8.1. Normative References . . . . . . . . . . . . . . . . . . 34
			8.2. Informative References . . . . . . . . . . . . . . . . . 35
			Appendix A. Mailing List Information . . . . . . . . . . . . . . 36
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	The information model describes all the information elements required		The information model describes all the information elements required
	to secure firmware updates of IoT devices from the threats described		to secure firmware updates of IoT devices from the threats described
	in Section 4.1 and enable the user stories captured in Section 4.4.		in Section 4.1 and enables the user stories captured in Section 4.4.
	These threats and user stories are not intended to be an exhaustive		These threats and user stories are not intended to be an exhaustive
	list of the threats against IoT devices, nor of the possible use		list of the threats against IoT devices, nor of the possible user
	cases of firmware update; instead they are intended to describe the		stories that describe how to conduct a firmware update. Instead they
	threats against firmware update in isolation and provide sufficient		are intended to describe the threats against firmware updates in
	motivation to provide information elements that cover a wide range of		isolation and provide sufficient motivation to specify the
	use cases. The information model does not define the encoding,		information elements that cover a wide range of user stories. The
			information model does not define the serialization, encoding,
	ordering, or structure of information elements, only their semantics.		ordering, or structure of information elements, only their semantics.
	Because the information model covers a wide range of user stories and		Because the information model covers a wide range of user stories and
	a wide range of threats, not all information elements apply to all		a wide range of threats, not all information elements apply to all
	scenarios. As a result, many information elements could be		scenarios. As a result, various information elements could be
	considered optional to implement and optional to use, depending on		considered optional to implement and optional to use, depending on
	which threats exist in a particular system and which use cases are		which threats exist in a particular domain of application and which
	required. Elements marked as mandatory provide baseline security and		user stories are required. Elements marked as mandatory provide
	usability properties that are expected to be required for most		baseline security and usability properties that are expected to be
	applications. Those elements are mandatory to implement and		required for most applications. Those elements are mandatory to
	mandatory to use. Elements marked as recommended provide important		implement and mandatory to use. Elements marked as recommended
	security or usability properties that are needed on most devices.		provide important security or usability properties that are needed on
	Elements marked as optional enable security or usability properties		most devices. Elements marked as optional enable security or
	that are useful in some applications.		usability properties that are useful in some applications.
	2. Conventions and Terminology		The definition of some of the information elements include examples
			that illustrate their semantics and how they are intended to be used.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		2. Conventions and Terminology
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].
	This document uses terms defined in [I-D.ietf-suit-architecture].		This document uses terms defined in [I-D.ietf-suit-architecture].
	The term 'Operator' refers to both, Device and Network Operator.		The term 'Operator' refers to both, Device and Network Operator.
			This document treats devices with a homogeneous storage architecture
			as devices with a heterogeneous storage architecture, but with a
			single storage subsystem.
			2.1. Requirements Notation
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. Manifest Information Elements		3. Manifest Information Elements
	Each manifest element is anchored in a security requirement or a		Each manifest information element is anchored in a security
	usability requirement. The manifest elements are described below and		requirement or a usability requirement. The manifest elements are
	justified by their requirements.		described below, justified by their requirements.
	3.1. Manifest Element: version identifier of the manifest structure		3.1. Manifest Element: Version ID of the manifest structure
	An identifier that describes which iteration of the manifest format		An identifier that describes which iteration of the manifest format
	is contained in the structure.		is contained in the structure.
	This element is MANDATORY and must be present in order to allow		This element is MANDATORY and MUST be present in order to allow
	devices to identify the version of the manifest data model that is in		devices to identify the version of the manifest data model that is in
	use.		use.
	3.2. Manifest Element: Monotonic Sequence Number		3.2. Manifest Element: Monotonic Sequence Number
	A monotonically increasing sequence number. For convenience, the		A monotonically increasing sequence number. For convenience, the
	monotonic sequence number MAY be a UTC timestamp. This allows global		monotonic sequence number MAY be a UTC timestamp. This allows global
	synchronisation of sequence numbers without any additional		synchronisation of sequence numbers without any additional
	management.		management. This number MUST be easily accessible so that code
			choosing one out of several manifests can choose which is the latest.
	This element is MANDATORY and is necessary to prevent malicious		This element is MANDATORY and is necessary to prevent malicious
	actors from reverting a firmware update against the wishes of the		actors from reverting a firmware update against the policies of the
	relevant authority.		relevant authority.
	Implements: Security Requirement MFSR1.		Implements: REQ.SEC.SEQUENCE (Section 4.3.1)
	3.3. Manifest Element: Vendor ID Condition		3.3. Manifest Element: Vendor ID
	Vendor IDs MUST be unique. This is to prevent similarly, or		Vendor IDs MUST be unique. This is to prevent similarly, or
	identically named entities from different geographic regions from		identically named entities from different geographic regions from
	colliding in their customer's infrastructure. Recommended practice		colliding in their customer's infrastructure. Recommended practice
	is to use type 5 UUIDs with the vendor's domain name and the UUID DNS		is to use [RFC4122] version 5 UUIDs with the vendor's domain name and
	prefix. Other options include type 1 and type 4 UUIDs.		the UUID DNS prefix. Other options include type 1 and type 4 UUIDs.
	This ID is RECOMMENDED and helps to distinguish between identically		Vendor ID is not intended to be a human-readable element. It is
	named products from different vendors.		intended for match/mismatch comparison only.
	Implements: Security Requirement MFSR2, MFSR4f.		The use of a Vendor ID is RECOMMENDED. It helps to distinguish
			between identically named products from different vendors.
			Implements: REQ.SEC.COMPATIBLE (Section 4.3.2),
			REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).
	3.3.1. Example: Domain Name-based UUIDs		3.3.1. Example: Domain Name-based UUIDs
	Vendor A creates a UUID based on their domain name:		Vendor A creates a UUID based on their domain name:
	vendorId = UUID5(DNS, "vendor-a.com")		vendorId = UUID5(DNS, "vendor-a.com")
	Because the DNS infrastructure prevents multiple registrations of the		Because the DNS infrastructure prevents multiple registrations of the
	same domain name, this UUID is guaranteed to be unique. Because the		same domain name, this UUID is guaranteed to be unique. Because the
	domain name is known, this UUID is reproducible. Type 1 and type 4		domain name is known, this UUID is reproducible. Type 1 and type 4
	UUIDs produce similar guarantees of uniqueness, but not		UUIDs produce similar guarantees of uniqueness, but not
	reproducibility.		reproducibility.
	3.4. Manifest Element: Class ID Condition		This approach creates a contention when a vendor changes its name or
			relinquishes control of a domain name. In this scenario, it is
			possible that another vendor would start using that same domain name.
			However, this UUID is not proof of identity; a device's trust in a
			vendor must be anchored in a cryptographic key, not a UUID.
	A device "Class" is defined as any device that can accept the same		3.4. Manifest Element: Class ID
	firmware update without modification. Class Identifiers MUST be
	unique within a Vendor ID. This is to prevent similarly, or
	identically named devices colliding in their customer's
	infrastructure. Recommended practice is to use type 5 UUIDs with the
	model, hardware revision, etc. and use the Vendor ID as the UUID
	prefix. Other options include type 1 and type 4 UUIDs. Classes MAY
	be implemented in a more granular way. Classes MUST NOT be
	implemented in a less granular way. Class ID can encompass model
	name, hardware revision, software revision. Devices MAY have
	multiple Class IDs.
	Note Well: Class ID is not a human-readable element. It is intended		A device "Class" is a set of different device types that can accept
	for match/mismatch use only.		the same firmware update without modification. Class IDs MUST be
			unique within the scope of a Vendor ID. This is to prevent
			similarly, or identically named devices colliding in their customer's
			infrastructure.
	This ID is RECOMMENDED and allows devices to determine applicability		Recommended practice is to use [RFC4122] version 5 UUIDs with as much
	of a firmware in an unambiguous way.		information as necessary to define firmware compatibility. Possible
			information used to derive the class UUID includes:
	Implements: Security Requirement MFSR2, MFSR4f.		o model name or number
			o hardware revision
			o runtime library version
			o bootloader version
			o ROM revision
			o silicon batch number
			The Class Identifier UUID SHOULD use the Vendor ID as the UUID
			prefix. Other options include version 1 and 4 UUIDs. Classes MAY be
			more granular than is required to identify firmware compatibility.
			Classes MUST NOT be less granular than is required to identify
			firmware compatibility. Devices MAY have multiple Class IDs.
			Class ID is not intended to be a human-readable element. It is
			intended for match/mismatch comparison only.
			The use of Class ID is RECOMMENDED. It allows devices to determine
			applicability of a firmware in an unambiguous way.
			If Class ID is not implemented, then each logical device class MUST
			use a unique Root of Trust for authorisation.
			Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2),
			REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).
	3.4.1. Example 1: Different Classes		3.4.1. Example 1: Different Classes
	Vendor A creates product Z and product Y. The firmware images of		Vendor A creates product Z and product Y. The firmware images of
	products Z and Y are not interchangeable. Vendor A creates UUIDs as		products Z and Y are not interchangeable. Vendor A creates UUIDs as
	follows:		follows:
	- vendorId = UUID5(DNS, "vendor-a.com")		o vendorId = UUID5(DNS, "vendor-a.com")
	- ZclassId = UUID5(vendorId, "Product Z")		o ZclassId = UUID5(vendorId, "Product Z")
	- YclassId = UUID5(vendorId, "Product Y")		o YclassId = UUID5(vendorId, "Product Y")
	This ensures that Vendor A's Product Z cannot install firmware for		This ensures that Vendor A's Product Z cannot install firmware for
	Product Y and Product Y cannot install firmware for Product Z.		Product Y and Product Y cannot install firmware for Product Z.
	3.4.2. Example 2: Upgrading Class ID		3.4.2. Example 2: Upgrading Class ID
	Vendor A creates product X. Later, Vendor A adds a new feature to		Vendor A creates product X. Later, Vendor A adds a new feature to
	product X, creating product X v2. Product X requires a firmware		product X, creating product X v2. Product X requires a firmware
	update to work with firmware intended for product X v2.		update to work with firmware intended for product X v2.
	Vendor A creates UUIDs as follows:		Vendor A creates UUIDs as follows:
	- vendorId = UUID5(DNS, "vendor-a.com")		o vendorId = UUID5(DNS, "vendor-a.com")
	- XclassId = UUID5(vendorId, "Product X")
	- Xv2classId = UUID5(vendorId, "Product X v2")		o XclassId = UUID5(vendorId, "Product X")
			o Xv2classId = UUID5(vendorId, "Product X v2")
	When product X receives the firmware update necessary to be		When product X receives the firmware update necessary to be
	compatible with product X v2, part of the firmware update changes the		compatible with product X v2, part of the firmware update changes the
	class ID to Xv2classId.		class ID to Xv2classId.
	3.4.3. Example 3: Shared Functionality		3.4.3. Example 3: Shared Functionality
	Vendor A produces two products, product X and product Y. These		Vendor A produces two products, product X and product Y. These
	components share a common core (such as an operating system), but		components share a common core (such as an operating system), but
	have different applications. The common core and the applications		have different applications. The common core and the applications
	can be updated independently. To enable X and Y to receive the same		can be updated independently. To enable X and Y to receive the same
	common core update, they require the same class ID. To ensure that		common core update, they require the same class ID. To ensure that
	only product X receives application X and only product Y receives		only product X receives application X and only product Y receives
	application Y, product X and product Y must have different class IDs.		application Y, product X and product Y must have different class IDs.
	The vendor creates Class IDs as follows:		The vendor creates Class IDs as follows:
	- vendorId = UUID5(DNS, "vendor-a.com")		o vendorId = UUID5(DNS, "vendor-a.com")
	- XclassId = UUID5(vendorId, "Product X")		o XclassId = UUID5(vendorId, "Product X")
	- YclassId = UUID5(vendorId, "Product Y")		o YclassId = UUID5(vendorId, "Product Y")
	- CommonClassId = UUID5(vendorId, "common core")		o CommonClassId = UUID5(vendorId, "common core")
	Product X matches against both XclassId and CommonClassId. Product Y		Product X matches against both XclassId and CommonClassId. Product Y
	matches against both YclassId and CommonClassId.		matches against both YclassId and CommonClassId.
	3.5. Manifest Element: Precursor Image Digest Condition		3.5. Manifest Element: Precursor Image Digest Condition
	When a precursor image is required by the payload format, a precursor		When a precursor image is required by the payload format, a precursor
	image digest condition MUST be present in the conditions list. The		image digest condition MUST be present in the conditions list. The
	precursor image may be installed or stored as a candidate.		precursor image may be installed or stored as a candidate.
	This element is MANDATORY for differential updates. Otherwise, it is		This element is OPTIONAL to implement.
	not needed.
	Implements: Security Requirement MFSR4e		Enables feature: differential updates.
			Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
	3.6. Manifest Element: Required Image Version List		3.6. Manifest Element: Required Image Version List
	When a payload applies to multiple versions of a firmware, the		When a payload applies to multiple versions of a firmware, the
	required image version list specifies which versions must be present		required image version list specifies which versions must be present
	for the update to be applied. This allows the update author to		for the update to be applied. This allows the update author to
	target specific versions of firmware for an update, while excluding		target specific versions of firmware for an update, while excluding
	those to which it should not be applied.		those to which it should not be applied.
	Where an update can only be applied over specific predecessor		Where an update can only be applied over specific predecessor
	versions, that version MUST be specified by the Required Image		versions, that version MUST be specified by the Required Image
	Version List.		Version List.
	This element is OPTIONAL.		This element is OPTIONAL.
	Implements: MFUR7		Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7)
	3.7. Manifest Element: Best-Before timestamp condition		3.7. Manifest Element: Expiration Time
	This element tells a device the last application time. This is only		This element tells a device the time at which the manifest expires
	usable in conjunction with a secure clock.		and should no longer be used. This is only usable in conjunction
			with a secure source of time.
	This element is OPTIONAL and MAY enable use cases where a secure		This element is OPTIONAL and MAY enable user stories where a secure
	clock is provided and firmware is intended to expire regularly.		source of time is provided and firmware is intended to expire
			predictably.
	Implements: Security Requirement MFSR3		Implements: REQ.SEC.EXP (Section 4.3.3)
	3.8. Manifest Element: Payload Format		3.8. Manifest Element: Payload Format
	The format of the payload must be indicated to devices is in an		The format of the payload MUST be indicated to devices is in an
	unambiguous way. This element provides a mechanism to describe the		unambiguous way. This element provides a mechanism to describe the
	payload format, within the signed metadata.		payload format, within the signed metadata.
	This element is MANDATORY and MUST be present to enable devices to		This element is MANDATORY and MUST be present to enable devices to
	decode payloads correctly.		decode payloads correctly.
	Implements: Security Requirement MFSR4a, Usability Requirement MFUR5		Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT
			(Section 4.5.5)
	3.9. Manifest Element: Processing Steps		3.9. Manifest Element: Processing Steps
	A list of all payload processors necessary to process a nested format		A representation of the Processing Steps required to decode a
	and any parameters needed by those payload processors. Each		payload. The representation MUST describe which algorithm(s) is used
	Processing Step SHOULD indicate the expected digest of the payload		and any additional parameters required by the algorithm(s). The
	after the processing is complete. Processing steps are distinct from		representation MAY group Processing Steps together in predefined
	Directives in that Directives apply to the manifest as a whole,		combinations.
	whereas Processing Steps apply to an individual payload and provide
	instructions on how to unpack it.
	Implements: Usability Requirement MFUR6		A Processing Step MAY indicate the expected digest of the payload
			after the processing is complete.
			Processing steps are RECOMMENDED to implement.
			Enables feature: Encrypted, compressed, packed formats
			Implements: REQ.USE.IMG.NESTED (Section 4.5.6)
	3.10. Manifest Element: Storage Location		3.10. Manifest Element: Storage Location
	This element tells the device which component is being updated. The		This element tells the device where to store a payload within a given
	device can use this to establish which permissions are necessary and		component. The device can use this to establish which permissions
	the physical location to use.		are necessary and the physical storage location to use.
	This element is MANDATORY and MUST be present to enable devices to		This element is MANDATORY and MUST be present to enable devices to
	store payloads to the correct location.		store payloads to the correct location.
	Implements: Security Requirement MFSR4b		Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)
	3.10.1. Example 1: Two Storage Locations		3.10.1. Example 1: Two Storage Locations
	A device supports two components: an OS and an application. These		A device supports two components: an OS and an application. These
	components can be updated independently, expressing dependencies to		components can be updated independently, expressing dependencies to
	ensure compatibility between the components. The firmware authority		ensure compatibility between the components. The firmware authority
	chooses two storage identifiers:		chooses two storage identifiers:
	- OS		o "OS"
	- APP		o "APP"
	3.10.2. Example 2: File System		3.10.2. Example 2: File System
	A device supports a full filesystem. The firmware authority chooses		A device supports a full filesystem. The firmware authority chooses
	to make the storage identifier the path at which to install the		to use the storage identifier as the path at which to install the
	payload. The payload may be a tarball, in which case, it unpacks the		payload. The payload may be a tarball, in which case, it unpacks the
	tarball into the specified path.		tarball into the specified path.
	3.10.3. Example 3: Flash Memory		3.10.3. Example 3: Flash Memory
	A device supports flash memory. The firmware authority chooses to		A device supports flash memory. The firmware authority chooses to
	make the storage identifier the offset where the image should be		make the storage identifier the offset where the image should be
	written.		written.
	3.11. Manifest Element: Component Identifier		3.11. Manifest Element: Component Identifier
	In a heterogeneous storage architecture, a storage identifier is		In a heterogeneous storage architecture, a storage identifier is
	insufficient to identify where and how to store a payload. To		insufficient to identify where and how to store a payload. To
	resolve this, a component identifier indicates which part of the		resolve this, a component identifier indicates which part of the
	storage architecture is targeted by the payload. In a homogeneous		storage architecture is targeted by the payload. In a homogeneous
	storage architecture, this element is unnecessary.		storage architecture, this element is unnecessary.
	This element is OPTIONAL and only necessary in heterogeneous storage		This element is OPTIONAL and only necessary in heterogeneous storage
	architecture devices.		architecture devices.
	Implements: MFUR3		N.B. A serialisation MAY choose to combine Component Identifier and
			Storage Location (Section 3.10)
			Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)
	3.12. Manifest Element: URIs		3.12. Manifest Element: Resource Indicator
	This element is a list of weighted URIs that the device uses to		This element provides the information required for the device to
	select where to obtain a payload.		acquire the resource. This can be encoded in several ways:
			o One URI
			o A list of URIs
			o A prioritised list or URIs
			o A list of signed URIs
	This element is OPTIONAL and only needed when the target device does		This element is OPTIONAL and only needed when the target device does
	not intrinsically know where to find the payload.		not intrinsically know where to find the payload.
	Note: Devices will typically require URIs.		N.B. Devices will typically require URIs.
	Implements: Security Requirement MFSR4c		Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
	3.13. Manifest Element: Payload Digest		3.13. Manifest Element: Payload Digests
	This element contains the digest of the payload. This allows the		This element contains one or more digests of one or more payloads.
	target device to ensure authenticity of the payload. It MUST be		This allows the target device to ensure authenticity of the
	possible to specify more than one payload digest, indexed by Manifest		payload(s). A serialisation MUST provide a mechanism to select one
	Element: XIP Address.		payload from a list based on system parameters, such as XIP address.
	This element is MANDATORY and fundamentally necessary to ensure the		This element is MANDATORY to implement and fundamentally necessary to
	authenticity and integrity of the payload.		ensure the authenticity and integrity of the payload. Support for
			more than one digest is OPTIONAL to implement in a recipient device.
	Implements: Security Requirement MFSR4d, Usability Requirement MFUR8		Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT
			(Section 4.5.8)
	3.14. Manifest Element: Size		3.14. Manifest Element: Size
	The size of the payload in bytes.		The size of the payload in bytes.
			Variable-size storage locations MUST be set to exactly the size
			listed in this element.
	This element is MANDATORY and informs the target device how big of a		This element is MANDATORY and informs the target device how big of a
	payload to expect. Without it, devices are exposed to some classes		payload to expect. Without it, devices are exposed to some classes
	of denial of service attack.		of denial of service attack.
	Implements: Security Requirement MFSR4d		Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8)
	3.15. Manifest Element: Signature		3.15. Manifest Element: Signature
	This is not strictly a manifest element. Instead, the manifest is		This is not strictly a manifest element. Instead, the manifest is
	wrapped by a standardised authentication container, such as a COSE or		wrapped by a standardised authentication container, such as a COSE
	CMS signature object. The authentication container MUST support		([RFC8152]) or CMS ([RFC5652]) signature object. The authentication
	multiple actors and multiple authentications.		container MUST support multiple actors and multiple authentication
			methods.
	This element is MANDATORY and represents the foundation of all		This element is MANDATORY and represents the foundation of all
	security properties of the manifest.		security properties of the manifest. There are two exceptions to
			this requirement: 1) if the manifest is authenticated by a second
			manifest as a dependency and 2) if the manifest is authenticated by
			channel security and contains only channel information (such as
			URIs).
	Implements: Security Requirement MFSR5, MFSR6, MFUR4		Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS
			(Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4)
	3.16. Manifest Element: Directives		3.16. Manifest Element: Additional installation instructions
	A list of instructions that the device should execute, in order, when		Instructions that the device should execute when processing the
	processing the manifest. This information is distinct from the		manifest. This information is distinct from the information
	information necessary to process a payload (Processing Steps) and		necessary to process a payload. Additional installation instructions
	applies to the whole manifest including all payloads that it		include information such as update timing (For example, install only
	references. Directives include information such as update timing		on Sunday, at 0200), procedural considerations (for example, shut
	(For example, install only on Sunday, at 0200), procedural		down the equipment under control before executing the update), pre
	considerations (for example, shut down the equipment under control		and post-installation steps (for example, run a script).
	before executing the update), pre and post-installation steps (for
	example, run a script).
	This element is OPTIONAL and enables some use cases.		This element is OPTIONAL.
	Implements: Usability Requirement MFUR1		Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
	3.17. Manifest Element: Aliases		3.17. Manifest Element: Aliases
	A list of Digest/URI pairs. A device should build an alias table		A mechanism for a manifest to augment or replace URIs or URI lists
	while paring a manifest tree and treat any aliases as top-ranked URIs		defined by one or more of its dependencies.
	for the corresponding digest.
	This element is OPTIONAL and enables some use cases.		This element is OPTIONAL and enables some user stories.
	Implements: Usability Requirement MFUR2		Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)
	3.18. Manifest Element: Dependencies		3.18. Manifest Element: Dependencies
	A list of Digest/URI pairs that refer to other manifests by digest.		A list of other manifests that are required by the current manifest.
	The manifests that are linked in this way must be acquired and		Manifests are identified an an unambiguous way, such as a digest.
	installed simultaneously in order to form a complete update.
	This element is MANDATORY to use in deployments that include both		This element is MANDATORY to use in deployments that include both
	multiple authorities and multiple payloads.		multiple authorities and multiple payloads.
	Implements: Usability Requirement MFUR3		Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)
	3.19. Manifest Element: Content Key Distribution Method		3.19. Manifest Element: Encryption Wrapper
	Encrypting firmware images requires symmetric content encryption		Encrypting firmware images requires symmetric content encryption
	keys. Since there are several methods to protect or distribute the		keys. The encryption wrapper provides the information needed for a
	symmetric content encryption keys, the manifest contains a element		device to obtain or locate a key that it uses to decrypt the
	for the Content Key Distribution Method. One examples for such a		firmware. Typical choices for an encryption wrapper include CMS
	Content Key Distribution Method is the usage of Key Tables, pointing		([RFC5652]) or COSE ([RFC8152]). This MAY be included in a
	to content encryption keys, which themselves are encrypted using the		decryption step contained in Processing Steps (Section 3.9).
	public keys of devices. This MAY be included in a decryption step
	contained in Processing Steps.
	This element is MANDATORY to use for encrypted payloads,		This element is MANDATORY to use for encrypted payloads,
	Implements: Security Requirement MFSR7.		Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
	3.20. Manifest Element: XIP Address		3.20. Manifest Element: XIP Address
	In order to support XIP systems with multiple possible base		In order to support XIP systems with multiple possible base
	addresses, it is necessary to specify which address the payload is		addresses, it is necessary to specify which address the payload is
	linked for.		linked for.
	For example a microcontroller may have a simple bootloader that		For example a microcontroller may have a simple bootloader that
	chooses one of two images to boot. That microcontroller then needs		chooses one of two images to boot. That microcontroller then needs
	to choose one of two firmware images to install, based on which of		to choose one of two firmware images to install, based on which of
	its two images is older.		its two images is older.
	Implements: MFUR8		Implements: REQ.USE.IMG.SELECT (Section 4.5.8)
	3.21. Manifest Element: Load-time metadata		3.21. Manifest Element: Load-time metadata
	## Manifest Element: Boot-time metadata ## Manifest Element: Payload		Load-time metadata provides the device with information that it needs
			in order to load one or more images. This is effectively a copy
			operation from the permanent storage location of an image into the
			active use location of that image. The metadata contains the source
			and destination of the image as well as any operations that are
			performed on the image.
			Implements: REQ.USE.LOAD (Section 4.5.10)
			3.22. Manifest Element: Run-time metadata
			Run-time metadata provides the device with any extra information
			needed to boot the device. This may include information such as the
			entry-point of an XIP image or the kernel command-line of a linux
			image.
			Implements: REQ.USE.EXEC (Section 4.5.9)
			3.23. Manifest Element: Payload
			The Payload element provides a recipient device with the whole
			payload, contained within the manifest superstructure. This enables
			the manifest and payload to be delivered simultaneously.
			Implements: REQ.USE.PAYLOAD (Section 4.5.11)
			3.24. Manifest Element: Key Claims
			The Key Claims element is not authenticated by the Signature
			(Section 3.15), instead, it provides a chain of key delegations (or
			references to them) for the device to follow in order to verify the
			key that authenticated the manifest using a trusted key.
			Implements: REQ.USE.DELEGATION (Section 4.5.13)
	4. Motivation for Manifest Fields		4. Motivation for Manifest Fields
	The following sub-sections describe the threat model, user stories,		The following sub-sections describe the threat model, user stories,
	security requirements, and usability requirements.		security requirements, and usability requirements.
	4.1. Threat Model		4.1. Threat Model
	The following sub-sections aim to provide information about the		The following sub-sections aim to provide information about the
	threats that were considered, the security requirements that are		threats that were considered, the security requirements that are
	derived from those threats and the fields that permit implementation		derived from those threats and the fields that permit implementation
	of the security requirements. This model uses the S.T.R.I.D.E.		of the security requirements. This model uses the S.T.R.I.D.E.
	[STRIDE] approach. Each threat is classified according to:		[STRIDE] approach. Each threat is classified according to:
	- Spoofing Identity		o Spoofing Identity
	- Tampering with data		o Tampering with data
	- Repudiation		o Repudiation
	- Information disclosure		o Information disclosure
	- Denial of service		o Denial of service
	- Elevation of privilege		o Elevation of privilege
	This threat model only covers elements related to the transport of		This threat model only covers elements related to the transport of
	firmware updates. It explicitly does not cover threats outside of		firmware updates. It explicitly does not cover threats outside of
	the transport of firmware updates. For example, threats to an IoT		the transport of firmware updates. For example, threats to an IoT
	device due to physical access are out of scope.		device due to physical access are out of scope.
	4.2. Threat Descriptions		4.2. Threat Descriptions
	4.2.1. Threat MFT1: Old Firmware		4.2.1. THREAT.IMG.EXPIRED: Old Firmware
	Classification: Elevation of Privilege		Classification: Elevation of Privilege
	An attacker sends an old, but valid manifest with an old, but valid		An attacker sends an old, but valid manifest with an old, but valid
	firmware image to a device. If there is a known vulnerability in the		firmware image to a device. If there is a known vulnerability in the
	provided firmware image, this may allow an attacker to exploit the		provided firmware image, this may allow an attacker to exploit the
	vulnerability and gain control of the device.		vulnerability and gain control of the device.
	Threat Escalation: If the attacker is able to exploit the known		Threat Escalation: If the attacker is able to exploit the known
	vulnerability, then this threat can be escalated to ALL TYPES.		vulnerability, then this threat can be escalated to ALL TYPES.
	Mitigated by: MFSR1		Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1)
	4.2.2. Threat MFT2: Mismatched Firmware		4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware
			Classification: Elevation of Privilege
			An attacker targets a device that has been offline for a long time
			and runs an old firmware version. The attacker sends an old, but
			valid manifest to a device with an old, but valid firmware image.
			The attacker-provided firmware is newer than the installed one but
			older than the most recently available firmware. If there is a known
			vulnerability in the provided firmware image then this may allow an
			attacker to gain control of a device. Because the device has been
			offline for a long time, it is unaware of any new updates. As such
			it will treat the old manifest as the most current.
			Threat Escalation: If the attacker is able to exploit the known
			vulnerability, then this threat can be escalated to ALL TYPES.
			Mitigated by: REQ.SEC.EXP (Section 4.3.3)
			4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware
	Classification: Denial of Service		Classification: Denial of Service
	An attacker sends a valid firmware image, for the wrong type of		An attacker sends a valid firmware image, for the wrong type of
	device, signed by an actor with firmware installation permission on		device, signed by an actor with firmware installation permission on
	both types of device. The firmware is verified by the device		both types of device. The firmware is verified by the device
	positively because it is signed by an actor with the appropriate		positively because it is signed by an actor with the appropriate
	permission. This could have wide-ranging consequences. For devices		permission. This could have wide-ranging consequences. For devices
	that are similar, it could cause minor breakage, or expose security		that are similar, it could cause minor breakage, or expose security
	vulnerabilities. For devices that are very different, it is likely		vulnerabilities. For devices that are very different, it is likely
	to render devices inoperable.		to render devices inoperable.
	Mitigated by: MFSR2		Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2)
	Example:		4.2.3.1. Example:
	Suppose that two vendors, Vendor A and Vendor B, adopt the same trade		Suppose that two vendors, Vendor A and Vendor B, adopt the same trade
	name in different geographic regions, and they both make products		name in different geographic regions, and they both make products
	with the same names, or product name matching is not used. This		with the same names, or product name matching is not used. This
	causes firmware from Vendor A to match devices from Vendor B.		causes firmware from Vendor A to match devices from Vendor B.
	If the vendors are the firmware authorities, then devices from Vendor		If the vendors are the firmware authorities, then devices from Vendor
	A will reject images signed by Vendor B since they use different		A will reject images signed by Vendor B since they use different
	credentials. However, if both devices trust the same firmware		credentials. However, if both devices trust the same firmware
	authority, then, devices from Vendor A could install firmware		authority, then, devices from Vendor A could install firmware
	intended for devices from Vendor B.		intended for devices from Vendor B.
	4.2.3. Threat MFT3: Offline device + Old Firmware		4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of
			payload
	Classification: Elevation of Privilege
	An attacker targets a device that has been offline for a long time
	and runs an old firmware version. The attacker sends an old, but
	valid manifest to a device with an old, but valid firmware image.
	The attacker-provided firmware is newer than the installed one but
	older than the most recently available firmware. If there is a known
	vulnerability in the provided firmware image then this may allow an
	attacker to gain control of a device. Because the device has been
	offline for a long time, it is unaware of any new updates. As such
	it will treat the old manifest as the most current.
	Threat Escalation: If the attacker is able to exploit the known
	vulnerability, then this threat can be escalated to ALL TYPES.
	Mitigated by: MFSR3
	4.2.4. Threat MFT4: The target device misinterprets the type of payload
	Classification: Denial of Service		Classification: Denial of Service
	If a device misinterprets the type of the firmware image, it may		If a device misinterprets the format of the firmware image, it may
	cause a device to install a firmware image incorrectly. An		cause a device to install a firmware image incorrectly. An
	incorrectly installed firmware image would likely cause the device to		incorrectly installed firmware image would likely cause the device to
	stop functioning.		stop functioning.
	Threat Escalation: An attacker that can cause a device to		Threat Escalation: An attacker that can cause a device to
	misinterpret the received firmware image may gain elevation of		misinterpret the received firmware image may gain elevation of
	privilege and potentially expand this to all types of threat.		privilege and potentially expand this to all types of threat.
	Mitigated by: MFSR4a		Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5)
	4.2.5. Threat MFT5: The target device installs the payload to the wrong		4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to
	location		the wrong location
	Classification: Denial of Service		Classification: Denial of Service
	If a device installs a firmware image to the wrong location on the		If a device installs a firmware image to the wrong location on the
	device, then it is likely to break. For example, a firmware image		device, then it is likely to break. For example, a firmware image
	installed as an application could cause a device and/or an		installed as an application could cause a device and/or an
	application to stop functioning.		application to stop functioning.
	Threat Escalation: An attacker that can cause a device to		Threat Escalation: An attacker that can cause a device to
	misinterpret the received code may gain elevation of privilege and		misinterpret the received code may gain elevation of privilege and
	potentially expand this to all types of threat.		potentially expand this to all types of threat.
	Mitigated by: MFSR4b		Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.5)
	4.2.6. Threat MFT6: Redirection		4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting
	Classification: Denial of Service		Classification: Denial of Service
	If a device does not know where to obtain the payload for an update,		If a device does not know where to obtain the payload for an update,
	it may be redirected to an attacker's server. This would allow an		it may be redirected to an attacker's server. This would allow an
	attacker to provide broken payloads to devices.		attacker to provide broken payloads to devices.
	Mitigated by: MFSR4c		Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
	4.2.7. Threat MFT7: Payload Verification on Boot		4.2.7. THREAT.NET.MITM
			4.2.8. THREAT.IMG.REPLACE: Payload Replacement
	Classification: Elevation of Privilege		Classification: Elevation of Privilege
	An attacker replaces a newly downloaded firmware after a device		An attacker replaces a newly downloaded firmware after a device
	finishes verifying a manifest. This could cause the device to		finishes verifying a manifest. This could cause the device to
	execute the attacker's code. This attack likely requires physical		execute the attacker's code. This attack likely requires physical
	access to the device. However, it is possible that this attack is		access to the device. However, it is possible that this attack is
	carried out in combination with another threat that allows remote		carried out in combination with another threat that allows remote
	execution.		execution. This is a typical Time Of Check/Time Of Use threat.
	Threat Escalation: If the attacker is able to exploit a known		Threat Escalation: If the attacker is able to exploit a known
	vulnerability, or if the attacker can supply their own firmware, then		vulnerability, or if the attacker can supply their own firmware, then
	this threat can be escalated to ALL TYPES.		this threat can be escalated to ALL TYPES.
	Mitigated by: MFSR4d		Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8)
	4.2.8. Threat MFT8: Unauthenticated Updates		4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images
	Classification: Elevation of Privilege		Classification: Elevation of Privilege / All Types
	If an attacker can install their firmware on a device, by		If an attacker can install their firmware on a device, by
	manipulating either payload or metadata, then they have complete		manipulating either payload or metadata, then they have complete
	control of the device.		control of the device.
	Threat Escalation: If the attacker is able to exploit a known		Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4)
	vulnerability, or if the attacker can supply their own firmware, then
	this threat can be escalated to ALL TYPES.
	Mitigated by: MFSR5
	4.2.9. Threat MFT9: Unexpected Precursor images		4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images
	Classification: Denial of Service		Classification: Denial of Service / All Types
	An attacker sends a valid, current manifest to a device that has an		An attacker sends a valid, current manifest to a device that has an
	unexpected precursor image. If a payload format requires a precursor		unexpected precursor image. If a payload format requires a precursor
	image (for example, delta updates) and that precursor image is not		image (for example, delta updates) and that precursor image is not
	available on the target device, it could cause the update to break.		available on the target device, it could cause the update to break.
	Threat Escalation: An attacker that can cause a device to install a		An attacker that can cause a device to install a payload against the
	payload against the wrong precursor image could gain elevation of		wrong precursor image could gain elevation of privilege and
	privilege and potentially expand this to all types of threat.		potentially expand this to all types of threat. However, it is
			unlikely that a valid differential update applied to an incorrect
			precursor would result in a functional, but vulnerable firmware.
	Mitigated by: MFSR4e		Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
	4.2.10. Threat MFT10: Unqualified Firmware		4.2.11. THREAT.UPD.INTEROP: Unqualified Firmware
	Classification: Denial of Service, Elevation of Privilege		Classification: Denial of Service, Elevation of Privilege
	This threat can appear in several ways, however it is ultimately		This threat can appear in several ways, however it is ultimately
	about interoperability of devices with other systems. The owner or		about interoperability of devices with other systems. The owner or
	operator of a network needs to approve firmware for their network in		operator of a network needs to approve firmware for their network in
	order to ensure interoperability with other devices on the network,		order to ensure interoperability with other devices on the network,
	or the network itself. If the firmware is not qualified, it may not		or the network itself. If the firmware is not qualified, it may not
	work. Therefore, if a device installs firmware without the approval		work. Therefore, if a device installs firmware without the approval
	of the network owner or operator, this is a threat to devices and the		of the network owner or operator, this is a threat to devices and the
	network.		network.
	Threat Escalation: If the firmware expects configuration that is		Threat Escalation: If the firmware expects configuration that is
	present in devices deployed in Network A, but not in devices deployed		present in devices deployed in Network A, but not in devices deployed
	in Network B, then the device may experience degraded security,		in Network B, then the device may experience degraded security,
	leading to threats of All Types.		leading to threats of All Types.
	Mitigated by: MFSR6, MFSR8		Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL
			(Section 4.3.13)
	4.2.10.1. Example 1: Multiple Network Operators with a Single Device		4.2.11.1. Example 1: Multiple Network Operators with a Single Device
	Operator		Operator
	In this example let us assume that Device Operators expect the rights		In this example, assume that Device Operators expect the rights to
	to create firmware but that Network Operators expect the rights to		create firmware but that Network Operators expect the rights to
	qualify firmware as fit-for-purpose on their networks. Additionally		qualify firmware as fit-for-purpose on their networks. Additionally,
	assume that an Device Operators manage devices that can be deployed		assume that Device Operators manage devices that can be deployed on
	on any network, including Network A and B in our example.		any network, including Network A and B in our example.
	An attacker may obtain a manifest for a device on Network A. Then,		An attacker may obtain a manifest for a device on Network A. Then,
	this attacker sends that manifest to a device on Network B. Because		this attacker sends that manifest to a device on Network B. Because
	Network A and Network B are under control of different Operators, and		Network A and Network B are under control of different Operators, and
	the firmware for a device on Network A has not been qualified to be		the firmware for a device on Network A has not been qualified to be
	deployed on Network B, the target device on Network B is now in		deployed on Network B, the target device on Network B is now in
	violation of the Operator B's policy and may get disabled by this		violation of the Operator B's policy and may be disabled by this
	unqualified, but signed firmware.		unqualified, but signed firmware.
	This is a denial of service because it can render devices inoperable.		This is a denial of service because it can render devices inoperable.
	This is an elevation of privilege because it allows the attacker to		This is an elevation of privilege because it allows the attacker to
	make installation decisions that should be made by the Operator.		make installation decisions that should be made by the Operator.
	4.2.10.2. Example 2: Single Network Operator with Multiple Device		4.2.11.2. Example 2: Single Network Operator with Multiple Device
	Operators		Operators
	Multiple devices that interoperate are used on the same network and		Multiple devices that interoperate are used on the same network and
	communicate with each other. Some devices are manufactured and		communicate with each other. Some devices are manufactured and
	managed by Device Operator A and other devices by Device Operator B.		managed by Device Operator A and other devices by Device Operator B.
	A new firmware is released by Device Operator A that breaks		A new firmware is released by Device Operator A that breaks
	compatibility with devices from Device Operator B. An attacker sends		compatibility with devices from Device Operator B. An attacker sends
	the new firmware to the devices managed by Device Operator A without		the new firmware to the devices managed by Device Operator A without
	approval of the Network Operator. This breaks the behaviour of the		approval of the Network Operator. This breaks the behaviour of the
	larger system causing denial of service and possibly other threats.		larger system causing denial of service and possibly other threats.
	Where the network is a distributed SCADA system, this could cause		Where the network is a distributed SCADA system, this could cause
	misbehaviour of the process that is under control.		misbehaviour of the process that is under control.
	4.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for		4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image
	Vulnerability Analysis		for Vulnerability Analysis
	Classification: All Types		Classification: All Types
	An attacker wants to mount an attack on an IoT device. To prepare		An attacker wants to mount an attack on an IoT device. To prepare
	the attack he or she retrieves the provided firmware image and		the attack he or she retrieves the provided firmware image and
	performs reverse engineering of the firmware image to analyze it for		performs reverse engineering of the firmware image to analyze it for
	specific vulnerabilities.		specific vulnerabilities.
	Mitigated by: MFSR7		Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
	4.2.12. Threat MFT12: Overriding Critical Manifest Elements		4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements
	Classification: Elevation of Privilege		Classification: Elevation of Privilege
	An authorised actor, but not the firmware authority, uses an override		An authorised actor, but not the firmware authority, uses an override
	mechanism (MFUS2) to change an information element in a manifest		mechanism (USER_STORY.OVERRIDE (Section 4.4.3)) to change an
	signed by the firmware authority. For example, if the authorised		information element in a manifest signed by the firmware authority.
	actor overrides the digest and URI of the payload, the actor can		For example, if the authorised actor overrides the digest and URI of
	replace the entire payload with a payload of their choice.		the payload, the actor can replace the entire payload with a payload
			of their choice.
	Threat Escalation: By overriding elements such as payload		Threat Escalation: By overriding elements such as payload
	installation instructions or firmware digest, this threat can be		installation instructions or firmware digest, this threat can be
	escalated to all types.		escalated to all types.
	Mitigated by: MFSR8		Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
	4.2.13. Threat MFT13: Manifest Element Exposure		4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure
	Classification: Information Disclosure		Classification: Information Disclosure
	A third party may be able to extract sensitive information from the		A third party may be able to extract sensitive information from the
	manifest.		manifest.
	Mitigated by: MFSR9		Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14)
			4.2.15. THREAT.IMG.EXTRA: Extra data after image
			Classification: All Types
			If a third party modifies the image so that it contains extra code
			after a valid, authentic image, that third party can then use their
			own code in order to make better use of an existing vulnerability
			Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15)
	4.3. Security Requirements		4.3. Security Requirements
	The security requirements here are a set of policies that mitigate		The security requirements here are a set of policies that mitigate
	the threats described in Section 4.1.		the threats described in Section 4.1.
	4.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers		4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers
	Only an actor with firmware installation authority is permitted to		Only an actor with firmware installation authority is permitted to
	decide when device firmware can be installed. To enforce this rule,		decide when device firmware can be installed. To enforce this rule,
	manifests MUST contain monotonically increasing sequence numbers.		manifests MUST contain monotonically increasing sequence numbers.
	Manifests MAY use UTC epoch timestamps to coordinate monotonically		Manifests MAY use UTC epoch timestamps to coordinate monotonically
	increasing sequence numbers across many actors in many locations. If		increasing sequence numbers across many actors in many locations. If
	UTC epoch timestamps are used, they MUST NOT be treated as times,		UTC epoch timestamps are used, they MUST NOT be treated as times,
	they MUST be treated only as sequence numbers. Devices MUST reject		they MUST be treated only as sequence numbers. Devices MUST reject
	manifests with sequence numbers smaller than any onboard sequence		manifests with sequence numbers smaller than any onboard sequence
	number.		number.
	Note: This is not a firmware version. It is a manifest sequence		Note: This is not a firmware version. It is a manifest sequence
	number. A firmware version may be rolled back by creating a new		number. A firmware version may be rolled back by creating a new
	manifest for the old firmware version with a later sequence number.		manifest for the old firmware version with a later sequence number.
	Mitigates: Threat MFT1		Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1)
	Implemented by: Manifest Element: Monotonic Sequence Number		Implemented by: Monotonic Sequence Number (Section 3.2)
	4.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers		4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers
	Devices MUST only apply firmware that is intended for them. Devices		Devices MUST only apply firmware that is intended for them. Devices
	MUST know with fine granularity that a given update applies to their		MUST know with fine granularity that a given update applies to their
	vendor, model, hardware revision, software revision. Human-readable		vendor, model, hardware revision, software revision. Human-readable
	identifiers are often error-prone in this regard, so unique		identifiers are often error-prone in this regard, so unique
	identifiers SHOULD be used.		identifiers SHOULD be used.
	Mitigates: Threat MFT2		Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
	Implemented by: Manifest Elements: Vendor ID Condition, Class ID		Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition
	Condition		(Section 3.4)
	4.3.3. Security Requirement MFSR3: Best-Before Timestamps		4.3.3. REQ.SEC.EXP: Expiration Time
	Firmware MAY expire after a given time. Devices MAY provide a secure		Firmware MAY expire after a given time. Devices MAY provide a secure
	clock (local or remote). If a secure clock is provided and the		clock (local or remote). If a secure clock is provided and the
	Firmware manifest has a best-before timestamp, the device MUST reject		Firmware manifest has an expiration timestamp, the device MUST reject
	the manifest if current time is larger than the best-before time.		the manifest if current time is later than the expiration time.
	Mitigates: Threat MFT3		Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2)
	Implemented by: Manifest Element: Best-Before timestamp condition		Implemented by: Expiration Time (Section 3.7)
	4.3.4. Security Requirement MFSR5: Cryptographic Authenticity		4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity
	The authenticity of an update must be demonstrable. Typically, this		The authenticity of an update MUST be demonstrable. Typically, this
	means that updates must be digitally authenticated. Because the		means that updates must be digitally authenticated. Because the
	manifest contains information about how to install the update, the		manifest contains information about how to install the update, the
	manifest's authenticity must also be demonstrable. To reduce the		manifest's authenticity MUST also be demonstrable. To reduce the
	overhead required for validation, the manifest contains the digest of		overhead required for validation, the manifest contains the digest of
	the firmware image, rather than a second digital signature. The		the firmware image, rather than a second digital signature. The
	authenticity of the manifest can be verified with a digital signature		authenticity of the manifest can be verified with a digital signature
	or Message Authentication Code, the authenticity of the firmware		or Message Authentication Code, the authenticity of the firmware
	image is tied to the manifest by the use of a digest of the firmware		image is tied to the manifest by the use of a digest of the firmware
	image.		image.
	Mitigates: Threat MFT8		Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9)
	Implemented by: Signature, Payload Digest		Implemented by: Signature (Section 3.15), Payload Digest
			(Section 3.13)
	4.3.5. Security Requirement MFSR4a: Authenticated Payload Type		4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type
	The type of payload (which may be independent of format) MUST be		The type of payload (which may be independent of format) MUST be
	authenticated. For example, the target must know whether the payload		authenticated. For example, the target must know whether the payload
	is XIP firmware, a loadable module, or serialized configuration data.		is XIP firmware, a loadable module, or serialized configuration data.
	Mitigates: MFT4		Mitigates: THREAT.IMG.FORMAT (Section 4.2.4)
	Implemented by: Manifest Elements: Payload Format, Storage Location		Implemented by: Payload Format (Section 3.8), Storage Location
			(Section 3.10)
	4.3.6. Security Requirement MFSR4b: Authenticated Storage Location		4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage
			Location
	The location on the target where the payload is to be stored MUST be		The location on the target where the payload is to be stored MUST be
	authenticated.		authenticated.
	Mitigates: MFT5		Mitigates: THREAT.IMG.LOCATION (Section 4.2.5)
	Implemented by: Manifest Elements: Storage Location		Implemented by: Storage Location (Section 3.10)
	4.3.7. Security Requirement MFSR4c: Authenticated Remote Resource		4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location
	Location
	The location where a target should find a payload MUST be		The location where a target should find a payload MUST be
	authenticated.		authenticated.
	Mitigates: MFT6		Mitigates: THREAT.NET.REDIRECT (Section 4.2.6)
	Implemented by: Manifest Elements: URIs		Implemented by: Resource Indicator (Section 3.12)
	4.3.8. Security Requirement MFSR4d: Secure Boot		4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution
	The target SHOULD verify firmware at time of boot. This requires		The target SHOULD verify firmware at time of boot. This requires
	authenticated payload size, and digest.		authenticated payload size, and digest.
	Mitigates: MFT7		Mitigates: THREAT.IMG.REPLACE (Section 4.2.8)
	Implemented by: Manifest Elements: Payload Digest, Size		Implemented by: Payload Digest (Section 3.13), Size (Section 3.14)
	4.3.9. Security Requirement MFSR4e: Authenticated precursor images		4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images
	If an update uses a differential compression method, it MUST specify		If an update uses a differential compression method, it MUST specify
	the digest of the precursor image and that digest MUST be		the digest of the precursor image and that digest MUST be
	authenticated.		authenticated.
	Mitigates: MFT9		Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10)
	Implemented by: Manifest Elements: Precursor Image Digest Condition
	4.3.10. Security Requirement MFSR4f: Authenticated Vendor and Class IDs
	The identifiers that specify firmware compatibility MUST be
	authenticated to ensure that only compatible firmware is installed on
	a target device.
	Mitigates: MFT2
	Implemented By: Manifest Elements: Vendor ID Condition, Class ID		Implemented by: Precursor Image Digest (Section 3.5)
	Condition
	4.3.11. Security Requirement MFSR4f: Authenticated Vendor and Class IDs		4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs
	The identifiers that specify firmware compatibility MUST be		The identifiers that specify firmware compatibility MUST be
	authenticated to ensure that only compatible firmware is installed on		authenticated to ensure that only compatible firmware is installed on
	a target device.		a target device.
	Mitigates: MFT2		Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
	Implemented By: Manifest Elements: Vendor ID Condition, Class ID		Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition
	Condition		(Section 3.4)
	4.3.12. Security Requirement MFSR6: Rights Require Authenticity		4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity
	If a device grants different rights to different actors, exercising		If a device grants different rights to different actors, exercising
	those rights MUST be accompanied by proof of those rights, in the		those rights MUST be accompanied by proof of those rights, in the
	form of proof of authenticity. Authenticity mechanisms such as those		form of proof of authenticity. Authenticity mechanisms such as those
	required in MFSR5 are acceptable but need to follow the end-to-end		required in REQ.SEC.AUTHENTIC (Section 4.3.4) are acceptable but need
	security model.		to follow the end-to-end security model.
	For example, if a device has a policy that requires that firmware		For example, if a device has a policy that requires that firmware
	have both an Authorship right and a Qualification right and if that		have both an Authorship right and a Qualification right and if that
	device grants Authorship and Qualification rights to different		device grants Authorship and Qualification rights to different
	parties, such as a Device Operator and a Network Operator,		parties, such as a Device Operator and a Network Operator,
	respectively, then the firmware cannot be installed without proof of		respectively, then the firmware cannot be installed without proof of
	rights from both the Device and the Network Operator.		rights from both the Device and the Network Operator.
	Mitigates: MFT10		Mitigates: THREAT.UPD.INTEROP (Section 4.2.11)
	Implemented by: Signature		Implemented by: Signature (Section 3.15)
	4.3.13. Security Requirement MFSR7: Firmware encryption		4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption
	The manifest information model must enable encrypted payloads.		The manifest information model MUST enable encrypted payloads.
	Encryption helps to prevent third parties, including attackers, from		Encryption helps to prevent third parties, including attackers, from
	reading the content of the firmware image. This can protect against		reading the content of the firmware image. This can protect against
	confidential information disclosures and discovery of vulnerabilities		confidential information disclosures and discovery of vulnerabilities
	through reverse engineering. Therefore the manifest must convey the		through reverse engineering. Therefore the manifest must convey the
	information required to allow an intended recipient to decrypt an		information required to allow an intended recipient to decrypt an
	encrypted payload.		encrypted payload.
	Mitigates: MFT11		Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12)
	Implemented by: Manifest Element: Content Key Distribution Method		Implemented by: Encryption Wrapper (Section 3.19)
	4.3.14. Security Requirement MFSR8: Access Control Lists		4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control
	If a device grants different rights to different actors, then an		If a device grants different rights to different actors, then an
	exercise of those rights must be validated against a list of rights		exercise of those rights MUST be validated against a list of rights
	for the actor. This typically takes the form of an Access Control		for the actor. This typically takes the form of an Access Control
	List (ACL). ACLs are applied to two scenarios:		List (ACL). ACLs are applied to two scenarios:
	1. An ACL decides which elements of the manifest may be overridden		1. An ACL decides which elements of the manifest may be overridden
	and by which actors.		and by which actors.
	2. An ACL decides which component identifier/storage identifier		2. An ACL decides which component identifier/storage identifier
	pairs can be written by which actors.		pairs can be written by which actors.
	Mitigates: MFT12, MFT10		Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), THREAT.UPD.INTEROP
			(Section 4.2.11)
	Implemented by: Client-side code, not specified in manifest.		Implemented by: Client-side code, not specified in manifest.
	4.3.15. Security Requirement MFSR9: Encrypted Manifests		4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests
	It must be possible to encrypt part or all of the manifest. This may		It MUST be possible to encrypt part or all of the manifest. This may
	be accomplished with either transport encryption or with at-rest		be accomplished with either transport encryption or with at-rest
	encryption, for example COSE_Encrypt.		encryption.
	Mitigates: MFT13		Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14)
	Implemented by: TLS/COSE		Implemented by: External Encryption Wrapper / Transport Security
			4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest
			The digest SHOULD cover all available space in a fixed-size storage
			location. Variable-size storage locations MUST be restricted to
			exactly the size of deployed payload. This prevents any data from
			being distributed without being covered by the digest. For example,
			XIP microcontrollers typically have fixed-size storage. These
			devices should deploy a digest that covers the deployed firmware
			image, concatenated with the default erased value of any remaining
			space.
			Mitigates: THREAT.IMG.EXTRA (Section 4.2.15)
			Implemented by: Payload Digests (Section 3.13)
	4.4. User Stories		4.4. User Stories
	User stories provide expected use cases. These are used to feed into		User stories provide expected use cases. These are used to feed into
	usability requirements.		usability requirements.
	4.4.1. Use Case MFUS1: Installation Instructions		4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions
	As an Device Operator, I want to provide my devices with additional		As a Device Operator, I want to provide my devices with additional
	installation instructions so that I can keep process details out of		installation instructions so that I can keep process details out of
	my payload data.		my payload data.
	Some installation instructions might be:		Some installation instructions might be:
	- Use a table of hashes to ensure that each block of the payload is		o Use a table of hashes to ensure that each block of the payload is
	validate before writing.		validate before writing.
	- Do not report progress.		o Do not report progress.
	- Pre-cache the update, but do not install.		o Pre-cache the update, but do not install.
	- Install the pre-cached update matching this manifest.		o Install the pre-cached update matching this manifest.
	- Install this update immediately, overriding any long-running		o Install this update immediately, overriding any long-running
	tasks.		tasks.
	Satisfied by: MFUR1		Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
	4.4.2. Use Case MFUS2: Override Non-Critical Manifest Elements		4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early
			As a designer of a resource-constrained IoT device, I want bad
			updates to fail as early as possible to preserve battery life and
			limit consumed bandwidth.
			Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
			4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements
	As a Network Operator, I would like to be able to override the non-		As a Network Operator, I would like to be able to override the non-
	critical information in the manifest so that I can control my devices		critical information in the manifest so that I can control my devices
	more precisely. This assumes that the Device Operator delegated		more precisely. The authority to override this information is
	rights about the device to the Network Operator.		provided via the installation of a limited trust relationship by
			another authority.
	Some examples of potentially overridable information:		Some examples of potentially overridable information:
	- URIs: this allows the Network Operator to direct devices to their		o URIs (Section 3.12): this allows the Network Operator to direct
	own infrastructure in order to reduce network load.		devices to their own infrastructure in order to reduce network
			load.
	- Conditions: this allows the Network Operator to pose additional		o Conditions: this allows the Network Operator to pose additional
	constraints on the installation of the manifest.		constraints on the installation of the manifest.
	- Directives: this allows the Network Operator to add more		o Directives (Section 3.16): this allows the Network Operator to add
	instructions such as time of installation.		more instructions such as time of installation.
	- Processing Steps: If an intermediary performs an action on behalf		o Processing Steps (Section 3.9): If an intermediary performs an
	of a device, it may need to override the processing steps. It is		action on behalf of a device, it may need to override the
	still possible for a device to verify the final content and the		processing steps. It is still possible for a device to verify the
	result of any processing step that specifies a digest. Some		final content and the result of any processing step that specifies
	processing steps should be non-overridable.		a digest. Some processing steps should be non-overridable.
	Satisfied by: MFUR2, MFUR3		Satisfied by: USER_STORY.OVERRIDE (Section 4.4.3),
			REQ.USE.MFST.COMPONENT (Section 4.5.3)
	4.4.3. Use Case MFUS3: Modular Update		4.4.4. USER_STORY.COMPONENT: Component Update
	As an Operator, I want to divide my firmware into frequently updated		As an Operator, I want to divide my firmware into components, so that
	and infrequently updated components, so that I can reduce the size of		I can reduce the size of updates, make different parties responsible
	updates and make different parties responsible for different		for different components, and divide my firmware into frequently
	components.		updated and infrequently updated components.
	Satisfied by: MFUR3		Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3)
	4.4.4. Use Case MFUS4: Multiple Authorisations		4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations
	As a Device Operator, I want to ensure the quality of a firmware		As a Device Operator, I want to ensure the quality of a firmware
	update before installing it, so that I can ensure interoperability of		update before installing it, so that I can ensure interoperability of
	all devices in my product family. I want to restrict the ability to		all devices in my product family. I want to restrict the ability to
	make changes to my devices to require my express approval.		make changes to my devices to require my express approval.
	Satisfied by: MFUR4, MFSR8		Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4),
			REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
	4.4.5. Use Case MFUS5: Multiple Payload Formats		4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats
	As an Operator, I want to be able to send multiple payload formats to		As an Operator, I want to be able to send multiple payload formats to
	suit the needs of my update, so that I can optimise the bandwidth		suit the needs of my update, so that I can optimise the bandwidth
	used by my devices.		used by my devices.
	Satisfied by: MFUR5		Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5)
	4.4.6. Use Case MFUS6: Prevent Confidential Information Disclosures		4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information
			Disclosures
	As an firmware author, I want to prevent confidential information		As an firmware author, I want to prevent confidential information
	from being disclosed during firmware updates. It is assumed that		from being disclosed during firmware updates. It is assumed that
	channel security is adequate to protect the manifest itself against		channel security or at-rest encryption is adequate to protect the
	information disclosure.		manifest itself against information disclosure.
	Satisfied by: MFSR7		Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
	4.4.7. Use Case MFUS7: Prevent Devices from Unpacking Unknown Formats		4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking
			Unknown Formats
	As a Device Operator, I want devices to determine whether they can		As a Device Operator, I want devices to determine whether they can
	process a payload prior to downloading it.		process a payload prior to downloading it.
	In some cases, it may be desirable for a third party to perform some		In some cases, it may be desirable for a third party to perform some
	processing on behalf of a target. For this to occur, the third party		processing on behalf of a target. For this to occur, the third party
	MUST indicate what processing occurred and how to verify it against		MUST indicate what processing occurred and how to verify it against
	the Trust Provisioning Authority's intent.		the Trust Provisioning Authority's intent.
	This amounts to overriding Processing Steps and URIs.		This amounts to overriding Processing Steps (Section 3.9) and
			Resource Indicator (Section 3.12).
	Satisfied by: MFUR6, MFUR2		Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED
			(Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)
	4.4.8. Use Case MFUS8: Specify Version Numbers of Target Firmware		4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of
			Target Firmware
	As a Device Operator, I want to be able to target devices for updates		As a Device Operator, I want to be able to target devices for updates
	based on their current firmware version, so that I can control which		based on their current firmware version, so that I can control which
	versions are replaced with a single manifest.		versions are replaced with a single manifest.
	Satisfied by: MFUR7		Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7)
	4.4.9. Use Case MFUS9: Enable Devices to Choose Between Images		4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images
	As a developer, I want to be able to sign two or more versions of my		As a developer, I want to be able to sign two or more versions of my
	firmware in a single manifest so that I can use a very simple		firmware in a single manifest so that I can use a very simple
	bootloader that chooses between two or more images that are executed		bootloader that chooses between two or more images that are executed
	in-place.		in-place.
	Satisfied by: MFUR8		Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8)
	4.4.10. Use Case MFUS10: Secure Boot Using Manifests		4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests
	As a signer for both secure boot and firmware deployment, I would		As a signer for both secure execution/boot and firmware deployment, I
	like to use the same signed document for both tasks so that my data		would like to use the same signed document for both tasks so that my
	size is smaller, I can share common code, and I can reduce signature		data size is smaller, I can share common code, and I can reduce
	verifications.		signature verifications.
	Satisfied by: MFUR9		Satisfied by: REQ.USE.EXEC (Section 4.5.9)
	4.4.11. Use Case MFUS11: Decompress on Load		4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load
	As a developer of firmware for a run-from-RAM device, I would like to		As a developer of firmware for a run-from-RAM device, I would like to
	use compressed images and to indicate to the bootloader that I am		use compressed images and to indicate to the bootloader that I am
	using a compressed image in the manifest so that it can be used with		using a compressed image in the manifest so that it can be used with
	secure boot.		secure execution/boot.
	Satisfied by: MFUR10		Satisfied by: REQ.USE.LOAD (Section 4.5.10)
	4.4.12. Use Case MFUS12: Payload in Manifest		4.4.13. USER_STORY.MFST.IMG: Payload in Manifest
	As an operator of a constrained network, I would like to be able to		As an operator of a constrained network, I would like to be able to
	send a small payload in the same packet as the manifest so that I can		send a small payload in the same packet as the manifest so that I can
	reduce network traffic.		reduce network traffic.
	Satisfied by: MFUR11		Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11)
	4.4.13. Use Case MFUS13: Simple Parsing		4.4.14. USER_STORY.MFST.PARSE: Simple Parsing
	As a developer for constrained devices, I want a low complexity		As a developer for constrained devices, I want a low complexity
	library for processing updates so that I can fit more application		library for processing updates so that I can fit more application
	code on my device.		code on my device.
	Satisfied by: MFUR12		Satisfied by: REQ.USE.PARSE (Section 4.5.12)
			4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest
			As an operator that rotates delegated authority more often than
			delivering firmware updates, I would like to delegate a new authority
			when I deliver a firmware update so that I can accomplish both tasks
			in a single transmission.
			Satisfied by: REQ.USE.DELEGATION (Section 4.5.13)
			4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation
			As an operator of a constrained network, I would like devices on my
			network to be able to evaluate the suitability of an update prior to
			initiating any large download so that I can prevent unnecessary
			consumption of bandwidth.
			Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
	4.5. Usability Requirements		4.5. Usability Requirements
	The following usability requirements satisfy the user stories listed		The following usability requirements satisfy the user stories listed
	above.		above.
	4.5.1. Usability Requirement MFUR1		4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks
	It must be possible to provide all information necessary for the		It MUST be possible for a manifest author to place ALL information
	processing of a manifest into the manifest.		required to process an update in the manifest.
	Satisfies: User story MFUS1		For example: Information about which precursor image is required for
			a differential update MUST be placed in the manifest, not in the
			differential compression header.
	Implemented by: Manifest Element: Directives		Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check),
			USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1)
	4.5.2. Usability Requirement MFUR2		Implemented by: Additional installation instructions (Section 3.16)
	It must be possible to redirect payload fetches. This applies where		4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location
			It MUST be possible to redirect payload fetches. This applies where
	two manifests are used in conjunction. For example, a Device		two manifests are used in conjunction. For example, a Device
	Operator creates a manifest specifying a payload and signs it, and		Operator creates a manifest specifying a payload and signs it, and
	provides a URI for that payload. A Network Operator creates a second		provides a URI for that payload. A Network Operator creates a second
	manifest, with a dependency on the first. They use this second		manifest, with a dependency on the first. They use this second
	manifest to override the URIs provided by the Device Operator,		manifest to override the URIs provided by the Device Operator,
	directing them into their own infrastructure instead. Some devices		directing them into their own infrastructure instead. Some devices
	may provide this capability, while others may only look at canonical		may provide this capability, while others may only look at canonical
	sources of firmware. For this to be possible, the device must fetch		sources of firmware. For this to be possible, the device must fetch
	the payload, whereas a device that accpets payload pushes will ignore		the payload, whereas a device that accepts payload pushes will ignore
	this feature.		this feature.
	Satisfies: User story MFUS2		N.B. If a manifest is delivered over an authenticated channel and
			that manifest contains only override information for which the remote
			is authorised, then it can be considered authenticated by the channel
			authentication.
	Implemented by: Manifest Element: Aliases		Satisfies: USER_STORY.OVERRIDE (Section 4.4.3)
	4.5.3. Usability Requirement MFUR3		Implemented by: Aliases (Section 3.17)
	It must be possible express the requirement to install one or more		4.5.3. REQ.USE.MFST.COMPONENT: Component Updates
			It MUST be possible express the requirement to install one or more
	payloads from one or more authorities so that a multi-payload update		payloads from one or more authorities so that a multi-payload update
	can be described. This allows multiple parties with different		can be described. This allows multiple parties with different
	permissions to collaborate in creating a single update for the IoT		permissions to collaborate in creating a single update for the IoT
	device, across multiple components.		device, across multiple components.
	This requirement effectively means that it must be possible to		This requirement effectively means that it must be possible to
	construct a tree of manifests on a multi-image target.		construct a tree of manifests on a multi-image target.
	Because devices can be either HeSA or HoSA both the storage system		In order to enable devices with a heterogeneous storage architecture,
	and the storage location within that storage system must be possible		the manifest must enable specification of both storage system and the
	to specify. In a HoSA device, the payload location may be as simple		storage location within that storage system.
	as an address, or a file path. In a HeSA device, the payload
	location may be scoped by a component identifier. It is expedient to		Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT
	consider that all HoSA devices are HeSA devices with a single		(Section 4.4.4)
	component.
			Implemented by Manifest Element: Dependencies, StorageIdentifier,
			ComponentIdentifier
	4.5.3.1. Example 1: Multiple Microcontrollers		4.5.3.1. Example 1: Multiple Microcontrollers
	An IoT device with multiple microcontrollers in the same physical		An IoT device with multiple microcontrollers in the same physical
	device (HeSA) will likely require multiple payloads with different		device (HeSA) will likely require multiple payloads with different
	component identifiers.		component identifiers.
	4.5.3.2. Example 2: Code and Configuration		4.5.3.2. Example 2: Code and Configuration
	A firmware image can be divided into two payloads: code and		A firmware image can be divided into two payloads: code and
	configuration. These payloads may require authorizations from		configuration. These payloads may require authorizations from
	different actors in order to install (see MFSR6 and MFSR8). This		different actors in order to install (see REQ.SEC.RIGHTS
			(Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This
	structure means that multiple manifests may be required, with a		structure means that multiple manifests may be required, with a
	dependency structure between them.		dependency structure between them.
	4.5.3.3. Example 3: Multiple Chunks		4.5.3.3. Example 3: Multiple Software Modules
	A firmware image can be divided into multiple functional blocks for		A firmware image can be divided into multiple functional blocks for
	separate testing and distribution. This means that code would need		separate testing and distribution. This means that code would need
	to be distributed in multiple payloads. For example, this might be		to be distributed in multiple payloads. For example, this might be
	desirable in order to ensure that common code between devices is		desirable in order to ensure that common code between devices is
	identical in order to reduce distribution bandwidth.		identical in order to reduce distribution bandwidth.
	Satisfies: User story MFUS2, MFUS3		4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications
	Implemented by Manifest Element: Dependencies, StorageIdentifier,
	ComponentIdentifier
	4.5.4. Usability Requirement MFUR4
	It MUST be possible to sign a manifest multiple times so that
	signatures from multiple parties with different permissions can be
	required in order to authorise installation of a manifest.
	Satisfies: User story MFUS4		It MUST be possible to authenticate a manifest multiple times so that
			authorisations from multiple parties with different permissions can
			be required in order to authorise installation of a manifest.
	Implemented by: COSE Signature (or similar)		Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5)
	4.5.5. Usability Requirement MFUR5		Implemented by: Signature (Section 3.15)
	The manifest format MUST accommodate any payload format that an		4.5.5. REQ.USE.IMG.FORMAT: Format Usability
	Operator wishes to use. Some examples of payload format would be:
	- Binary		The manifest serialisation MUST accommodate any payload format that
			an Operator wishes to use. This enables the recipient to detect
			which format the Operator has chosen. Some examples of payload
			format are:
	- Elf		o Binary
	- Differential		o Elf
	- Compressed		o Differential
	- Packed configuration		o Compressed
			o Packed configuration
	- Intel HEX		o Intel HEX
	- S-Record		o S-Record
	Satisfies: User story MFUS5		Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6)
			USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8)
	Implemented by: Manifest Element: Payload Format		Implemented by: Payload Format (Section 3.8)
	4.5.6. Usability Requirement MFUR6		4.5.6. REQ.USE.IMG.NESTED: Nested Formats
	The manifest format must accommodate nested formats, announcing to		The manifest serialisation MUST accommodate nested formats,
	the target device all the nesting steps and any parameters used by		announcing to the target device all the nesting steps and any
	those steps.		parameters used by those steps.
	Satisfies: User story MFUS6		Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7)
	Implemented by: Manifest Element: Processing Steps		Implemented by: Processing Steps (Section 3.9)
	4.5.7. Usability Requirement MFUR7		4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching
	The manifest format must provide a method to specify multiple version		The manifest serialisation MUST provide a method to specify multiple
	numbers of firmware to which the manifest applies, either with a list		version numbers of firmware to which the manifest applies, either
	or with range matching.		with a list or with range matching.
	Satisfies: User story MFUS8		Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9)
	Implemented by: Manifest Element: Required Image Version List		Implemented by: Required Image Version List (Section 3.6)
	4.5.8. Usability Requirement MFUR8		4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination
	The manifest format must provide a mechanism to list multiple		The manifest serialisation MUST provide a mechanism to list multiple
	equivalent payloads by Execute-In-Place Installation Address,		equivalent payloads by Execute-In-Place Installation Address,
	including the payload digest and, optionally, payload URIs.		including the payload digest and, optionally, payload URIs.
	Satisfies: User story MFUS9		Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10)
	Implemented by: Manifest Element: XIP Address		Implemented by: XIP Address (Section 3.20)
	4.5.9. Usability Requirement MFUR9: Bootable Manifest		4.5.9. REQ.USE.EXEC: Executable Manifest
	It must be possible to describe a bootable system with a manifest on		It MUST be possible to describe an executable system with a manifest
	both Execute-In-Place microcontrollers and on complex operating		on both Execute-In-Place microcontrollers and on complex operating
	systems. This requires the manifest to specify the digest of each		systems. This requires the manifest to specify the digest of each
	statically linked storage location. In addition, the manifest must		statically linked dependency. In addition, the manifest
	be able to express metadata used by the bootloader, such as a kernel		serialisation MUST be able to express metadata, such as a kernel
	command-line.		command-line, used by any loader or bootloader.
	Satisfies: User story MFUS10		Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11)
	Implemented by: Manifest Element: Boot-time Metadata		Implemented by: Run-time metadata (Section 3.22)
	4.5.10. Usability Requirement MFUR10: Load-Time Information		4.5.10. REQ.USE.LOAD: Load-Time Information
	It must be possible to specify additional metadata for load time		It MUST be possible to specify additional metadata for load time
	processing of a payload, such as load-address, and compression		processing of a payload, such as cryptographic information, load-
	algorithm.		address, and compression algorithm.
	N.B. load comes before boot.		N.B. load comes before exec/boot.
	Satisfies: User Story MFUS11		Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12)
	Implemented by: Manifest Element: Load-time Metadata		Implemented by: Load-time metadata (Section 3.21)
	4.5.11. Usability Requirement MFUR11: Payload in Manifest		4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure
	Superstructure
	It must be possible to place a payload in the same structure as the		It MUST be possible to place a payload in the same structure as the
	manifest. This typically places the payload in the same packet as		manifest. This MAY place the payload in the same packet as the
	the manifest.		manifest.
	Satisfies: User Story MFUS12		Satisfies: USER_STORY.MFST.IMG (Section 4.4.13)
	Implemented by: Manifest Element: Payload
	4.5.12. Usability Requirement MFUR12: Simple Parsing		Implemented by: Payload (Section 3.23)
	The structure of the manifest must be simple to parse, without need		4.5.12. REQ.USE.PARSE: Simple Parsing
			The structure of the manifest MUST be simple to parse, without need
	for a general-purpose parser.		for a general-purpose parser.
	Satisfies: User Story MFUS13		Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14)
	Implemented by: N/A		Implemented by: N/A
			4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest
			Any serialisation MUST enable the delivery of a key claim with, but
			not authenticated by a manifest. This key claim delivers a new key
			with which the recipient can verify the manifest.
			Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)
			Implemented by: Key Claims (Section 3.24)
	5. Security Considerations		5. Security Considerations
	Security considerations for this document are covered in Section 4.		Security considerations for this document are covered in Section 4.
	6. IANA Considerations		6. IANA Considerations
	This document does not require any actions by IANA.		This document does not require any actions by IANA.
	7. Acknowledgements		7. Acknowledgements
	We would like to thank our working group chairs, Dave Thaler, Russ		We would like to thank our working group chairs, Dave Thaler, Russ
	Housley and David Waltermire, for their review comments and their		Housley and David Waltermire, for their review comments and their
	support.		support.
	We would like to thank the participants of the 2018 Berlin SUIT		We would like to thank the participants of the 2018 Berlin SUIT
	Hackathon and the June 2018 virtual design team meetings for their		Hackathon and the June 2018 virtual design team meetings for their
	discussion input. In particular, we would like to thank Koen		discussion input. In particular, we would like to thank Koen
	Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus		Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus
	Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson,		Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson,
	Jan-Frederik Rieckers Francisco Acosta, Anton Gerasimov, Matthias		Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias
	Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm,		Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm,
	Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said		Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said
	Gharout, and Milen Stoychev.		Gharout, and Milen Stoychev.
			We would like to thank those who contributed to the development of
			this information model. In particular, we would like to thank
			Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, Gary
			Thomson.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-suit-architecture]		[I-D.ietf-suit-architecture]
	Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A		Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A
	Firmware Update Architecture for Internet of Things		Firmware Update Architecture for Internet of Things
	Devices", draft-ietf-suit-architecture-02 (work in		Devices", draft-ietf-suit-architecture-05 (work in
	progress), January 2019.		progress), April 2019.
	[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>.
	8.2. Informative References
	[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>.
			[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
			RFC 5652, DOI 10.17487/RFC5652, September 2009,
			<https://www.rfc-editor.org/info/rfc5652>.
			[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
			RFC 8152, DOI 10.17487/RFC8152, July 2017,
			<https://www.rfc-editor.org/info/rfc8152>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			8.2. Informative References
	[STRIDE] Microsoft, "The STRIDE Threat Model", May 2018,		[STRIDE] Microsoft, "The STRIDE Threat Model", May 2018,
	<https://msdn.microsoft.com/en-us/library/		<https://msdn.microsoft.com/en-us/library/
	ee823878(v=cs.20).aspx>.		ee823878(v=cs.20).aspx>.
	8.3. URIs		8.3. URIs
	[1] mailto:suit@ietf.org		[1] mailto:suit@ietf.org
	[2] https://www1.ietf.org/mailman/listinfo/suit		[2] https://www1.ietf.org/mailman/listinfo/suit
End of changes. 278 change blocks.
	555 lines changed or deleted		756 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/