< draft-ietf-suit-information-model-04.txt		draft-ietf-suit-information-model-05.txt >
	SUIT B. Moran		SUIT B. Moran
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Standards Track Arm Limited		Intended status: Standards Track Arm Limited
	Expires: May 2, 2020 H. Birkholz		Expires: July 23, 2020 H. Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	October 30, 2019		January 20, 2020
	An Information Model for Firmware Updates in IoT Devices		An Information Model for Firmware Updates in IoT Devices
	draft-ietf-suit-information-model-04		draft-ietf-suit-information-model-05
	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. Ensuring that devices function and		suitable for constrained devices. Ensuring that devices function and
	remain secure over their service life requires such an update		remain secure over their service life requires such an update
	mechanism to fix vulnerabilities, to update configuration settings,		mechanism to fix vulnerabilities, to update configuration settings,
	as well as adding new functionality		as well as adding new functionality
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 2, 2020.		This Internet-Draft will expire on July 23, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6		2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
	3. Manifest Information Elements . . . . . . . . . . . . . . . . 6		3. Manifest Information Elements . . . . . . . . . . . . . . . . 6
	3.1. Manifest Element: Version ID of the manifest structure . 6		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 . . . . . . . . . . . . . . . 7		3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 7
	3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7		3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7
	3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7		3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7
	3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8		3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8
	3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9		3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9
	3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9		3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9
	3.5. Manifest Element: Precursor Image Digest Condition . . . 9		3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9
			3.5. Manifest Element: Precursor Image Digest Condition . . . 10
	3.6. Manifest Element: Required Image Version List . . . . . . 10		3.6. Manifest Element: Required Image Version List . . . . . . 10
	3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10		3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10
	3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10		3.8. Manifest Element: Payload Format . . . . . . . . . . . . 11
	3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11		3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11
	3.10. Manifest Element: Storage Location . . . . . . . . . . . 11		3.10. Manifest Element: Storage Location . . . . . . . . . . . 11
	3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11		3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12
	3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11		3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12
	3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12		3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12
	3.11. Manifest Element: Component Identifier . . . . . . . . . 12		3.11. Manifest Element: Component Identifier . . . . . . . . . 12
	3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12		3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12
	3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 12		3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 13
	3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13		3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13
	3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13		3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13
	3.16. Manifest Element: Additional installation instructions . 13		3.16. Manifest Element: Additional installation instructions . 14
	3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14		3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14
	3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14		3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14
	3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14		3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 15
	3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14		3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15
	3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15		3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15
	3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15		3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15
	3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15		3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 16
	3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15		3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 16
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 15		4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16		4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16
	4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16		4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17
	4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16		4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17
	4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old		4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old
	Firmware . . . . . . . . . . . . . . . . . . . . . . 16		Firmware . . . . . . . . . . . . . . . . . . . . . . 17
	4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17		4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17
	4.2.4. THREAT.IMG.FORMAT: The target device misinterprets		4.2.4. THREAT.IMG.FORMAT: The target device misinterprets
	the type of payload . . . . . . . . . . . . . . . . . 17		the type of payload . . . . . . . . . . . . . . . . . 18
	4.2.5. THREAT.IMG.LOCATION: The target device installs the		4.2.5. THREAT.IMG.LOCATION: The target device installs the
	payload to the wrong location . . . . . . . . . . . . 18		payload to the wrong location . . . . . . . . . . . . 18
	4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic		4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
	payload hosting . . . . . . . . . . . . . . . . . . . 18		payload hosting . . . . . . . . . . . . . . . . . . . 19
	4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18		4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 19
	4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19		4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19
	4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 19		4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 20
	4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor		4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
	images . . . . . . . . . . . . . . . . . . . . . . . 19		images . . . . . . . . . . . . . . . . . . . . . . . 20
	4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20		4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20
	4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of		4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of
	Firmware Image for Vulnerability Analysis . . . . . . 21		Firmware Image for Vulnerability Analysis . . . . . . 22
	4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest		4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
	Elements . . . . . . . . . . . . . . . . . . . . . . 22		Elements . . . . . . . . . . . . . . . . . . . . . . 22
	4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element		4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
	Exposure . . . . . . . . . . . . . . . . . . . . . . 22		Exposure . . . . . . . . . . . . . . . . . . . . . . 23
	4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22		4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 23
	4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 22		4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 23
	4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or		4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or
	payload prior to signing . . . . . . . . . . . . . . 23		payload prior to signing . . . . . . . . . . . . . . 23
	4.3. Security Requirements . . . . . . . . . . . . . . . . . . 23		4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between
	4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 23		authentication and use . . . . . . . . . . . . . . . 24
	4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24		4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24
	4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 24		4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24
	4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 24		4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 25
			4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 25
			4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 25
	4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25		4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25
	4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC:		4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC:
	Authenticated Storage Location . . . . . . . . . . . 25		Authenticated Storage Location . . . . . . . . . . . 26
	4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote		4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote
	Resource Location . . . . . . . . . . . . . . . . . . 25		Resource Location . . . . . . . . . . . . . . . . . . 26
	4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 25		4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 26
	4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor		4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
	images . . . . . . . . . . . . . . . . . . . . . . . 26		images . . . . . . . . . . . . . . . . . . . . . . . 26
	4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and		4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
	Class IDs . . . . . . . . . . . . . . . . . . . . . . 26		Class IDs . . . . . . . . . . . . . . . . . . . . . . 27
	4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26		4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 27
	4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 26		4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 27
	4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 27		4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 28
	4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 27		4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 28
	4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 27		4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 28
	4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 28		4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 29
	4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing		4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing
	keys . . . . . . . . . . . . . . . . . . . . . . . . 28		keys . . . . . . . . . . . . . . . . . . . . . . . . 29
	4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to		4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to
	deployment . . . . . . . . . . . . . . . . . . . . . 28		deployment . . . . . . . . . . . . . . . . . . . . . 29
	4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a		4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a
	trusted environment . . . . . . . . . . . . . . . . . 28		trusted environment . . . . . . . . . . . . . . . . . 29
	4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29		4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between
			check and use . . . . . . . . . . . . . . . . . . . . 29
			4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 30
	4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation		4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
	Instructions . . . . . . . . . . . . . . . . . . . . 29		Instructions . . . . . . . . . . . . . . . . . . . . 30
	4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 29		4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 30
	4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest		4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest
	Elements . . . . . . . . . . . . . . . . . . . . . . 29		Elements . . . . . . . . . . . . . . . . . . . . . . 31
	4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 30		4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 31
	4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 30		4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 31
	4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 30		4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 32
	4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential		4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
	Information Disclosures . . . . . . . . . . . . . . . 30		Information Disclosures . . . . . . . . . . . . . . . 32
	4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from		4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from
	Unpacking Unknown Formats . . . . . . . . . . . . . . 31		Unpacking Unknown Formats . . . . . . . . . . . . . . 32
	4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version		4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version
	Numbers of Target Firmware . . . . . . . . . . . . . 31		Numbers of Target Firmware . . . . . . . . . . . . . 32
	4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose		4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose
	Between Images . . . . . . . . . . . . . . . . . . . 31		Between Images . . . . . . . . . . . . . . . . . . . 33
	4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using		4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
	Manifests . . . . . . . . . . . . . . . . . . . . . . 31		Manifests . . . . . . . . . . . . . . . . . . . . . . 33
	4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32		4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 33
	4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 32		4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 33
	4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 32		4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 33
	4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in		4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
	Manifest . . . . . . . . . . . . . . . . . . . . . . 32		Manifest . . . . . . . . . . . . . . . . . . . . . . 34
	4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 32
	4.5. Usability Requirements . . . . . . . . . . . . . . . . . 32
	4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33
	4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
	Resource Location . . . . . . . . . . . . . . . . . . 33
	4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 33		4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 34
	4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 34		4.5. Usability Requirements . . . . . . . . . . . . . . . . . 34
	4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 34		4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 34
	4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 35		4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
	4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 35		Resource Location . . . . . . . . . . . . . . . . . . 34
	4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 35		4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 35
	4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 36		4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 36
	4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 36		4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 36
	4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 36		4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 36
	4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 36		4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 37
			4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 37
			4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 37
			4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37
			4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 38
			4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 39
	4.5.13. REQ.USE.DELEGATION: Delegation of Authority in		4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
	Manifest . . . . . . . . . . . . . . . . . . . . . . 37		Manifest . . . . . . . . . . . . . . . . . . . . . . 39
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	7.1. Normative References . . . . . . . . . . . . . . . . . . 37		7.1. Normative References . . . . . . . . . . . . . . . . . . 40
	7.2. Informative References . . . . . . . . . . . . . . . . . 38		7.2. Informative References . . . . . . . . . . . . . . . . . 40
	Appendix A. Mailing List Information . . . . . . . . . . . . . . 39		Appendix A. Mailing List Information . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
	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 enables 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 user		list of the threats against IoT devices, nor of the possible user
	stories that describe how to conduct a firmware update. Instead they		stories that describe how to conduct a firmware update. Instead they
	are intended to describe the threats against firmware updates in		are intended to describe the threats against firmware updates in
	isolation and provide sufficient motivation to specify the		isolation and provide sufficient motivation to specify the
	information elements that cover a wide range of user stories. The		information elements that cover a wide range of user stories. The
	information model does not define the serialization, encoding,		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, various 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 domain of application and which		which threats exist in a particular domain of application and which
	user stories are required. Elements marked as mandatory provide		user stories are required. Elements marked as REQUIRED provide
	baseline security and usability properties that are expected to be		baseline security and usability properties that are expected to be
	required for most applications. Those elements are mandatory to		required for most applications. Those elements are REQUIRED to
	implement and mandatory to use. Elements marked as recommended		implement and REQUIRED to use. Elements marked as recommended
	provide important security or usability properties that are needed on		provide important security or usability properties that are needed on
	most devices. Elements marked as optional enable security or		most devices. Elements marked as optional enable security or
	usability properties that are useful in some applications.		usability properties that are useful in some applications.
	The definition of some of the information elements include examples		The definition of some of the information elements include examples
	that illustrate their semantics and how they are intended to be used.		that illustrate their semantics and how they are intended to be used.
	2. Conventions and Terminology		2. Conventions and Terminology
	This document uses terms defined in [I-D.ietf-suit-architecture].		This document uses terms defined in [I-D.ietf-suit-architecture].
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 39 ¶
	Each manifest information element is anchored in a security		Each manifest information element is anchored in a security
	requirement or a usability requirement. The manifest elements are		requirement or a usability requirement. The manifest elements are
	described below, justified by their requirements.		described below, justified by their requirements.
	3.1. Manifest Element: Version ID 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 REQUIRED 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. This number MUST be easily accessible so that code		management. This number MUST be easily accessible so that code
	choosing one out of several manifests can choose which is the latest.		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 REQUIRED and is necessary to prevent malicious actors
	actors from reverting a firmware update against the policies of the		from reverting a firmware update against the policies of the relevant
	relevant authority.		authority.
	Implements: REQ.SEC.SEQUENCE (Section 4.3.1)		Implements: REQ.SEC.SEQUENCE (Section 4.3.1)
	3.3. Manifest Element: Vendor ID		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 [RFC4122] version 5 UUIDs with the vendor's domain name and		is to use [RFC4122] version 5 UUIDs with the vendor's domain name and
	the DNS name space ID. Other options include type 1 and type 4		the DNS name space ID. Other options include type 1 and type 4
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 47 ¶
	o XclassId = UUID5(vendorId, "Product X")		o XclassId = UUID5(vendorId, "Product X")
	o YclassId = UUID5(vendorId, "Product Y")		o YclassId = UUID5(vendorId, "Product Y")
	o 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.4.4. Example 4: White-labelling
			Vendor A creates a product A and its firmware. Vendor B sells the
			product under its own name as Product B with some customised
			configuration. The vendors create the Class IDs as follows:
			o vendorIdA = UUID5(DNS, "vendor-a.com")
			o classIdA = UUID5(vendorIdA, "Product A-Unlabelled")
			o vendorIdB = UUID5(DNS, "vendor-b.com")
			o classIdB = UUID5(vendorIdB, "Product B")
			The product will match against each of these class IDs. If Vendor A
			and Vendor B provide different components for the device, the
			implementor MAY choose to make ID matching scoped to each component.
			Then, the vendorIdA, classIdA match the component ID supplied by
			Vendor A, and the vendorIdB, classIdB match the component ID supplied
			by Vendor B.
	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 OPTIONAL to implement.		This element is OPTIONAL to implement.
	Enables feature: differential updates.		Enables feature: differential updates.
	skipping to change at page 10, line 43 ¶		skipping to change at page 11, line 17 ¶
	predictably.		predictably.
	Implements: REQ.SEC.EXP (Section 4.3.3)		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 in an		The format of the payload MUST be indicated to devices 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 REQUIRED and MUST be present to enable devices to
	decode payloads correctly.		decode payloads correctly.
	Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT		Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT
	(Section 4.5.5)		(Section 4.5.5)
	3.9. Manifest Element: Processing Steps		3.9. Manifest Element: Processing Steps
	A representation of the Processing Steps required to decode a		A representation of the Processing Steps required to decode a
	payload. The representation MUST describe which algorithm(s) is used		payload. The representation MUST describe which algorithm(s) is used
	and any additional parameters required by the algorithm(s). The		and any additional parameters required by the algorithm(s). The
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 46 ¶
	Enables feature: Encrypted, compressed, packed formats		Enables feature: Encrypted, compressed, packed formats
	Implements: REQ.USE.IMG.NESTED (Section 4.5.6)		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 where to store a payload within a given		This element tells the device where to store a payload within a given
	component. The device can use this to establish which permissions		component. The device can use this to establish which permissions
	are necessary and the physical storage 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 REQUIRED and MUST be present to enable devices to
	store payloads to the correct location.		store payloads to the correct location.
	Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)		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 Author chooses two		ensure compatibility between the components. The Author chooses two
	storage identifiers:		storage identifiers:
	skipping to change at page 12, line 34 ¶		skipping to change at page 13, line 4 ¶
	Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)		Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)
	3.12. Manifest Element: Resource Indicator		3.12. Manifest Element: Resource Indicator
	This element provides the information required for the device to		This element provides the information required for the device to
	acquire the resource. This can be encoded in several ways:		acquire the resource. This can be encoded in several ways:
	o One URI		o One URI
	o A list of URIs		o A list of URIs
	o A prioritised list of URIs		o A prioritised list of URIs
	o A list of signed 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.
	N.B. Devices will typically require URIs.		N.B. Devices will typically require URIs.
	Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)		Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
	3.13. Manifest Element: Payload Digests		3.13. Manifest Element: Payload Digests
	This element contains one or more digests of one or more payloads.		This element contains one or more digests of one or more payloads.
	This allows the target device to ensure authenticity of the		This allows the target device to ensure authenticity of the
	payload(s). A serialisation MUST provide a mechanism to select one		payload(s). A serialisation MUST provide a mechanism to select one
	payload from a list based on system parameters, such as Execute-In-		payload from a list based on system parameters, such as Execute-In-
	Place Installation Address.		Place Installation Address.
	This element is MANDATORY to implement and fundamentally necessary to		This element is REQUIRED to implement and fundamentally necessary to
	ensure the authenticity and integrity of the payload. Support for		ensure the authenticity and integrity of the payload. Support for
	more than one digest is OPTIONAL to implement in a recipient device.		more than one digest is OPTIONAL to implement in a recipient device.
	Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT		Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT
	(Section 4.5.8)		(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		Variable-size storage locations MUST be set to exactly the size
	listed in this element.		listed in this element.
	This element is MANDATORY and informs the target device how big of a		This element is REQUIRED 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: REQ.SEC.AUTH.EXEC (Section 4.3.8)		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		wrapped by a standardised authentication container, such as a COSE
	([RFC8152]) or CMS ([RFC5652]) signature object. The authentication		([RFC8152]) or CMS ([RFC5652]) signature object. The authentication
	container MUST support multiple actors and multiple authentication		container MUST support multiple actors and multiple authentication
	methods.		methods.
	This element is MANDATORY and represents the foundation of all		This element is REQUIRED in non-dependency manifests and represents
	security properties of the manifest. There are two exceptions to		the foundation of all security properties of the manifest. Manifests
	this requirement: 1) if the manifest is authenticated by a second		which are included as dependencies by another manifest SHOULD include
	manifest as a dependency and 2) if the manifest is authenticated by		a signature so that the recipient can distinguish between different
	channel security and contains only channel information (such as		actors with different permissions.
	URIs).
			A manifest MUST NOT be considered authenticated by channel security
			even if it contains only channel information (such as URIs). If the
			authenticated remote or channel were compromised, the threat actor
			could induce recipients to queries traffic over any accessible
			network. Lightweight authentication with pre-existing relationships
			SHOULD be done with MAC.
	Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS		Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS
	(Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4)		(Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4)
	3.16. Manifest Element: Additional installation instructions		3.16. Manifest Element: Additional installation instructions
	Instructions that the device should execute when processing the		Instructions that the device should execute when processing the
	manifest. This information is distinct from the information		manifest. This information is distinct from the information
	necessary to process a payload. Additional installation instructions		necessary to process a payload. Additional installation instructions
	include information such as update timing (for example, install only		include information such as update timing (for example, install only
	skipping to change at page 14, line 23 ¶		skipping to change at page 14, line 49 ¶
	This element is OPTIONAL and enables some user stories.		This element is OPTIONAL and enables some user stories.
	Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)		Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)
	3.18. Manifest Element: Dependencies		3.18. Manifest Element: Dependencies
	A list of other manifests that are required by the current manifest.		A list of other manifests that are required by the current manifest.
	Manifests are identified an unambiguous way, such as a digest.		Manifests are identified an unambiguous way, such as a digest.
	This element is MANDATORY to use in deployments that include both		This element is REQUIRED to use in deployments that include both
	multiple authorities and multiple payloads.		multiple authorities and multiple payloads.
	Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)		Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)
	3.19. Manifest Element: Encryption Wrapper		3.19. Manifest Element: Encryption Wrapper
	Encrypting firmware images requires symmetric content encryption		Encrypting firmware images requires symmetric content encryption
	keys. The encryption wrapper provides the information needed for a		keys. The encryption wrapper provides the information needed for a
	device to obtain or locate a key that it uses to decrypt the		device to obtain or locate a key that it uses to decrypt the
	firmware. Typical choices for an encryption wrapper include CMS		firmware. Typical choices for an encryption wrapper include CMS
	([RFC5652]) or COSE ([RFC8152]). This MAY be included in a		([RFC5652]) or COSE ([RFC8152]). This MAY be included in a
	decryption step contained in Processing Steps (Section 3.9).		decryption step contained in Processing Steps (Section 3.9).
	This element is MANDATORY to use for encrypted payloads,		This element is REQUIRED to use for encrypted payloads,
	Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)		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
	skipping to change at page 23, line 38 ¶		skipping to change at page 24, line 16 ¶
	or signing service that watches manifest creation activities and		or signing service that watches manifest creation activities and
	inserts code into any binary that is referenced by a manifest.		inserts code into any binary that is referenced by a manifest.
	For example, the attacker deploys malware to the developer's computer		For example, the attacker deploys malware to the developer's computer
	or signing service that replaces the referenced binary (digest) and		or signing service that replaces the referenced binary (digest) and
	URI with the attacker's binary (digest) and URI.		URI with the attacker's binary (digest) and URI.
	Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18),		Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18),
	REQ.SEC.MFST.TRUSTED (Section 4.3.19)		REQ.SEC.MFST.TRUSTED (Section 4.3.19)
			4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between
			authentication and use
			Classification: All Types
			If an attacker can modify a manifest after it is authenticated (Time
			Of Check) but before it is used (Time Of Use), then the attacker can
			place any content whatsoever in the manifest.
			Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20)
	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. REQ.SEC.SEQUENCE: 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.
	skipping to change at page 28, line 19 ¶		skipping to change at page 29, line 15 ¶
	4.3.16. REQ.SEC.REPORTING: Secure Reporting		4.3.16. REQ.SEC.REPORTING: Secure Reporting
	Status reports from the device to any remote system SHOULD be		Status reports from the device to any remote system SHOULD be
	performed over an authenticated, confidential channel in order to		performed over an authenticated, confidential channel in order to
	prevent modification or spoofing of the reports.		prevent modification or spoofing of the reports.
	Mitigates: THREAT.NET.MITM (Section 4.2.7)		Mitigates: THREAT.NET.MITM (Section 4.2.7)
	4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys		4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys
	Cryptographic keys for signing manifests SHOULD be stored in a manner		Cryptographic keys for signing/authenticating manifests SHOULD be
	that is inaccessible to networked devices, for example in an HSM, or		stored in a manner that is inaccessible to networked devices, for
	an air-gapped computer. This protects against an attacker obtaining		example in an HSM, or an air-gapped computer. This protects against
	the keys.		an attacker obtaining the keys.
	Keys SHOULD be stored in a way that limits the risk of a legitimate,		Keys SHOULD be stored in a way that limits the risk of a legitimate,
	but compromised, entity (such as a server or developer computer)		but compromised, entity (such as a server or developer computer)
	issuing signing requests.		issuing signing requests.
	Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16)		Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16)
	4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment		4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment
	Manifests SHOULD be parsed and examined prior to deployment to		Manifests SHOULD be parsed and examined prior to deployment to
	skipping to change at page 29, line 5 ¶		skipping to change at page 29, line 46 ¶
	For high risk deployments, such as large numbers of devices or		For high risk deployments, such as large numbers of devices or
	critical function devices, manifests SHOULD be constructed in an		critical function devices, manifests SHOULD be constructed in an
	environment that is protected from interference, such as an air-		environment that is protected from interference, such as an air-
	gapped computer. Note that a networked computer connected to an HSM		gapped computer. Note that a networked computer connected to an HSM
	does not fulfill this requirement (see THREAT.MFST.MODIFICATION		does not fulfill this requirement (see THREAT.MFST.MODIFICATION
	(Section 4.2.17)).		(Section 4.2.17)).
	Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)		Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
			4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and
			use
			Both the manifest and any data extracted from it MUST be held
			immutable between its authenticity verification (time of check) and
			its use (time of use). To make this guarantee, the manifest MUST fit
			within an internal memory or a secure memory, such as encrypted
			memory. The recipient SHOULD defend the manifest from tampering by
			code or hardware resident in the recipient, for example other
			processes or debuggers.
			If an application requires that the manifest is verified before
			storing it, then this means the manifest MUST fit in RAM.
			Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18)
	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. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions		4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions
	As a 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.
	skipping to change at page 32, line 20 ¶		skipping to change at page 33, line 38 ¶
	secure execution/boot.		secure execution/boot.
	Satisfied by: REQ.USE.LOAD (Section 4.5.10)		Satisfied by: REQ.USE.LOAD (Section 4.5.10)
	4.4.13. USER_STORY.MFST.IMG: Payload in Manifest		4.4.13. USER_STORY.MFST.IMG: Payload in Manifest
	As an operator of devices on a constrained network, I would like the		As an operator of devices on a constrained network, I would like the
	manifest to be able to include a small payload in the same packet so		manifest to be able to include a small payload in the same packet so
	that I can reduce network traffic.		that I can reduce network traffic.
			Small payloads may include, for example, wrapped encryption keys,
			encoded configuration, public keys, [RFC8392] CBOR Web Tokens, or
			X.509 certificates.
	Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11)		Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11)
	4.4.14. USER_STORY.MFST.PARSE: 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: REQ.USE.PARSE (Section 4.5.12)		Satisfied by: REQ.USE.PARSE (Section 4.5.12)
	skipping to change at page 33, line 33 ¶		skipping to change at page 35, line 7 ¶
	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 accepts payload pushes will ignore		the payload, whereas a device that accepts payload pushes will ignore
	this feature.		this feature.
	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.
	Satisfies: USER_STORY.OVERRIDE (Section 4.4.3)		Satisfies: USER_STORY.OVERRIDE (Section 4.4.3)
	Implemented by: Aliases (Section 3.17)		Implemented by: Aliases (Section 3.17)
	4.5.3. REQ.USE.MFST.COMPONENT: Component Updates		4.5.3. REQ.USE.MFST.COMPONENT: Component Updates
	It MUST be possible express the requirement to install one or more		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
	skipping to change at page 36, line 40 ¶		skipping to change at page 38, line 11 ¶
	Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12)		Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12)
	Implemented by: Load-time metadata (Section 3.21)		Implemented by: Load-time metadata (Section 3.21)
	4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure		4.5.11. REQ.USE.PAYLOAD: Payload in Manifest 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 MAY place the payload in the same packet as the		manifest. This MAY place the payload in the same packet as the
	manifest.		manifest.
			Integrated payloads may include, for example, wrapped encryption
			keys, encoded configuration, public keys, [RFC8392] CBOR Web Tokens,
			or X.509 certificates.
			When an integrated payload is provided, this increases the size of
			the manifest. Manifest size can cause several processing and storage
			concerns that require careful consideration. The payload can prevent
			the whole manifest from being contained in a single network packet,
			which can cause fragmentation and the loss of portions of the
			manifest in lossy networks. This causes the need for reassembly and
			retransmission logic. The manifest must be held immutable between
			verification and processing (see REQ.SEC.MFST.CONST
			(Section 4.3.20)), so a larger manifest will consume more memory with
			immutability guarantees, for example internal RAM or NVRAM, or
			external secure memory. If the manifest exceeds the available
			immutable memory, then it must be processed modularly, evaluating
			each of: delegation chains, the security container, and the actual
			manifest, which includes verifying the integrated payload. If the
			security model calls for downloading the manifest and validating it
			before storing to NVRAM in order to prevent wear to NVRAM and energy
			expenditure in NVRAM, then either increasing memory allocated to
			manifest storage or modular processing of the received manifest may
			be required. While the manifest has been organised to enable this
			type of processing, it creates additional complexity in the parser.
			If the manifest is stored in NVRAM prior to processing, the
			integrated payload may cause the manifest to exceed the available
			storage. Because the manifest is received prior to validation of
			applicability, authority, or correctness, integrated payloads cause
			the recipient to expend network bandwidth and energy that may not be
			required if the manifest is discarded and these costs vary with the
			size of the integrated payload.
			See also: REQ.SEC.MFST.CONST (Section 4.3.20).
	Satisfies: USER_STORY.MFST.IMG (Section 4.4.13)		Satisfies: USER_STORY.MFST.IMG (Section 4.4.13)
	Implemented by: Payload (Section 3.23)		Implemented by: Payload (Section 3.23)
	4.5.12. REQ.USE.PARSE: Simple Parsing		4.5.12. REQ.USE.PARSE: Simple Parsing
	The structure of the manifest MUST be simple to parse, without need		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.MFST.PARSE (Section 4.4.14)		Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14)
	skipping to change at page 37, line 45 ¶		skipping to change at page 40, line 10 ¶
	We would like to thank those who contributed to the development of		We would like to thank those who contributed to the development of
	this information model. In particular, we would like to thank		this information model. In particular, we would like to thank
	Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary		Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary
	Thomson.		Thomson.
	7. References		7. References
	7.1. Normative References		7.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., Tschofenig, H., Brown, D., and M. Meriac, "A
	Firmware Update Architecture for Internet of Things		Firmware Update Architecture for Internet of Things",
	Devices", draft-ietf-suit-architecture-07 (work in		draft-ietf-suit-architecture-08 (work in progress),
	progress), October 2019.		November 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>.
	[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>.
	skipping to change at page 38, line 29 ¶		skipping to change at page 40, line 39 ¶
	7.2. Informative References		7.2. Informative References
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,		RFC 5652, DOI 10.17487/RFC5652, September 2009,
	<https://www.rfc-editor.org/info/rfc5652>.		<https://www.rfc-editor.org/info/rfc5652>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
			[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
			"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
			May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	[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>.
	7.3. URIs		7.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. 58 change blocks.
	119 lines changed or deleted		213 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/