< draft-ietf-suit-architecture-02.txt		draft-ietf-suit-architecture-03.txt >
	SUIT B. Moran		SUIT B. Moran
	Internet-Draft Arm Limited		Internet-Draft Arm Limited
	Intended status: Informational M. Meriac		Intended status: Informational M. Meriac
	Expires: July 20, 2019 Consultant		Expires: September 12, 2019 Consultant
	H. Tschofenig		H. Tschofenig
	Arm Limited		Arm Limited
	D. Brown		D. Brown
	Linaro		Linaro
	January 16, 2019		March 11, 2019
	A Firmware Update Architecture for Internet of Things Devices		A Firmware Update Architecture for Internet of Things Devices
	draft-ietf-suit-architecture-02		draft-ietf-suit-architecture-03
	Abstract		Abstract
	Vulnerabilities with Internet of Things (IoT) devices have raised the		Vulnerabilities with Internet of Things (IoT) devices have raised the
	need for a solid and secure firmware update mechanism that is also		need for a solid and secure firmware update mechanism that is also
	suitable for constrained devices. Incorporating such update		suitable for constrained devices. Incorporating such update
	mechanism to fix vulnerabilities, to update configuration settings as		mechanism to fix vulnerabilities, to update configuration settings as
	well as adding new functionality is recommended by security experts.		well as adding new functionality is recommended by security experts.
	This document lists requirements and describes an architecture for a		This document lists requirements and describes an architecture for a
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 20, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Agnostic to how firmware images are distributed . . . . . 6		3.1. Agnostic to how firmware images are distributed . . . . . 7
	3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 7		3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 7
	3.3. Use state-of-the-art security mechanisms . . . . . . . . 7		3.3. Use state-of-the-art security mechanisms . . . . . . . . 7
	3.4. Rollback attacks must be prevented . . . . . . . . . . . 7		3.4. Rollback attacks must be prevented . . . . . . . . . . . 8
	3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8		3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8
	3.6. Operate with a small bootloader . . . . . . . . . . . . . 8		3.6. Operate with a small bootloader . . . . . . . . . . . . . 8
	3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 8		3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 9
	3.8. Minimal impact on existing firmware formats . . . . . . . 9		3.8. Minimal impact on existing firmware formats . . . . . . . 9
	3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 9		3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 9
	3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9		3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9
	4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Communication Architecture . . . . . . . . . . . . . . . . . 11		5. Communication Architecture . . . . . . . . . . . . . . . . . 12
	6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 15		6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. Device Firmware Update Examples . . . . . . . . . . . . . . . 16		7. Device Firmware Update Examples . . . . . . . . . . . . . . . 17
	7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 16		7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 17
	7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 16		7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 17
	7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 16		7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 17
	7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 16		7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17
	8. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 17		8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 19		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	11. Mailing List Information . . . . . . . . . . . . . . . . . . 19		11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		12. Mailing List Information . . . . . . . . . . . . . . . . . . 22
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	13.1. Normative References . . . . . . . . . . . . . . . . . . 21		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	13.2. Informative References . . . . . . . . . . . . . . . . . 21		14.1. Normative References . . . . . . . . . . . . . . . . . . 23
	13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22		14.2. Informative References . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	When developing IoT devices, one of the most difficult problems to		When developing IoT devices, one of the most difficult problems to
	solve is how to update the firmware on the device. Once the device		solve is how to update the firmware on the device. Once the device
	is deployed, firmware updates play a critical part in its lifetime,		is deployed, firmware updates play a critical part in its lifetime,
	particularly when devices have a long lifetime, are deployed in		particularly when devices have a long lifetime, are deployed in
	remote or inaccessible areas where manual intervention is cost		remote or inaccessible areas where manual intervention is cost
	prohibitive or otherwise difficult. Updates to the firmware of an		prohibitive or otherwise difficult. Updates to the firmware of an
	IoT device are done to fix bugs in software, to add new		IoT device are done to fix bugs in software, to add new
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 33 ¶
	deciding whether to boot a firmware image that is present or		deciding whether to boot a firmware image that is present or
	whether to obtain and verify a new firmware image. Since the		whether to obtain and verify a new firmware image. Since the
	bootloader is a security critical component its functionality may		bootloader is a security critical component its functionality may
	be split into separate stages. Such a multi-stage bootloader may		be split into separate stages. Such a multi-stage bootloader may
	offer very basic functionality in the first stage and resides in		offer very basic functionality in the first stage and resides in
	ROM whereas the second stage may implement more complex		ROM whereas the second stage may implement more complex
	functionality and resides in flash memory so that it can be		functionality and resides in flash memory so that it can be
	updated in the future (in case bugs have been found). The exact		updated in the future (in case bugs have been found). The exact
	split of components into the different stages, the number of		split of components into the different stages, the number of
	firmware images stored by an IoT device, and the detailed		firmware images stored by an IoT device, and the detailed
	functionality varies throughout different implementations.		functionality varies throughout different implementations. A more
			detailed discussion is provided in Section 8.
	- Microcontroller (MCU for microcontroller unit): An MCU is a		- Microcontroller (MCU for microcontroller unit): An MCU is a
	compact integrated circuit designed for use in embedded systems.		compact integrated circuit designed for use in embedded systems.
	A typical microcontroller includes a processor, memory (RAM and		A typical microcontroller includes a processor, memory (RAM and
	flash), input/output (I/O) ports and other features connected via		flash), input/output (I/O) ports and other features connected via
	some bus on a single chip. The term 'system on chip (SoC)' is		some bus on a single chip. The term 'system on chip (SoC)' is
	often used for these types of devices.		often used for these types of devices.
	- System on Chip (SoC): An SoC is an integrated circuit that		- System on Chip (SoC): An SoC is an integrated circuit that
	integrates all components of a computer, such as CPU, memory,		integrates all components of a computer, such as CPU, memory,
	skipping to change at page 17, line 9 ¶		skipping to change at page 18, line 9 ¶
	will be used as a peripheral, not via shared memory. In this case,		will be used as a peripheral, not via shared memory. In this case,
	each CPU will have to be responsible for its own firmware upgrade.		each CPU will have to be responsible for its own firmware upgrade.
	It is likely that one of the CPUs will be considered a master, and		It is likely that one of the CPUs will be considered a master, and
	will direct the other CPU to do the upgrade. This configuration is		will direct the other CPU to do the upgrade. This configuration is
	commonly used to offload specific work to other CPUs. Firmware		commonly used to offload specific work to other CPUs. Firmware
	dependencies are similar to the other solutions above, sometimes		dependencies are similar to the other solutions above, sometimes
	allowing only one image to be upgraded, other times requiring several		allowing only one image to be upgraded, other times requiring several
	to be upgraded atomically. Because the updates are happening on		to be upgraded atomically. Because the updates are happening on
	multiple CPUs, upgrading the two images atomically is challenging.		multiple CPUs, upgrading the two images atomically is challenging.
	8. Example Flow		8. Bootloader
	The following example message flow illustrates the interaction for		Today, firmware updates for an Internet-connected device are expected
	distributing a firmware image to a device starting with an author		to be delivered over the Internet. Firmware updates over serial
			interfaces, such as USB or RS232, are most likely the exception
			rather than the norm. In order to fetch a manifest plus the firmware
			image a fair amount of code is required since the firmware consumer
			needs to implement
			- the Internet protocol stack for large file downloads,
			- the capability to write the received firmware image to some
			persistent storage (most likely flash memory). It may even be
			necessary to unpack, decompress or otherwise process the received
			firmware image.
			- security protocol features for communication security,
			- manifest parsing,
			- security functionality for manifest verification, and
			- functionality for remote management by a device management server.
			All these features are most likely offered by the application running
			on the device (except for basic security algorithms that may run
			either on a trusted execution environment or on a separate hardware
			security MCU/module).
			Once manifests have been processed and firmware images successfully
			downloaded and verified the device needs to hand control over to the
			bootloader. In most cases this requires the MCU to restart. The
			bootloader then determines whether the newly downloaded firmware
			image should be started. The boot process is security sensitive
			since the firmware images may, for example, be stored in off-chip
			flash memory given attackers easy access to the firmware image. The
			bootloader will have to perform additional security checks on the
			firmware image before it can be booted.
			The manifest may have been stored alongside the firmware image to
			allow re-verification of the firmware image during every boot
			attempt. Alternatively, secure boot-specific meta-data may have been
			created by the firmware consumer after a successful firmware download
			and verification process. Whether to re-use the standardized
			manifest format that was used during the initial firmware retrieval
			process or whether it is better to use a different format for the
			secure boot-specific meta-data depends on the system design. The
			manifest format does, however, have the capability to serve also as a
			building block for secure boot with its severable elements that allow
			shrinking the size of the manifest by stripping elements that are no
			longer needed.
			If the application image contains the firmware consumer
			functionality, as described above, then it is necessary that a
			working image is left on the device to ensure that the bootloader can
			roll back to a working firmware image to re-do the firmware download
			since the bootloader itself does not have enough functionality to
			fetch a firmware image plus manifest from a firmware server over the
			Internet. A multi-stage bootloader may soften this requirement at
			the expense of a more sophisticated boot process.
			For a bootloader to offer a secure boot mechanism it needs to provide
			the following features:
			- ability to access security algorithms, such as SHA-256 to compute
			a fingerprint over the firmware image and a digital signature
			algorithm.
			- access keying material directly or indirectly to utilize the
			digital signature. The device needs to have a trust anchor store.
			- ability to expose boot process-related data to the application
			firmware (such as to the device management software). This allows
			a device management server to determine whether the firmware
			update has been successful and, if not, what errors occurred.
			- to (optionally) offer attestation information (such as
			measurements).
			While the software architecture of the bootloader and also its
			security mechanism are implemention-specific the use of the manifest
			for controlling the download of the firmware over the Internet as
			well as for the secure boot process is relevant for the design of the
			manifest.
			9. Example
			The following example message flow illustrates a possible interaction
			for distributing a firmware image to a device starting with an author
	uploading the new firmware to firmware server and creating a		uploading the new firmware to firmware server and creating a
	manifest. The firmware and manifest are stored on the same firmware		manifest. The firmware and manifest are stored on the same firmware
	server.		server.
	+--------+ +-----------------+ +------------+ +----------+		+--------+ +-----------------+ +------------+ +----------+
	| Author | | Firmware Server | |FW Consuumer| |Bootloader|		| Author | | Firmware Server | |FW Consumer | |Bootloader|
	+--------+ +-----------------+ +------------+ +----------+		+--------+ +-----------------+ +------------+ +----------+
	| | | +		| | | +
	| Create Firmware | | |		| Create Firmware | | |
	|--------------- | | |		|--------------- | | |
	| | | | |		| | | | |
	|<-------------- | | |		|<-------------- | | |
	| | | |		| | | |
	| Upload Firmware | | |		| Upload Firmware | | |
	|------------------>| | |		|------------------>| | |
	| | | |		| | | |
	skipping to change at page 18, line 26 ¶		skipping to change at page 21, line 16 ¶
	| | | Store |		| | | Store |
	| | | Firmware |		| | | Firmware |
	| | |-------------- |		| | |-------------- |
	| | | | |		| | | | |
	| | |<------------- |		| | |<------------- |
	| | | |		| | | |
	| | | |		| | | |
	| | | Reboot |		| | | Reboot |
	| | |--------------->|		| | |--------------->|
	| | | |		| | | |
	| | | Validate |		| | | Verify |
	| | | Firmware |		| | | Firmware |
	| | | ---------------|		| | | ---------------|
	| | | | |		| | | | |
	| | | -------------->|		| | | -------------->|
	| | | |		| | | |
	| | | Activate new |		| | | Activate new |
	| | | Firmware |		| | | Firmware |
	| | | ---------------|		| | | ---------------|
	| | | | |		| | | | |
	| | | -------------->|		| | | -------------->|
	| | | |		| | | |
	| | | Boot new |		| | | Boot new |
	| | | Firmware |		| | | Firmware |
	| | | ---------------|		| | | ---------------|
	| | | | |		| | | | |
	| | | -------------->|		| | | -------------->|
	| | | |		| | | |
	Figure 5: Example Flow for a Firmware Upate.		Figure 5: Example Flow for a Firmware Upate.
	9. IANA Considerations		10. IANA Considerations
	This document does not require any actions by IANA.		This document does not require any actions by IANA.
	10. Security Considerations		11. Security Considerations
	Firmware updates fix security vulnerabilities and are considered to		Firmware updates fix security vulnerabilities and are considered to
	be an important building block in securing IoT devices. Due to the		be an important building block in securing IoT devices. Due to the
	importance of firmware updates for IoT devices the Internet		importance of firmware updates for IoT devices the Internet
	Architecture Board (IAB) organized a 'Workshop on Internet of Things		Architecture Board (IAB) organized a 'Workshop on Internet of Things
	(IoT) Software Update (IOTSU)', which took place at Trinity College		(IoT) Software Update (IOTSU)', which took place at Trinity College
	Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at		Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at
	the big picture. A report about this workshop can be found at		the big picture. A report about this workshop can be found at
	[RFC8240]. A standardized firmware manifest format providing end-to-		[RFC8240]. A standardized firmware manifest format providing end-to-
	end security from the author to the device will be specified in a		end security from the author to the device will be specified in a
	skipping to change at page 19, line 45 ¶		skipping to change at page 22, line 34 ¶
	involvement.		involvement.
	- energy efficiency and battery lifetime considerations.		- energy efficiency and battery lifetime considerations.
	- key management required for verifying the digital signature		- key management required for verifying the digital signature
	protecting the manifest.		protecting the manifest.
	- incentives for manufacturers to offer a firmware update mechanism		- incentives for manufacturers to offer a firmware update mechanism
	as part of their IoT products.		as part of their IoT products.
	11. Mailing List Information		12. Mailing List Information
	The discussion list for this document is located at the e-mail		The discussion list for this document is located at the e-mail
	address suit@ietf.org [1]. Information on the group and information		address suit@ietf.org [1]. Information on the group and information
	on how to subscribe to the list is at		on how to subscribe to the list is at
	https://www1.ietf.org/mailman/listinfo/suit [2]		https://www1.ietf.org/mailman/listinfo/suit [2]
	Archives of the list can be found at: https://www.ietf.org/mail-		Archives of the list can be found at: https://www.ietf.org/mail-
	archive/web/suit/current/index.html [3]		archive/web/suit/current/index.html [3]
	12. Acknowledgements		13. Acknowledgements
	We would like to thank the following persons for their feedback:		We would like to thank the following persons for their feedback:
	- Geraint Luff		- Geraint Luff
	- Amyas Phillips		- Amyas Phillips
	- Dan Ros		- Dan Ros
	- Thomas Eichinger		- Thomas Eichinger
	- Michael Richardson		- Michael Richardson
	- Emmanuel Baccelli		- Emmanuel Baccelli
	- Ned Smith		- Ned Smith
	skipping to change at page 21, line 4 ¶		skipping to change at page 23, line 40 ¶
	- Markus Gueller		- Markus Gueller
	- Henk Birkholz		- Henk Birkholz
	- Jintao Zhu		- Jintao Zhu
	- Takeshi Takahashi		- Takeshi Takahashi
	We would also like to thank the WG chairs, Russ Housley, David		We would also like to thank the WG chairs, Russ Housley, David
	Waltermire, Dave Thaler for their support and their reviews.		Waltermire, Dave Thaler for their support and their reviews.
	Kathleen Moriarty was the responsible security area director when		Kathleen Moriarty was the responsible security area director when
	this work was started.		this work was started.
	13. References		14. References
	13.1. Normative References		14.1. Normative References
	[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>.
	[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer		[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
	Security (TLS) / Datagram Transport Layer Security (DTLS)		Security (TLS) / Datagram Transport Layer Security (DTLS)
	Profiles for the Internet of Things", RFC 7925,		Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,		DOI 10.17487/RFC7925, July 2016,
	<https://www.rfc-editor.org/info/rfc7925>.		<https://www.rfc-editor.org/info/rfc7925>.
	13.2. Informative References		14.2. Informative References
	[I-D.ietf-suit-information-model]		[I-D.ietf-suit-information-model]
	Moran, B., Tschofenig, H., and H. Birkholz, "Firmware		Moran, B., Tschofenig, H., and H. Birkholz, "Firmware
	Updates for Internet of Things Devices - An Information		Updates for Internet of Things Devices - An Information
	Model for Manifests", draft-ietf-suit-information-model-01		Model for Manifests", draft-ietf-suit-information-model-02
	(work in progress), July 2018.		(work in progress), January 2019.
	[LwM2M] OMA, ., "Lightweight Machine to Machine Technical		[LwM2M] OMA, ., "Lightweight Machine to Machine Technical
	Specification, Version 1.0.2", February 2018,		Specification, Version 1.0.2", February 2018,
	<http://www.openmobilealliance.org/release/LightweightM2M/		<http://www.openmobilealliance.org/release/LightweightM2M/
	V1_0_2-20180209-A/		V1_0_2-20180209-A/
	OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf>.		OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf>.
	[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard		[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
	(AES) Key Wrap with Padding Algorithm", RFC 5649,		(AES) Key Wrap with Padding Algorithm", RFC 5649,
	DOI 10.17487/RFC5649, September 2009,		DOI 10.17487/RFC5649, September 2009,
	skipping to change at page 22, line 5 ¶		skipping to change at page 24, line 39 ¶
	[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management		[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
	Requirements", RFC 6024, DOI 10.17487/RFC6024, October		Requirements", RFC 6024, DOI 10.17487/RFC6024, October
	2010, <https://www.rfc-editor.org/info/rfc6024>.		2010, <https://www.rfc-editor.org/info/rfc6024>.
	[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet		[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
	of Things Software Update (IoTSU) Workshop 2016",		of Things Software Update (IoTSU) Workshop 2016",
	RFC 8240, DOI 10.17487/RFC8240, September 2017,		RFC 8240, DOI 10.17487/RFC8240, September 2017,
	<https://www.rfc-editor.org/info/rfc8240>.		<https://www.rfc-editor.org/info/rfc8240>.
	13.3. URIs		14.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
	[3] https://www.ietf.org/mail-archive/web/suit/current/index.html		[3] https://www.ietf.org/mail-archive/web/suit/current/index.html
	Authors' Addresses		Authors' Addresses
	Brendan Moran		Brendan Moran
End of changes. 25 change blocks.
	42 lines changed or deleted		128 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/