withmilestones-01.txt		withmilestones-01-02.txt
	Vulnerabilities in Internet of Things (IoT) devices have raised the need		Vulnerabilities in Internet of Things (IoT) devices have raised the need for a
	for a secure firmware update mechanism that is also suitable for constrained		secure firmware update mechanism that is also suitable for constrained devices.
	devices. Security experts, researchers, and regulators recommend that all IoT		Security experts, researchers, and regulators recommend that all IoT devices
	devices be equipped with such a mechanism. While there are many proprietary		be equipped with such a mechanism. While there are many proprietary firmware
	firmware update mechanisms in use today, there is no modern interoperable		update mechanisms in use today, there is no modern interoperable approach
	approach allowing secure updates to firmware in IoT devices. In June of 2016		allowing secure updates to firmware in IoT devices. In June 2016, the Internet
	the Internet Architecture Board organized a workshop on 'Internet		Architecture Board organized a workshop on 'Internet of Things (IoT) Software
	of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various		Update (IOTSU)', and RFC 8240 documents various requirements and challenges
	requirements and challenges that are specific to IoT devices.		that are specific to IoT devices.
	A firmware update solution consists of several components, including:		A firmware update solution consists of several components, including:
	* A mechanism to transport firmware images to compatible devices.		* A mechanism to transport firmware images to compatible devices.
	* A manifest that provides meta-data about the firmware image (such as a		* A manifest that provides meta-data about the firmware image (such as a
	firmware package identifier, the hardware the package needs to run, and		firmware package identifier, the hardware the package needs to run, and
	dependencies on other firmware packages), as well as cryptographic information		dependencies on other firmware packages), as well as cryptographic
	for protecting the firmware image in an end-to-end fashion.		information for protecting the firmware image in an end-to-end fashion.
	* The firmware image itself.		* The firmware image itself.
	This group will focus on defining a firmware update solution (taking into		The SUIT WG is defining a firmware update solution (taking into account past
	account past learnings from RFC 4108 and other firmware update solutions) that		learnings from RFC 4108 and other proprietary firmware update solutions) that
	will be usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with		are usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with ~10
	~10 KiB RAM and ~100 KiB flash. The solution may apply to more capable devices		KiB RAM and ~100 KiB flash. The solution may apply to more capable devices as
	as well. This group will not define any new transport or discovery mechanisms,		well. The SUIT WG is not defining any new transport or discovery mechanisms,
	but may describe how to use existing mechanisms within the architecture.		but may describe how to use existing mechanisms within the architecture.
	In particular this group aims to publish several documents, namely:		The SUIT WG has already completed work on two documents:
	* An IoT firmware update architecture that includes a description of the		* An IoT firmware update architecture.
	involved entities, security threats, and assumptions.		* An information model for the SUIT manifest.
	* One or more manifest format specifications.
	To support specification of manifest format(s), this group will first develop the		Now that the information model is complete, the SUIT WG has selected the CBOR
	information model for the contents of a manifest. Once there is general agreement		serialization format and the associated COSE cryptographic mechanisms to encode
	on the contents, the group will pick a small number of serialization formats such as		the SUIT manifest. The SUIT WG may consider a small number of additional
	CBOR and/or ASN.1 (and their associated cryptographic mechanisms) to encode the		formats in the future; however, to reduce the complexity of a firmware
	manifest. A small number of formats is preferred to reduce the complexity of a		management solution, a very small number of formats is preferred to enable SUIT
	firmware management solution, where each IoT device would typically only		maifest integration and interoperability with other IoT technologies and
	support one format, but the same tool or service might support all such		ecosystems. To support a wide range of deployment scenarios, the formats are
	formats. To support a wide range of deployment scenarios, the formats are
	expected to be expressive enough to allow the use of different firmware sources		expected to be expressive enough to allow the use of different firmware sources
	and permission models.		and permission models.
	This group does not aim to create a standard for a generic application software		To enable SUIT Status Tracker functionality, the SUIT WG is also defining
	update mechanism, but instead this group will focus on firmware development		extensions to determine if a particular manifest could be successfully deployed
	practices in the embedded industry. Software update solutions that target		to a device and determine if an operation was successful.
	updating software other than the firmware binaries (e.g., applications) are
	also out of scope.
	This group will aim to maintain a close relationship with silicon vendors and		In addition, the SUIT WG will work with the RATS WG to specify claims related
	OEMs that develop IoT operating systems.		to the SUIT Status Tracker that can be used to provide evidence in support of
			the architecture that has already been defined by the RATS WG.
	Milestones		The SUIT WG will continue to work with silicon vendors and OEMs that develop
			IoT operating systems to produce implementations based on SUIT WG
			specifications. In particular, the SUIT WG plans to continue to participate in
			IETF Hackathons.
	Done - Adopt "Architecture" document as WG item.		The SUIT WG document deliverables are:
			* A SUIT manifest format specification using CBOR.
			* Extensions to the SUIT manifest for optional capabilities, including:
			- firmware encryption,
			- trust domains,
			- update management, and
			- inclusion of MUD file as defined in RFC 8520.
			* A secure method for an IoT device to report on firmware update status.
	Done - Adopt a manifest information model as a WG item.		In addition, either the SUIT WG or the RATS WG will produce:
			* A set of claims for attesting to firmware update status.
	Done - Calendar item: First interoperability event at IETF 101.		Milestones
	Done - Calendar item: Second interoperability event at IETF 102.		Dec 2021 - Adopt SUIT Manifest update management document as WG item
	Done - Adopt initial manifest serialization format(s) as WG item(s).		Dec 2021 - Adopt SUIT Manifest trust domains document as WG item
	o draft-moran-suit-manifest
	Done - Submit manifest information model to the IESG for publication as Informational.		Dec 2021 - Adopt SUIT Manifest MUD extension document as WG item
	o draft-ietf-suit-information-model
	Done - Submit architecture to the IESG for publication as Informational		Mar 2022 - Decide with RATS WG in which working group the 'set of claims for attesting to
	o draft-ietf-suit-architecture		firmware update status' document should be produced
	Done - Adopt firmware encryption document as WG item.		Aug 2022 - Submit firmware encryption document to the IESG for publication as a Proposed
	o draft-ietf-suit-firmware-encryption		Standard
	Done - Adopt SUIT Status Tracker document as WG item		Sep 2022 - Submit SUIT Status Tracker document to the IESG for publication as a Proposed
	o draft-ietf-suit-report		Standard
	Feb 2022 - Submit an initial manifest serialization format to the IESG for publication as a		Nov 2022 - Submit SUIT Manifest update management document to the IESG for publication as a
	Proposed Standard.		Proposed Standard
	o draft-ietf-suit-manifest
			Nov 2022 - Submit SUIT Manifest trust domains document to the IESG for publication as a
			Proposed Standard
			Dec 2022 - Submit SUIT Manifest MUD extension document to the IESG for publication as a
			Proposed Standard
End of changes. 18 change blocks.
	51 lines changed or deleted		57 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/