< draft-ietf-suit-information-model-06.txt		draft-ietf-suit-information-model-07.txt >
	SUIT B. Moran		SUIT B. Moran
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Informational Arm Limited		Intended status: Informational Arm Limited
	Expires: December 3, 2020 H. Birkholz		Expires: December 4, 2020 H. Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	June 01, 2020		June 02, 2020
	An Information Model for Firmware Updates in IoT Devices		An Information Model for Firmware Updates in IoT Devices
	draft-ietf-suit-information-model-06		draft-ietf-suit-information-model-07
	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.
	One component of such a firmware update is a concise and machine-		One component of such a firmware update is a concise and machine-
	processable meta-data document, or manifest, that describes the		processable meta-data document, or manifest, that describes the
	firmware image(s) and offers appropriate protection. This document		firmware image(s) and offers appropriate protection. This document
	describes the information that must be 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.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 3, 2020.		This Internet-Draft will expire on December 4, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 8		3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 8
	3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9		3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9
	3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9		3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9
	3.5. Manifest Element: Precursor Image Digest Condition . . . 10		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 . . . . . . . . . . . . 10
	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 . . . . . . . . . . 11
	3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12		3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11
	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 . . . . . . . . . . . . 13		3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 12
	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 . 14		3.16. Manifest Element: Additional installation instructions . 13
	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 . . . . . . . . . . 14
	3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15		3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14
	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 . . . . . . . . . . . . . . . . 15
	3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15		3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 16		4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16		4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16
	4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16		4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16
	4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16		4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16
	4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old		4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old
	Firmware . . . . . . . . . . . . . . . . . . . . . . 17		Firmware . . . . . . . . . . . . . . . . . . . . . . 16
	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 . . . . . . . . . . . . . . . . . 18		the type of payload . . . . . . . . . . . . . . . . . 17
	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 . . . . . . . . . . . . . . . . . . . 18
	4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18		4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18
	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 . . . . . 19
	4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor		4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
	images . . . . . . . . . . . . . . . . . . . . . . . 19		images . . . . . . . . . . . . . . . . . . . . . . . 19
	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 . . . . . . 22		Firmware Image for Vulnerability Analysis . . . . . . 21
	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 . . . . . . . . . . . . . . . . . . . . . . 22
	4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22		4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22
	4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 23		4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 22
	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.2.18. THREAT.MFST.TOCTOU: Modification of manifest between		4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between
	authentication and use . . . . . . . . . . . . . . . 23		authentication and use . . . . . . . . . . . . . . . 23
	4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24		4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24
	4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24		4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24
	4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24		4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24
	4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 25		4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 24
	4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 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 . . . . . . . . . . . 25
	4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote		4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote
	Resource Location . . . . . . . . . . . . . . . . . . 26		Resource Location . . . . . . . . . . . . . . . . . . 25
	4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 26		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 . . . . . . . . . . . . . . . . . . . . . . 26
	4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26		4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26
	4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 27		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 . . . . . . . 27
	4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 28		4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 27
	4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 28		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 . . . . . . . . . 28
	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 . . . . . . . . . . . . . . . . . . . . . . . . 28
	4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to		4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to
	deployment . . . . . . . . . . . . . . . . . . . . . 29		deployment . . . . . . . . . . . . . . . . . . . . . 28
	4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a		4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a
	trusted environment . . . . . . . . . . . . . . . . . 29		trusted environment . . . . . . . . . . . . . . . . . 29
	4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between		4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between
	check and use . . . . . . . . . . . . . . . . . . . . 29		check and use . . . . . . . . . . . . . . . . . . . . 29
	4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29		4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29
	4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation		4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
	Instructions . . . . . . . . . . . . . . . . . . . . 29		Instructions . . . . . . . . . . . . . . . . . . . . 29
	4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 30		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 . . . . . . . . . . . . . . . . . . . . . . 30		Elements . . . . . . . . . . . . . . . . . . . . . . 30
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	Information Disclosures . . . . . . . . . . . . . . . 31		Information Disclosures . . . . . . . . . . . . . . . 31
	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 . . . . . . . . . . . . . . 31
	4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version		4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version
	Numbers of Target Firmware . . . . . . . . . . . . . 32		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 . . . . . . . . . . . . . . . . . . . 32		Between Images . . . . . . . . . . . . . . . . . . . 32
	4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using		4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
	Manifests . . . . . . . . . . . . . . . . . . . . . . 32		Manifests . . . . . . . . . . . . . . . . . . . . . . 32
	4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32		4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32
	4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 33		4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 32
	4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 33		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 . . . . . . . . . . . . . . . . . . . . . . 33		Manifest . . . . . . . . . . . . . . . . . . . . . . 33
	4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 33		4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 33
	4.5. Usability Requirements . . . . . . . . . . . . . . . . . 33		4.5. Usability Requirements . . . . . . . . . . . . . . . . . 33
	4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33		4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33
	4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote		4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
	Resource Location . . . . . . . . . . . . . . . . . . 34		Resource Location . . . . . . . . . . . . . . . . . . 34
	4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 34		4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 34
	4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 35		4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 35
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37		4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37
	4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 37		4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 37
	4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 38		4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 38
	4.5.13. REQ.USE.DELEGATION: Delegation of Authority in		4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
	Manifest . . . . . . . . . . . . . . . . . . . . . . 38		Manifest . . . . . . . . . . . . . . . . . . . . . . 38
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 39		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
	7.1. Normative References . . . . . . . . . . . . . . . . . . 39		7.1. Normative References . . . . . . . . . . . . . . . . . . 39
	7.2. Informative References . . . . . . . . . . . . . . . . . 39		7.2. Informative References . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	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
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 37 ¶
	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 REQUIRED 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 REQUIRED to		required for most applications. Those elements are required to be
	implement and REQUIRED to use. Elements marked as recommended		implemented and used. Elements marked as RECOMMENDED provide
	provide important security or usability properties that are needed on		important security or usability properties that are needed on most
	most devices. Elements marked as optional enable security or		devices. Elements marked as OPTIONAL enable security or usability
	usability properties that are useful in some applications.		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].
	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		This document treats devices with a homogeneous storage architecture
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	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 REQUIRED and MUST be present in order to allow		This element is REQUIRED in order to allow devices to identify the
	devices to identify the version of the manifest data model that is in		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 REQUIRED and is necessary to prevent malicious actors		This element is REQUIRED and is necessary to prevent malicious actors
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 39 ¶
	This element is OPTIONAL.		This element is OPTIONAL.
	Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7)		Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7)
	3.7. Manifest Element: Expiration Time		3.7. Manifest Element: Expiration Time
	This element tells a device the time at which the manifest expires		This element tells a device the time at which the manifest expires
	and should no longer be used. This is only usable in conjunction		and should no longer be used. This is only usable in conjunction
	with a secure source of time.		with a secure source of time.
	This element is OPTIONAL and MAY enable user stories where a secure		This element is OPTIONAL and may enable user stories where a secure
	source of time is provided and firmware is intended to expire		source of time is provided and firmware is intended to expire
	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.
	skipping to change at page 12, line 28 ¶		skipping to change at page 12, line 21 ¶
	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.
	N.B. A serialisation MAY choose to combine Component Identifier and		N.B. A manifest format MAY choose to combine Component Identifier
	Storage Location (Section 3.10)		and Storage Location (Section 3.10)
	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
	skipping to change at page 13, line 9 ¶		skipping to change at page 12, line 50 ¶
	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 manifest format 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 REQUIRED 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)
	skipping to change at page 13, line 36 ¶		skipping to change at page 13, line 28 ¶
	This element is REQUIRED 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. The
	([RFC8152]) or CMS ([RFC5652]) signature object. The authentication		authentication container MUST support multiple signers and multiple
	container MUST support multiple actors and multiple authentication		signature algorithms.
	methods.
	This element is REQUIRED in non-dependency manifests and represents		This element is REQUIRED in non-dependency manifests and represents
	the foundation of all security properties of the manifest. Manifests		the foundation of all security properties of the manifest. Manifests
	which are included as dependencies by another manifest SHOULD include		which are included as dependencies by another manifest SHOULD include
	a signature so that the recipient can distinguish between different		a signature so that the recipient can distinguish between different
	actors with different permissions.		actors with different permissions.
	A manifest MUST NOT be considered authenticated by channel security		A manifest MUST NOT be considered authenticated by channel security
	even if it contains only channel information (such as URIs). If the		even if it contains only channel information (such as URIs). If the
	authenticated remote or channel were compromised, the threat actor		authenticated remote or channel were compromised, the threat actor
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 37 ¶
	This element is REQUIRED 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. This MAY be included in a decryption step contained in
	([RFC5652]) or COSE ([RFC8152]). This MAY be included in a		Processing Steps (Section 3.9).
	decryption step contained in Processing Steps (Section 3.9).
	This element is REQUIRED 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.
	skipping to change at page 25, line 7 ¶		skipping to change at page 24, line 45 ¶
	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.IMG.INCOMPATIBLE (Section 4.2.3)		Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
	Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition		Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition
	(Section 3.4)		(Section 3.4)
	4.3.3. REQ.SEC.EXP: Expiration Time		4.3.3. REQ.SEC.EXP: Expiration Time
	Firmware MAY expire after a given time. Devices MAY provide a secure		A firmware manifest MAY expire after a given time. Devices MAY
	clock (local or remote). If a secure clock is provided and the		provide a secure clock (local or remote). If a secure clock is
	Firmware manifest has an expiration timestamp, the device MUST reject		provided and the Firmware manifest has an expiration timestamp, the
	the manifest if current time is later than the expiration time.		device MUST reject the manifest if current time is later than the
			expiration time.
	Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2)		Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2)
	Implemented by: Expiration Time (Section 3.7)		Implemented by: Expiration Time (Section 3.7)
	4.3.4. REQ.SEC.AUTHENTIC: 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
	skipping to change at page 25, line 39 ¶		skipping to change at page 25, line 29 ¶
	Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM		Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM
	(Section 4.2.7)		(Section 4.2.7)
	Implemented by: Signature (Section 3.15), Payload Digest		Implemented by: Signature (Section 3.15), Payload Digest
	(Section 3.13)		(Section 3.13)
	4.3.5. REQ.SEC.AUTH.IMG_TYPE: 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 configuration data.
	Mitigates: THREAT.IMG.FORMAT (Section 4.2.4)		Mitigates: THREAT.IMG.FORMAT (Section 4.2.4)
	Implemented by: Payload Format (Section 3.8), Storage Location		Implemented by: Payload Format (Section 3.8), Storage Location
	(Section 3.10)		(Section 3.10)
	4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage		4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage
	Location		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
	skipping to change at page 33, line 12 ¶		skipping to change at page 33, line 6 ¶
	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,		Small payloads may include, for example, wrapped encryption keys,
	encoded configuration, public keys, [RFC8392] CBOR Web Tokens, or		configuration information, public keys, authorization tokens, or
	X.509 certificates.		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.
	skipping to change at page 34, line 34 ¶		skipping to change at page 34, line 26 ¶
	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.
	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 to 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.
	In order to enable devices with a heterogeneous storage architecture,		In order to enable devices with a heterogeneous storage architecture,
	the manifest must enable specification of both storage system and the		the manifest must enable specification of both storage system and the
	skipping to change at page 35, line 40 ¶		skipping to change at page 35, line 34 ¶
	It MUST be possible to authenticate a manifest multiple times so that		It MUST be possible to authenticate a manifest multiple times so that
	authorisations from multiple parties with different permissions can		authorisations from multiple parties with different permissions can
	be required in order to authorise installation of a manifest.		be required in order to authorise installation of a manifest.
	Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5)		Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5)
	Implemented by: Signature (Section 3.15)		Implemented by: Signature (Section 3.15)
	4.5.5. REQ.USE.IMG.FORMAT: Format Usability		4.5.5. REQ.USE.IMG.FORMAT: Format Usability
	The manifest serialisation MUST accommodate any payload format that		The manifest format MUST accommodate any payload format that an
	an Operator wishes to use. This enables the recipient to detect		Operator wishes to use. This enables the recipient to detect which
	which format the Operator has chosen. Some examples of payload		format the Operator has chosen. Some examples of payload format are:
	format are:
	o Binary		o Binary
	o Executable and Linkable Format (ELF)		o Executable and Linkable Format (ELF)
	o Differential		o Differential
	o Compressed		o Compressed
	o Packed configuration		o Packed configuration
	o Intel HEX		o Intel HEX
	o Motorola S-Record		o Motorola S-Record
	Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6)		Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6)
	USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8)		USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8)
	Implemented by: Payload Format (Section 3.8)		Implemented by: Payload Format (Section 3.8)
	4.5.6. REQ.USE.IMG.NESTED: Nested Formats		4.5.6. REQ.USE.IMG.NESTED: Nested Formats
	The manifest serialisation MUST accommodate nested formats,		The manifest format MUST accommodate nested formats, announcing to
	announcing to the target device all the nesting steps and any		the target device all the nesting steps and any parameters used by
	parameters used by those steps.		those steps.
	Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7)		Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7)
	Implemented by: Processing Steps (Section 3.9)		Implemented by: Processing Steps (Section 3.9)
	4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching		4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching
	The manifest serialisation MUST provide a method to specify multiple		The manifest format MUST provide a method to specify multiple version
	version numbers of firmware to which the manifest applies, either		numbers of firmware to which the manifest applies, either with a list
	with a list or with range matching.		or with range matching.
	Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9)		Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9)
	Implemented by: Required Image Version List (Section 3.6)		Implemented by: Required Image Version List (Section 3.6)
	4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination		4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination
	The manifest serialisation MUST provide a mechanism to list multiple		The manifest format 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.IMG.SELECT (Section 4.4.10)		Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10)
	Implemented by: XIP Address (Section 3.20)		Implemented by: XIP Address (Section 3.20)
	4.5.9. REQ.USE.EXEC: Executable Manifest		4.5.9. REQ.USE.EXEC: Executable Manifest
	It MUST be possible to describe an executable system with a manifest		It MUST be possible to describe an executable system with a manifest
	on 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 dependency. In addition, the manifest		statically linked dependency. In addition, the manifest format MUST
	serialisation MUST be able to express metadata, such as a kernel		be able to express metadata, such as a kernel command-line, used by
	command-line, used by any loader or bootloader.		any loader or bootloader.
	Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11)		Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11)
	Implemented by: Run-time metadata (Section 3.22)		Implemented by: Run-time metadata (Section 3.22)
	4.5.10. REQ.USE.LOAD: 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 cryptographic information, load-		processing of a payload, such as cryptographic information, load-
	address, and compression algorithm.		address, and compression algorithm.
	skipping to change at page 37, line 30 ¶		skipping to change at page 37, line 24 ¶
	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		Integrated payloads may include, for example, wrapped encryption
	keys, configuration data, public keys, CBOR Web Tokens [RFC8392], or		keys, configuration information, public keys, authorization tokens,
	X.509 certificates.		or X.509 certificates.
	When an integrated payload is provided, this increases the size of		When an integrated payload is provided, this increases the size of
	the manifest. Manifest size can cause several processing and storage		the manifest. Manifest size can cause several processing and storage
	concerns that require careful consideration. The payload can prevent		concerns that require careful consideration. The payload can prevent
	the whole manifest from being contained in a single network packet,		the whole manifest from being contained in a single network packet,
	which can cause fragmentation and the loss of portions of the		which can cause fragmentation and the loss of portions of the
	manifest in lossy networks. This causes the need for reassembly and		manifest in lossy networks. This causes the need for reassembly and
	retransmission logic. The manifest must be held immutable between		retransmission logic. The manifest MUST be held immutable between
	verification and processing (see REQ.SEC.MFST.CONST		verification and processing (see REQ.SEC.MFST.CONST
	(Section 4.3.20)), so a larger manifest will consume more memory with		(Section 4.3.20)), so a larger manifest will consume more memory with
	immutability guarantees, for example internal RAM or NVRAM, or		immutability guarantees, for example internal RAM or NVRAM, or
	external secure memory. If the manifest exceeds the available		external secure memory. If the manifest exceeds the available
	immutable memory, then it must be processed modularly, evaluating		immutable memory, then it MUST be processed modularly, evaluating
	each of: delegation chains, the security container, and the actual		each of: delegation chains, the security container, and the actual
	manifest, which includes verifying the integrated payload. If the		manifest, which includes verifying the integrated payload. If the
	security model calls for downloading the manifest and validating it		security model calls for downloading the manifest and validating it
	before storing to NVRAM in order to prevent wear to NVRAM and energy		before storing to NVRAM in order to prevent wear to NVRAM and energy
	expenditure in NVRAM, then either increasing memory allocated to		expenditure in NVRAM, then either increasing memory allocated to
	manifest storage or modular processing of the received manifest may		manifest storage or modular processing of the received manifest may
	be required. While the manifest has been organised to enable this		be required. While the manifest has been organised to enable this
	type of processing, it creates additional complexity in the parser.		type of processing, it creates additional complexity in the parser.
	If the manifest is stored in NVRAM prior to processing, the		If the manifest is stored in NVRAM prior to processing, the
	integrated payload may cause the manifest to exceed the available		integrated payload may cause the manifest to exceed the available
	skipping to change at page 38, line 30 ¶		skipping to change at page 38, line 24 ¶
	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)
	Implemented by: N/A		Implemented by: N/A
	4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest		4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest
	Any serialisation MUST enable the delivery of a key claim with, but		Any manifest format MUST enable the delivery of a key claim with, but
	not authenticated by, a manifest. This key claim delivers a new key		not authenticated by, a manifest. This key claim delivers a new key
	with which the recipient can verify the manifest.		with which the recipient can verify the manifest.
	Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)		Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)
	Implemented by: Key Claims (Section 3.24)		Implemented by: Key Claims (Section 3.24)
	5. IANA Considerations		5. IANA Considerations
	This document does not require any actions by IANA.		This document does not require any actions by IANA.
	skipping to change at page 39, line 41 ¶		skipping to change at page 39, line 36 ¶
	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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[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>.
	[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>.
	Authors' Addresses		Authors' Addresses
	Brendan Moran		Brendan Moran
	Arm Limited		Arm Limited
	EMail: Brendan.Moran@arm.com		EMail: Brendan.Moran@arm.com
End of changes. 44 change blocks.
	79 lines changed or deleted		63 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/