< draft-ietf-teep-protocol-04.txt		draft-ietf-teep-protocol-05.txt >
	TEEP H. Tschofenig		TEEP H. Tschofenig
	Internet-Draft Arm Ltd.		Internet-Draft Arm Ltd.
	Intended status: Standards Track M. Pei		Intended status: Standards Track M. Pei
	Expires: May 6, 2021 Broadcom		Expires: August 26, 2021 Broadcom
	D. Wheeler		D. Wheeler
	Intel		Intel
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	A. Tsukamoto		A. Tsukamoto
	AIST		AIST
	November 2, 2020		February 22, 2021
	Trusted Execution Environment Provisioning (TEEP) Protocol		Trusted Execution Environment Provisioning (TEEP) Protocol
	draft-ietf-teep-protocol-04		draft-ietf-teep-protocol-05
	Abstract		Abstract
	This document specifies a protocol that installs, updates, and		This document specifies a protocol that installs, updates, and
	deletes Trusted Applications (TAs) in a device with a Trusted		deletes Trusted Applications (TAs) in a device with a Trusted
	Execution Environment (TEE). This specification defines an		Execution Environment (TEE). This specification defines an
	interoperable protocol for managing the lifecycle of TAs.		interoperable protocol for managing the lifecycle of TAs.
	The protocol name is pronounced teepee. This conjures an image of a		The protocol name is pronounced teepee. This conjures an image of a
	wedge-shaped protective covering for one's belongings, which sort of		wedge-shaped protective covering for one's belongings, which sort of
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 6, 2021.		This Internet-Draft will expire on August 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 4		3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 4
	4. Detailed Messages Specification . . . . . . . . . . . . . . . 6		4. Detailed Messages Specification . . . . . . . . . . . . . . . 5
	4.1. Creating and Validating TEEP Messages . . . . . . . . . . 6		4.1. Creating and Validating TEEP Messages . . . . . . . . . . 6
	4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 6		4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 6
	4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6		4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6
	4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 7		4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 7
	4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9		4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9
	4.4. Install Message . . . . . . . . . . . . . . . . . . . . . 12		4.3.1. Evidence . . . . . . . . . . . . . . . . . . . . . . 12
	4.5. Delete Message . . . . . . . . . . . . . . . . . . . . . 13		4.4. Update Message . . . . . . . . . . . . . . . . . . . . . 13
	4.6. Success Message . . . . . . . . . . . . . . . . . . . . . 14		4.5. Success Message . . . . . . . . . . . . . . . . . . . . . 14
	4.7. Error Message . . . . . . . . . . . . . . . . . . . . . . 14		4.6. Error Message . . . . . . . . . . . . . . . . . . . . . . 15
	5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 17		5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 18
	6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 17		6. Behavior Specification . . . . . . . . . . . . . . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6.1. TAM Behavior . . . . . . . . . . . . . . . . . . . . . . 19
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6.2. TEEP Agent Behavior . . . . . . . . . . . . . . . . . . . 20
	8.1. Media Type Registration . . . . . . . . . . . . . . . . . 20		7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 21		8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	8.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	8.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 21		9.1. Media Type Registration . . . . . . . . . . . . . . . . . 23
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		9.2. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 24
	9.1. Normative References . . . . . . . . . . . . . . . . . . 22		9.3. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 24
	9.2. Informative References . . . . . . . . . . . . . . . . . 23		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24		10.1. Normative References . . . . . . . . . . . . . . . . . . 25
	B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24		10.2. Informative References . . . . . . . . . . . . . . . . . 26
	C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 24		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
	D. Examples of Diagnostic Notation and Binary Representation . . 27		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
	D.1. Some assumptions in examples . . . . . . . . . . . . . . 27		C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 27
	D.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 28		D. Examples of Diagnostic Notation and Binary Representation . . 30
	D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 28		D.1. Some assumptions in examples . . . . . . . . . . . . . . 30
	D.2.2. CBOR Binary Representation . . . . . . . . . . . . . 28		D.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 31
	D.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 29		D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 31
	D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 29		D.2.2. CBOR Binary Representation . . . . . . . . . . . . . 31
	D.3.2. CBOR Binary Representation . . . . . . . . . . . . . 29		D.3. Entity Attestation Token . . . . . . . . . . . . . . . . 31
	D.4. Install Message . . . . . . . . . . . . . . . . . . . . . 29		D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 32
	D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 29		D.4. QueryResponse Message . . . . . . . . . . . . . . . . . . 32
	D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 30		D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 32
	D.5. Success Message (for Install) . . . . . . . . . . . . . . 30		D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 33
	D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 30		D.5. Update Message . . . . . . . . . . . . . . . . . . . . . 34
	D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 30		D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 34
	D.6. Error Message (for Install) . . . . . . . . . . . . . . . 30		D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 35
	D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 30		D.6. Success Message . . . . . . . . . . . . . . . . . . . . . 35
	D.6.2. CBOR binary Representation . . . . . . . . . . . . . 31		D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		D.6.2. CBOR Binary Representation . . . . . . . . . . . . . 35
			D.7. Error Message . . . . . . . . . . . . . . . . . . . . . . 35
			D.7.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35
			D.7.2. CBOR binary Representation . . . . . . . . . . . . . 36
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	The Trusted Execution Environment (TEE) concept has been designed to		The Trusted Execution Environment (TEE) concept has been designed to
	separate a regular operating system, also referred as a Rich		separate a regular operating system, also referred as a Rich
	Execution Environment (REE), from security-sensitive applications.		Execution Environment (REE), from security-sensitive applications.
	In a TEE ecosystem, device vendors may use different operating		In a TEE ecosystem, device vendors may use different operating
	systems in the REE and may use different types of TEEs. When TA		systems in the REE and may use different types of TEEs. When TA
	Developers or Device Administrators use Trusted Application Managers		Developers or Device Administrators use Trusted Application Managers
	(TAMs) to install, update, and delete Trusted Applications (TAs) on a		(TAMs) to install, update, and delete Trusted Applications (TAs) on a
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 16 ¶
	treats each TA, any dependencies the TA has, and personalization data		treats each TA, any dependencies the TA has, and personalization data
	as separate components that are expressed in SUIT manifests, and a		as separate components that are expressed in SUIT manifests, and a
	SUIT manifest might contain or reference multiple binaries (see		SUIT manifest might contain or reference multiple binaries (see
	[I-D.ietf-suit-manifest] for more details).		[I-D.ietf-suit-manifest] for more details).
	As such, the term Trusted Component in this document refers to a set		As such, the term Trusted Component in this document refers to a set
	of binaries expressed in a SUIT manifest, to be installed in a TEE.		of binaries expressed in a SUIT manifest, to be installed in a TEE.
	Note that a Trusted Component may include one or more TAs and/or		Note that a Trusted Component may include one or more TAs and/or
	configuration data and keys needed by a TA to operate correctly.		configuration data and keys needed by a TA to operate correctly.
	Each Trusted Component is uniquely identified by a "component-id"		Each Trusted Component is uniquely identified by a SUIT Component
	byte string, such as a 16-byte UUID [RFC4122]. If Concise Software		Identifier (see [I-D.ietf-suit-manifest] Section 8.7.2.2).
	Identifiers [I-D.ietf-sacm-coswid] are used (e.g., in the suit-coswid
	field of SUIT manifests), the component-id value is the CoSWID tag-id
	value.
	3. Message Overview		3. Message Overview
	The TEEP protocol consists of messages exchanged between a TAM and a		The TEEP protocol consists of messages exchanged between a TAM and a
	TEEP Agent. The messages are encoded in CBOR and designed to provide		TEEP Agent. The messages are encoded in CBOR and designed to provide
	end-to-end security. TEEP protocol messages are signed by the		end-to-end security. TEEP protocol messages are signed by the
	endpoints, i.e., the TAM and the TEEP Agent, but Trusted Applications		endpoints, i.e., the TAM and the TEEP Agent, but Trusted Applications
	may also be encrypted and signed by a TA Developer or Device		may also be encrypted and signed by a TA Developer or Device
	Administrator. The TEEP protocol not only uses CBOR but also the		Administrator. The TEEP protocol not only uses CBOR but also the
	respective security wrapper, namely COSE [RFC8152]. Furthermore, for		respective security wrapper, namely COSE [RFC8152]. Furthermore, for
	software updates the SUIT manifest format [I-D.ietf-suit-manifest] is		software updates the SUIT manifest format [I-D.ietf-suit-manifest] is
	used, and for attestation the Entity Attestation Token (EAT)		used, and for attestation the Entity Attestation Token (EAT)
	[I-D.ietf-rats-eat] format is supported although other attestation		[I-D.ietf-rats-eat] format is supported although other attestation
	formats are also permitted.		formats are also permitted.
	This specification defines six messages.		This specification defines five messages.
	A TAM queries a device's current state with a QueryRequest message.		A TAM queries a device's current state with a QueryRequest message.
	A TEEP Agent will, after authenticating and authorizing the request,		A TEEP Agent will, after authenticating and authorizing the request,
	report attestation information, list all Trusted Components, and		report attestation information, list all Trusted Components, and
	provide information about supported algorithms and extensions in a		provide information about supported algorithms and extensions in a
	QueryResponse message. An error message is returned if the request		QueryResponse message. An error message is returned if the request
	could not be processed. A TAM will process the QueryResponse message		could not be processed. A TAM will process the QueryResponse message
	and determine whether to initiate subsequent message exchanges to		and determine whether to initiate subsequent message exchanges to
	install, update, or delete Trusted Applications.		install, update, or delete Trusted Applications.
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	+------------+ +-------------+		+------------+ +-------------+
	QueryRequest ------->		QueryRequest ------->
	QueryResponse		QueryResponse
	<------- or		<------- or
	Error		Error
	With the Install message a TAM can instruct a TEEP Agent to install a		With the Update message a TAM can instruct a TEEP Agent to install
	Trusted Component. The TEEP Agent will process the message,		and/or delete one or more Trusted Components. The TEEP Agent will
	determine whether the TAM is authorized and whether the Trusted		process the message, determine whether the TAM is authorized and
	Component has been signed by an authorized TA Signer. If the Install		whether the Trusted Component has been signed by an authorized TA
	message was processed successfully then a Success message is returned		Signer. A Success message is returned when the operation has been
	to the TAM, or an Error message otherwise.		completed successfully, or an Error message otherwise.
	+------------+ +-------------+
	| TAM | |TEEP Agent |
	+------------+ +-------------+
	Install ---->
	Success
	<---- or
	Error
	With the Delete message a TAM can instruct a TEEP Agent to delete one
	or multiple Trusted Components. A Success message is returned when
	the operation has been completed successfully, or an Error message
	otherwise.
	+------------+ +-------------+		+------------+ +-------------+
	| TAM | |TEEP Agent |		| TAM | |TEEP Agent |
	+------------+ +-------------+		+------------+ +-------------+
	Delete ---->		Update ---->
	Success		Success
	<---- or		<---- or
	Error		Error
	4. Detailed Messages Specification		4. Detailed Messages Specification
	TEEP messages are protected by the COSE_Sign1 structure. The TEEP		TEEP messages are protected by the COSE_Sign1 structure. The TEEP
	protocol messages are described in CDDL format [RFC8610] below.		protocol messages are described in CDDL format [RFC8610] below.
	{		{
	teep-message => (query-request /		teep-message => (query-request /
	query-response /		query-response /
	install /		update /
	delete /
	teep-success /		teep-success /
	teep-error ),		teep-error ),
	}		}
	4.1. Creating and Validating TEEP Messages		4.1. Creating and Validating TEEP Messages
	4.1.1. Creating a TEEP message		4.1.1. Creating a TEEP message
	To create a TEEP message, the following steps are performed.		To create a TEEP message, the following steps are performed.
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 27 ¶
	3. Create a COSE_Sign1 object using the TEEP message as the		3. Create a COSE_Sign1 object using the TEEP message as the
	COSE_Sign1 Payload; all steps specified in [RFC8152] for creating		COSE_Sign1 Payload; all steps specified in [RFC8152] for creating
	a COSE_Sign1 object MUST be followed.		a COSE_Sign1 object MUST be followed.
	4. Prepend the COSE object with the TEEP CBOR tag to indicate that		4. Prepend the COSE object with the TEEP CBOR tag to indicate that
	the CBOR-encoded message is indeed a TEEP message.		the CBOR-encoded message is indeed a TEEP message.
	4.1.2. Validating a TEEP Message		4.1.2. Validating a TEEP Message
	When validating a TEEP message, the following steps are performed.		When TEEP message is received (see the ProcessTeepMessage conceptual
	If any of the listed steps fail, then the TEEP message MUST be		API defined in [I-D.ietf-teep-architecture] section 6.2.1), the
	rejected.		following validation steps are performed. If any of the listed steps
			fail, then the TEEP message MUST be rejected.
	1. Verify that the received message is a valid CBOR object.		1. Verify that the received message is a valid CBOR object.
	2. Remove the TEEP message CBOR tag and verify that one of the COSE		2. Remove the TEEP message CBOR tag and verify that one of the COSE
	CBOR tags follows it.		CBOR tags follows it.
	3. Verify that the message contains a COSE_Sign1 structure.		3. Verify that the message contains a COSE_Sign1 structure.
	4. Verify that the resulting COSE Header includes only parameters		4. Verify that the resulting COSE Header includes only parameters
	and values whose syntax and semantics are both understood and		and values whose syntax and semantics are both understood and
	skipping to change at page 7, line 39 ¶		skipping to change at page 7, line 27 ¶
	o Querying installed Trusted Components, and		o Querying installed Trusted Components, and
	o Listing supporting SUIT commands.		o Listing supporting SUIT commands.
	Like other TEEP messages, the QueryRequest message is signed, and the		Like other TEEP messages, the QueryRequest message is signed, and the
	relevant CDDL snippet is shown below. The complete CDDL structure is		relevant CDDL snippet is shown below. The complete CDDL structure is
	shown in [CDDL].		shown in [CDDL].
	query-request = [		query-request = [
	type: TEEP-TYPE-query-request,		type: TEEP-TYPE-query-request,
	token: uint,
	options: {		options: {
			? token => bstr .size (8..64),
	? supported-cipher-suites => [ + suite ],		? supported-cipher-suites => [ + suite ],
	? challenge => bstr .size (8..64),		? challenge => bstr .size (8..64),
	? versions => [ + version ],		? versions => [ + version ],
	? ocsp-data => bstr,		? ocsp-data => bstr,
	* $$query-request-extensions		* $$query-request-extensions
	* $$teep-option-extensions		* $$teep-option-extensions
	},		},
	data-item-requested		data-item-requested: data-item-requested
	]		]
	The message has the following fields:		The message has the following fields:
	type		type
	The value of (1) corresponds to a QueryRequest message sent from		The value of (1) corresponds to a QueryRequest message sent from
	the TAM to the TEEP Agent.		the TAM to the TEEP Agent.
	token		token
	The value in the token parameter is used to match responses to		The value in the token parameter is used to match responses to
	requests. This is particularly useful when a TAM issues multiple		requests. This is particularly useful when a TAM issues multiple
	concurrent requests to a TEEP Agent.		concurrent requests to a TEEP Agent. The token is not needed when
			the attestation bit is set in the data-item-requested value. The
			size of the token is at least 8 bytes (64 bits) and maximum of 64
			bytes, which is the same as in an EAT Nonce Claim (see
			[I-D.ietf-rats-eat] Section 3.3). The first usage of a token
			generated by a TAM MUST be randomly created. Subsequent token
			values MUST be different for each request message to distinguish
			the correct response from multiple requests. The token value MUST
			NOT be used for other purposes, such as a TAM to identify the
			devices and/or a device to identify TAMs or Trusted Components.
			The TAM MUST expire the token value after receiving the first
			responce from the device and ignore any subsequent messages that
			have the same token value.
	data-item-requested		data-item-requested
	The data-item-requested parameter indicates what information the		The data-item-requested parameter indicates what information the
	TAM requests from the TEEP Agent in the form of a bitmap. Each		TAM requests from the TEEP Agent in the form of a bitmap. Each
	value in the bitmap corresponds to an IANA registered information		value in the bitmap corresponds to an IANA registered information
	element. This specification defines the following initial set of		element. This specification defines the following initial set of
	information elements:		information elements:
	attestation (1) With this value the TAM requests the TEEP Agent		attestation (1) With this value the TAM requests the TEEP Agent
	to return attestation evidence (e.g., an EAT) in the response.		to return attestation evidence (e.g., an EAT) in the response.
	skipping to change at page 8, line 39 ¶		skipping to change at page 8, line 38 ¶
	discover the capabilities of a TEEP Agent implementation.		discover the capabilities of a TEEP Agent implementation.
	suit-commands (8) With this value the TAM queries the TEEP Agent		suit-commands (8) With this value the TAM queries the TEEP Agent
	for supported commands offered by the SUIT manifest		for supported commands offered by the SUIT manifest
	implementation.		implementation.
	Further values may be added in the future via IANA registration.		Further values may be added in the future via IANA registration.
	supported-cipher-suites		supported-cipher-suites
	The supported-cipher-suites parameter lists the ciphersuite(s)		The supported-cipher-suites parameter lists the ciphersuite(s)
	supported by the TAM. Details about the ciphersuite encoding can		supported by the TAM. If this parameter is not present, it is to
	be found in Section 6.		be treated the same as if it contained both ciphersuites defined
			in this document. Details about the ciphersuite encoding can be
			found in Section 7.
	challenge		challenge
	The challenge field is an optional parameter used for ensuring the		The challenge field is an optional parameter used for ensuring the
	refreshness of the attestation evidence returned with a		refreshness of the attestation evidence returned with a
	QueryResponse message. When a challenge is provided in the		QueryResponse message. When a challenge is provided in the
	QueryRequest and an EAT is returned with the QueryResponse message		QueryRequest and an EAT is returned with the QueryResponse message
	then the challenge contained in this request MUST be copied into		then the challenge contained in this request MUST be copied into
	the nonce claim found in the EAT. If any format other than EAT is		the nonce claim found in the EAT. If any format other than EAT is
	used, it is up to that format to define the use of the challenge		used, it is up to that format to define the use of the challenge
	field.		field.
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 7 ¶
	The QueryResponse message is the successful response by the TEEP		The QueryResponse message is the successful response by the TEEP
	Agent after receiving a QueryRequest message.		Agent after receiving a QueryRequest message.
	Like other TEEP messages, the QueryResponse message is signed, and		Like other TEEP messages, the QueryResponse message is signed, and
	the relevant CDDL snippet is shown below. The complete CDDL		the relevant CDDL snippet is shown below. The complete CDDL
	structure is shown in [CDDL].		structure is shown in [CDDL].
	query-response = [		query-response = [
	type: TEEP-TYPE-query-response,		type: TEEP-TYPE-query-response,
	token: uint,
	options: {		options: {
			? token => bstr .size (8..64),
	? selected-cipher-suite => suite,		? selected-cipher-suite => suite,
	? selected-version => version,		? selected-version => version,
	? evidence-format => text,		? evidence-format => text,
	? evidence => bstr,		? evidence => bstr,
	? tc-list => [ + tc-info ],		? tc-list => [ + tc-info ],
	? requested-ta-list => [ + requested-ta-info ],		? requested-tc-list => [ + requested-tc-info ],
	? unneeded-ta-list => [ + bstr ],		? unneeded-tc-list => [ + SUIT_Component_Identifier ],
	? ext-list => [ + ext-info ],		? ext-list => [ + ext-info ],
	* $$query-response-extensions,		* $$query-response-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	tc-info = {		tc-info = {
	component-id: bstr,		component-id => SUIT_Component_Identifier,
	? tc-manifest-sequence-number: uint		? tc-manifest-sequence-number => .within uint .size 8
	}		}
	requested-ta-info = {		requested-tc-info = {
	component-id: bstr,		component-id => SUIT_Component_Identifier,
	? tc-manifest-sequence-number: uint,		? tc-manifest-sequence-number => .within uint .size 8
	? have-binary: bool		? have-binary => bool
	}		}
	The QueryResponse message has the following fields:		The QueryResponse message has the following fields:
	type		type
	The value of (2) corresponds to a QueryResponse message sent from		The value of (2) corresponds to a QueryResponse message sent from
	the TEEP Agent to the TAM.		the TEEP Agent to the TAM.
	token		token
	The value in the token parameter is used to match responses to		The value in the token parameter is used to match responses to
	requests. The value MUST correspond to the value received with		requests. The value MUST correspond to the value received with
	the QueryRequest message.		the QueryRequest message if one was present, and MUST be absent if
			no token was present in the QueryRequest.
	selected-cipher-suite		selected-cipher-suite
	The selected-cipher-suite parameter indicates the selected		The selected-cipher-suite parameter indicates the selected
	ciphersuite. Details about the ciphersuite encoding can be found		ciphersuite. Details about the ciphersuite encoding can be found
	in Section 6.		in Section 7.
	selected-version		selected-version
	The selected-version parameter indicates the TEEP protocol version		The selected-version parameter indicates the TEEP protocol version
	selected by the TEEP Agent. The absense of this parameter		selected by the TEEP Agent. The absense of this parameter
	indicates the same as if it was present with a value of 0.		indicates the same as if it was present with a value of 0.
	evidence-format		evidence-format
	The evidence-format parameter indicates the IANA Media Type of the		The evidence-format parameter indicates the IANA Media Type of the
	attestation evidence contained in the evidence parameter. It MUST		attestation evidence contained in the evidence parameter. It MUST
	be present if the evidence parameter is present and the format is		be present if the evidence parameter is present and the format is
	not an EAT.		not an EAT.
	evidence		evidence
	The evidence parameter contains the attestation evidence. This		The evidence parameter contains the attestation evidence. This
	parameter MUST be present if the QueryResponse is sent in response		parameter MUST be present if the QueryResponse is sent in response
	to a QueryRequest with the attestation bit set. If the evidence-		to a QueryRequest with the attestation bit set. If the evidence-
	format parameter is absent, the attestation evidence contained in		format parameter is absent, the attestation evidence contained in
	this parameter MUST be an Entity Attestation Token following the		this parameter MUST be an Entity Attestation Token following the
	encoding defined in [I-D.ietf-rats-eat].		encoding defined in [I-D.ietf-rats-eat]. See Section 4.3.1 for
			further discussion.
	tc-list		tc-list
	The tc-list parameter enumerates the Trusted Components installed		The tc-list parameter enumerates the Trusted Components installed
	on the device in the form of tc-info objects.		on the device in the form of tc-info objects. This parameter MUST
			be present if the QueryResponse is sent in response to a
			QueryRequest with the trusted-components bit set.
	requested-ta-list		requested-tc-list
	The requested-ta-list parameter enumerates the Trusted		The requested-tc-list parameter enumerates the Trusted Components
	Applications that are not currently installed in the TEE, but		that are not currently installed in the TEE, but which are
	which are requested to be installed, for example by an installer		requested to be installed, for example by an installer of an
	of an Untrusted Application that has a TA as a dependency.		Untrusted Application that has a TA as a dependency, or by a
	Requested TAs are expressed in the form of requested-ta-info		Trusted Application that has another Trusted Component as a
	objects.		dependency. Requested Trusted Components are expressed in the
			form of requested-tc-info objects. A TEEP Agent can get this
			information from the UnrequestTA conceptual API defined in
			[I-D.ietf-teep-architecture] section 6.2.1.
	unneeded-ta-list		unneeded-tc-list
	The unneeded-ta-list parameter enumerates the Trusted Applications		The unneeded-tc-list parameter enumerates the Trusted Components
	that are currently installed in the TEE, but which are no longer		that are currently installed in the TEE, but which are no longer
	needed by any other application. The TAM can use this information		needed by any other application. The TAM can use this information
	in determining whether a TA can be deleted. Each unneeded TA is		in determining whether a Trusted Component can be deleted. Each
	expressed in the form of a component-id byte string.		unneeded Trusted Component is identified by its SUIT Component
			Identifier. A TEEP Agent can get this information from the
			UnrequestTA conceptual API defined in [I-D.ietf-teep-architecture]
			section 6.2.1.
	ext-list		ext-list
	The ext-list parameter lists the supported extensions. This		The ext-list parameter lists the supported extensions. This
	document does not define any extensions.		document does not define any extensions.
	The tc-info object has the following fields:		The tc-info object has the following fields:
	component-id		component-id
	A unique identifier encoded as a CBOR bstr.		A SUIT Component Identifier.
	tc-manifest-sequence-number		tc-manifest-sequence-number
	The suit-manifest-sequence-number value from the SUIT manifest for		The suit-manifest-sequence-number value from the SUIT manifest for
	the Trusted Component, if a SUIT manifest was used.		the Trusted Component, if a SUIT manifest was used.
	The requested-ta-info message has the following fields:		The requested-tc-info message has the following fields:
	component-id		component-id
	A unique identifier encoded as a CBOR bstr.		A SUIT Component Identifier.
	tc-manifest-sequence-number		tc-manifest-sequence-number
	The minimum suit-manifest-sequence-number value from a SUIT		The minimum suit-manifest-sequence-number value from a SUIT
	manifest for the TA. If not present, indicates that any version		manifest for the Trusted Component. If not present, indicates
	will do.		that any version will do.
	have-binary		have-binary
	If present with a value of true, indicates that the TEEP agent		If present with a value of true, indicates that the TEEP agent
	already has the TA binary and only needs an Install message with a		already has the Trusted Component binary and only needs an Update
	SUIT manifest that authorizes installing it. If have-binary is		message with a SUIT manifest that authorizes installing it. If
	true, the tc-manifest-sequence-number field MUST be present.		have-binary is true, the tc-manifest-sequence-number field MUST be
			present.
	4.4. Install Message		4.3.1. Evidence
	The Install message is used by the TAM to install a Trusted Component		Section 7.1 of [I-D.ietf-teep-architecture] lists information that
	via the TEEP Agent.		may be required in the evidence depend on the circumstance. When an
			Entity Attestation Token is used, the following claims can be used to
			meet those requirements:
	Like other TEEP messages, the Install message is signed, and the		+------------+---------------------+--------------------------------+
			| Requiremen | Claim | Reference |
			| t | | |
			+------------+---------------------+--------------------------------+
			| Device | device-identifier | [I-D.birkholz-rats-suit-claims |
			| unique | | ] section 3.1.3 |
			| identifier | | |
			| Vendor of | vendor-identifier | [I-D.birkholz-rats-suit-claims |
			| the device | | ] section 3.1.1 |
			| Class of | class-identifier | [I-D.birkholz-rats-suit-claims |
			| the device | | ] section 3.1.2 |
			| TEE | chip-version-scheme | [I-D.ietf-rats-eat] section |
			| hardware | | 3.7 |
			| type | | |
			| TEE | chip-version-scheme | [I-D.ietf-rats-eat] section |
			| hardware | | 3.7 |
			| version | | |
			| TEE | component- | [I-D.birkholz-rats-suit-claims |
			| firmware | identifier | ] section 3.1.4 |
			| type | | |
			| TEE | version | [I-D.birkholz-rats-suit-claims |
			| firmware | | ] section 3.1.8 |
			| version | | |
			| Freshness | nonce | [I-D.ietf-rats-eat] section |
			| proof | | 3.3 |
			+------------+---------------------+--------------------------------+
			4.4. Update Message
			The Update message is used by the TAM to install and/or delete one or
			more Trusted Components via the TEEP Agent.
			Like other TEEP messages, the Update message is signed, and the
	relevant CDDL snippet is shown below. The complete CDDL structure is		relevant CDDL snippet is shown below. The complete CDDL structure is
	shown in [CDDL].		shown in [CDDL].
	install = [		update = [
	type: TEEP-TYPE-install,		type: TEEP-TYPE-update,
	token: uint,		options: {
	option: {		? token => bstr .size (8..64),
	? manifest-list => [ + SUIT_Envelope ],		? manifest-list => [ + bstr .cbor SUIT_Envelope ],
	* $$install-extensions,		* $$update-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	The Install message has the following fields:		The Update message has the following fields:
	type		type
	The value of (3) corresponds to an Install message sent from the		The value of (3) corresponds to an Update message sent from the
	TAM to the TEEP Agent. In case of successful processing, a		TAM to the TEEP Agent. In case of successful processing, a
	Success message is returned by the TEEP Agent. In case of an		Success message is returned by the TEEP Agent. In case of an
	error, an Error message is returned. Note that the Install		error, an Error message is returned. Note that the Update message
	message is used for initial Trusted Component installation as well		is used for initial Trusted Component installation as well as for
	as for updates.		updates and deletes.
	token		token
	The value in the token field is used to match responses to		The value in the token field is used to match responses to
	requests.		requests.
	manifest-list		manifest-list
	The manifest-list field is used to convey one or multiple SUIT		The manifest-list field is used to convey one or multiple SUIT
	manifests. A manifest is a bundle of metadata about a TA, such as		manifests to install. A manifest is a bundle of metadata about a
	where to find the code, the devices to which it applies, and		TA, such as where to find the code, the devices to which it
	cryptographic information protecting the manifest. The manifest		applies, and cryptographic information protecting the manifest.
	may also convey personalization data. TA binaries and		The manifest may also convey personalization data. TA binaries
	personalization data can be signed and encrypted by the same TA		and personalization data can be signed and encrypted by the same
	Signer. Other combinations are, however, possible as well. For		TA Signer. Other combinations are, however, possible as well.
	example, it is also possible for the TAM to sign and encrypt the		For example, it is also possible for the TAM to sign and encrypt
	personalization data and to let the TA Developer sign and/or		the personalization data and to let the TA Developer sign and/or
	encrypt the TA binary.		encrypt the TA binary.
	4.5. Delete Message		Note that an Update message carrying one or more SUIT manifests will
			inherently involve multiple signatures, one by the TAM in the TEEP
	The Delete message is used by the TAM to remove a Trusted Component		message and one from a Trusted Component signer inside each manifest.
	from the device.		This is intentional as they are for different purposes.
	Like other TEEP messages, the Delete message is signed, and the
	relevant CDDL snippet is shown below. The complete CDDL structure is
	shown in [CDDL].
	delete = [
	type: TEEP-TYPE-delete,
	token: uint,
	option: {
	? tc-list => [ + bstr ],
	* $$delete-extensions,
	* $$teep-option-extensions
	}
	]
	The Delete message has the following fields:
	type
	The value of (4) corresponds to a Delete message sent from the TAM
	to the TEEP Agent. In case of successful processing, a Success
	message is returned by the TEEP Agent. In case of an error, an
	Error message is returned.
	token		The TAM is what authorizes apps to be installed, updated, and deleted
	The value in the token parameter is used to match responses to		on a given TEE and so the TEEP signature is checked by the TEEP Agent
	requests.		at protocol message processing time. (This same TEEP security
			wrapper is also used on messages like QueryRequest so that Agents
			only send potentially sensitive data such as evidence to trusted
			TAMs.)
	tc-list		The Trusted Component signer on the other hand is what authorizes the
	The tc-list parameter enumerates the Trusted Components to be		Trusted Component to actually run, so the manifest signature could be
	deleted, in the form of component-id byte strings.		checked at install time or load (or run) time or both, and this
			checking is done by the TEE independent of whether TEEP is used or
			some other update mechanism. See section 5 of
			[I-D.ietf-teep-architecture] for further discussion.
	4.6. Success Message		4.5. Success Message
	The TEEP protocol defines two implicit success messages and this		The Success message is used by the TEEP Agent to return a success in
	explicit Success message for the cases where the TEEP Agent cannot		response to an Update message.
	return another reply, such as for the Install and the Delete
	messages.
	Like other TEEP messages, the Success message is signed, and the		Like other TEEP messages, the Success message is signed, and the
	relevant CDDL snippet is shown below. The complete CDDL structure is		relevant CDDL snippet is shown below. The complete CDDL structure is
	shown in [CDDL].		shown in [CDDL].
	teep-success = [		teep-success = [
	type: TEEP-TYPE-teep-success,		type: TEEP-TYPE-teep-success,
	token: uint,		options: {
	option: {		? token => bstr .size (8..64),
	? msg => text,		? msg => text .size (1..128),
	? suit-reports => [ + suit-report ],		? suit-reports => [ + suit-report ],
	* $$teep-success-extensions,		* $$teep-success-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	The Success message has the following fields:		The Success message has the following fields:
	type		type
	The value of (5) corresponds to corresponds to a Success message		The value of (5) corresponds to corresponds to a Success message
	sent from the TEEP Agent to the TAM.		sent from the TEEP Agent to the TAM.
	token		token
	The value in the token parameter is used to match responses to		The value in the token parameter is used to match responses to
	requests.		requests. It MUST match the value of the token parameter in the
			Update message the Success is in response to, if one was present.
			If none was present, the token MUST be absent in the Success
			message.
	msg		msg
	The msg parameter contains optional diagnostics information		The msg parameter contains optional diagnostics information
	encoded in UTF-8 [RFC3629] returned by the TEEP Agent.		encoded in UTF-8 [RFC3629] using Net-Unicode form [RFC5198] with
			max 128 bytes returned by the TEEP Agent.
	suit-reports		suit-reports
	If present, the suit-reports parameter contains a set of SUIT		If present, the suit-reports parameter contains a set of SUIT
	Reports as defined in Section 4 of [I-D.moran-suit-report].		Reports as defined in Section 4 of [I-D.moran-suit-report]. If
			the suit-report-nonce field is present in the SUIT Report, is
			value MUST match the value of the token parameter in the Update
			message the Success message is in response to.
	4.7. Error Message		4.6. Error Message
	The Error message is used by the TEEP Agent to return an error.		The Error message is used by the TEEP Agent to return an error in
			response to an Update message.
	Like other TEEP messages, the Error message is signed, and the		Like other TEEP messages, the Error message is signed, and the
	relevant CDDL snippet is shown below. The complete CDDL structure is		relevant CDDL snippet is shown below. The complete CDDL structure is
	shown in [CDDL].		shown in [CDDL].
	teep-error = [		teep-error = [
	type: TEEP-TYPE-teep-error,		type: TEEP-TYPE-teep-error,
	token: uint,
	err-code: uint,
	options: {		options: {
	? err-msg => text,		? token => bstr .size (8..64),
			? err-msg => text .size (1..128),
	? supported-cipher-suites => [ + suite ],		? supported-cipher-suites => [ + suite ],
	? versions => [ + version ],		? versions => [ + version ],
	? suit-reports => [ + suit-report ],		? suit-reports => [ + suit-report ],
	* $$teep-error--extensions,		* $$teep-error-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		},
			err-code: uint (0..23)
	]		]
	The Error message has the following fields:		The Error message has the following fields:
	type		type
	The value of (6) corresponds to an Error message sent from the		The value of (6) corresponds to an Error message sent from the
	TEEP Agent to the TAM.		TEEP Agent to the TAM.
	token		token
	The value in the token parameter is used to match responses to		The value in the token parameter is used to match responses to
	requests.		requests. It MUST match the value of the token parameter in the
			Update message the Success is in response to, if one was present.
	err-code		If none was present, the token MUST be absent in the Error
	The err-code parameter contains one of the values listed in the
	registry defined in Section 8.2 (with the initial set of error
	codes listed below). Only selected values are applicable to each
	message.		message.
	err-msg		err-msg
	The err-msg parameter is human-readable diagnostic text that MUST		The err-msg parameter is human-readable diagnostic text that MUST
	be encoded using UTF-8 [RFC3629] using Net-Unicode form [RFC5198].		be encoded using UTF-8 [RFC3629] using Net-Unicode form [RFC5198]
			with max 128 bytes.
	supported-cipher-suites		supported-cipher-suites
	The supported-cipher-suites parameter lists the ciphersuite(s)		The supported-cipher-suites parameter lists the ciphersuite(s)
	supported by the TEEP Agent. Details about the ciphersuite		supported by the TEEP Agent. Details about the ciphersuite
	encoding can be found in Section 6. This field is optional but		encoding can be found in Section 7. This field is optional but
	MUST be returned with the ERR_UNSUPPORTED_CRYPTO_ALG error		MUST be returned with the ERR_UNSUPPORTED_CRYPTO_ALG error
	message.		message.
	versions		versions
	The versions parameter enumerates the TEEP protocol version(s)		The versions parameter enumerates the TEEP protocol version(s)
	supported by the TEEP Agent. This otherwise optional parameter		supported by the TEEP Agent. This otherwise optional parameter
	MUST be returned with the ERR_UNSUPPORTED_MSG_VERSION error		MUST be returned with the ERR_UNSUPPORTED_MSG_VERSION error
	message.		message.
	suit-reports		suit-reports
	If present, the suit-reports parameter contains a set of SUIT		If present, the suit-reports parameter contains a set of SUIT
	Reports as defined in Section 4 of [I-D.moran-suit-report].		Reports as defined in Section 4 of [I-D.moran-suit-report]. If
			the suit-report-nonce field is present in the SUIT Report, is
			value MUST match the value of the token parameter in the Update
			message the Error message is in response to.
			err-code
			The err-code parameter contains one of the error codes listed
			below). Only selected values are applicable to each message.
	This specification defines the following initial error messages:		This specification defines the following initial error messages:
	ERR_ILLEGAL_PARAMETER (1)		ERR_PERMANENT_ERROR (1)
	The TEEP request contained incorrect fields or fields that are		The TEEP request contained incorrect fields or fields that are
	inconsistent with other fields.		inconsistent with other fields. For diagnosis purposes it is
			RECOMMMENDED to identify the failure reason in the error message.
			A TAM receiving this error might refuse to communicate further
			with the TEEP Agent for some period of time until it has reason to
			believe it is worth trying again, but it should take care not to
			give up on communication when there is no attestation evidence
			indicating that the error is genuine. In contrast,
			ERR_TEMPORARY_ERROR is an indication that a more agressive retry
			is warranted.
	ERR_UNSUPPORTED_EXTENSION (2)		ERR_UNSUPPORTED_EXTENSION (2)
	The TEEP Agent does not support the request message or an		The TEEP Agent does not support an extension included in the
	extension it indicated.		request message. For diagnosis purposes it is RECOMMMENDED to
			identify the unsupported extension in the error message. A TAM
	ERR_REQUEST_SIGNATURE_FAILED (3)		receiving this error might retry the request without using
	The TEEP Agent could not verify the signature of the request		extensions.
	message.
	ERR_UNSUPPORTED_MSG_VERSION (4)		ERR_UNSUPPORTED_MSG_VERSION (4)
	The TEEP Agent does not support the TEEP protocol version		The TEEP Agent does not support the TEEP protocol version
	indicated in the request message.		indicated in the request message. A TAM receiving this error
			might retry the request using a different TEEP protocol version.
	ERR_UNSUPPORTED_CRYPTO_ALG (5)		ERR_UNSUPPORTED_CRYPTO_ALG (5)
	The TEEP Agent does not support the cryptographic algorithm		The TEEP Agent does not support the cryptographic algorithm
	indicated in the request message.		indicated in the request message. A TAM receiving this error
			might retry the request using a different cryptographic algorithm.
	ERR_BAD_CERTIFICATE (6)		ERR_BAD_CERTIFICATE (6)
	Processing of a certificate failed. For diagnosis purposes it is		Processing of a certificate failed. For diagnosis purposes it is
	RECOMMMENDED to include information about the failing certificate		RECOMMMENDED to include information about the failing certificate
	in the error message.		in the error message. For example, the certificate was of an
			unsupported type, or the certificate was revoked by its signer. A
	ERR_UNSUPPORTED_CERTIFICATE (7)		TAM receiving this error might attempt to use an alternate
	A certificate was of an unsupported type.		certificate.
	ERR_CERTIFICATE_REVOKED (8)
	A certificate was revoked by its signer.
	ERR_CERTIFICATE_EXPIRED (9)		ERR_CERTIFICATE_EXPIRED (9)
	A certificate has expired or is not currently valid.		A certificate has expired or is not currently valid. A TAM
			receiving this error might attempt to renew its certificate before
	ERR_INTERNAL_ERROR (10)		using it again.
	A miscellaneous internal error occurred while processing the
	request message.
	ERR_TC_NOT_FOUND (12)		ERR_TEMPORARY_ERROR (10)
	The target Trusted Component does not exist. This error may		A miscellaneous temporary error, such as a memory allocation
	happen when the TAM has stale information and tries to delete a		failure, occurred while processing the request message. A TAM
	Trusted Component that has already been deleted.		receiving this error might retry the same request at a later point
			in time.
	ERR_MANIFEST_PROCESSING_FAILED (17)		ERR_MANIFEST_PROCESSING_FAILED (17)
	The TEEP Agent encountered one or more manifest processing		The TEEP Agent encountered one or more manifest processing
	failures. If the suit-reports parameter is present, it contains		failures. If the suit-reports parameter is present, it contains
	the failure details.		the failure details. A TAM receiving this error might still
			attempt to install or update other components that do not depend
			on the failed manifest.
	Additional error codes can be registered with IANA.		New error codes should be added sparingly, not for every
			implementation error. That is the intent of the err-msg field, which
			can be used to provide details meaningful to humans. New error codes
			should only be added if the TAM is expected to do something
			behaviorally different upon receipt of the error message, rather than
			just logging the event. Hence, each error code is responsible for
			saying what the behavioral difference is expected to be.
	5. Mapping of TEEP Message Parameters to CBOR Labels		5. Mapping of TEEP Message Parameters to CBOR Labels
	In COSE, arrays and maps use strings, negative integers, and unsigned		In COSE, arrays and maps use strings, negative integers, and unsigned
	integers as their keys. Integers are used for compactness of		integers as their keys. Integers are used for compactness of
	encoding. Since the word "key" is mainly used in its other meaning,		encoding. Since the word "key" is mainly used in its other meaning,
	as a cryptographic key, this specification uses the term "label" for		as a cryptographic key, this specification uses the term "label" for
	this usage as a map key.		this usage as a map key.
	This specification uses the following mapping:		This specification uses the following mapping:
	skipping to change at page 17, line 44 ¶		skipping to change at page 19, line 27 ¶
	| manifest-list | 10 |		| manifest-list | 10 |
	| msg | 11 |		| msg | 11 |
	| err-msg | 12 |		| err-msg | 12 |
	| evidence-format | 13 |		| evidence-format | 13 |
	| requested-tc-list | 14 |		| requested-tc-list | 14 |
	| unneeded-tc-list | 15 |		| unneeded-tc-list | 15 |
	| component-id | 16 |		| component-id | 16 |
	| tc-manifest-sequence-number | 17 |		| tc-manifest-sequence-number | 17 |
	| have-binary | 18 |		| have-binary | 18 |
	| suit-reports | 19 |		| suit-reports | 19 |
			| token | 20 |
	+-----------------------------+-------+		+-----------------------------+-------+
	6. Ciphersuites		6. Behavior Specification
			Behavior is specified in terms of the conceptual APIs defined in
			section 6.2.1 of [I-D.ietf-teep-architecture].
			6.1. TAM Behavior
			When the ProcessConnect API is invoked, the TAM sends a QueryRequest
			message.
			When the ProcessTeepMessage API is invoked, the TAM first does
			validation as specified in Section 4.1.2, and drops the message if it
			is not valid. Otherwise, it proceeds as follows.
			If a QueryResponse message is received that contains evidence, the
			evidence is passed to an attestation Verifier (see
			[I-D.ietf-rats-architecture]) to determine whether the Agent is in a
			trustworthy state. Based on the results of attestation, and the
			lists of installed, requested, and unneeded Trusted Components
			reported in the QueryResponse, the TAM determines, in any
			implementation specific manner, which Trusted Components need to be
			installed, updated, or deleted, if any. If any Trusted Components
			need to be installed, updated, or deleted, the TAM sends an Update
			message containing SUIT Manifests with command sequences to do the
			relevant installs, updates, or deletes.
			If a Success or Error message is received, the TAM also validates
			that the nonce in any SUIT Report matches the token sent in the
			Update message, and drops the message if it does not match.
			Otherwise, the TAM handles the update in any implementation specific
			way, such as updating any locally cached information about the state
			of the TEEP Agent, or logging the results.
			If an Error message is received, the TAM can handle it in any
			implementation specific way, but Section 4.6 provides recommendations
			for such handling.
			6.2. TEEP Agent Behavior
			When the RequestTA API is invoked, the TEEP Agent first checks
			whether the requested TA is already installed. If it is already
			installed, the TEEP Agent passes no data back to the caller.
			Otherwise, if the TEEP Agent chooses to initiate the process of
			requesting the indicated TA, it determines (in any implementation
			specific way) the TAM URI based on any TAM URI provided by the
			RequestTA caller and any local configuration, and passes back the TAM
			URI to connect to.
			When the RequestPolicyCheck API is invoked, the TEEP Agent decides
			whether to initiate communication with any trusted TAMs (e.g., it
			might choose to do so for a given TAM unless it detects that it has
			already communicated with that TAM recently). If so, it passes back
			a TAM URI to connect to. If the TEEP Agent has multiple TAMs it
			needs to connect with, it just passes back one, with the expectation
			that RequestPolicyCheck API will be invoked to retrieve each one
			successively until there are no more and it can pass back no data at
			that time. Thus, once a TAM URI is returned, the TEEP Agent can
			remember that it has already initiated communication with that TAM.
			When the ProcessError API is invoked, the TEEP Agent can handle it in
			any implementation specific way, such as logging the error or using
			the information in future choices of TAM URI.
			When the ProcessTeepMessage API is invoked, the Agent first does
			validation as specified in Section 4.1.2, and drops the message if it
			is not valid. Otherwise, processing continues as follows based on
			the type of message.
			When a QueryRequest message is received, the Agent responds with a
			QueryResponse message.
			When an Update message is received, the Agent attempts to update the
			Trusted Components specified in the SUIT manifests by following the
			Update Procedure specified in [I-D.ietf-suit-manifest], and responds
			with a Success message if all SUIT manifests were successfully
			installed, or an Error message if any error was encountered.
			7. Ciphersuites
	A ciphersuite consists of an AEAD algorithm, an HMAC algorithm, and a		A ciphersuite consists of an AEAD algorithm, an HMAC algorithm, and a
	signature algorithm. Each ciphersuite is identified with an integer		signature algorithm. Each ciphersuite is identified with an integer
	value, which corresponds to an IANA registered ciphersuite (see		value, which corresponds to an IANA registered ciphersuite (see
	Section 8.3. This document specifies two ciphersuites.		Section 9.2. This document specifies two ciphersuites.
	+-------+------------------------------------------------+		+-------+------------------------------------------------+
	| Value | Ciphersuite |		| Value | Ciphersuite |
	+-------+------------------------------------------------+		+-------+------------------------------------------------+
	| 1 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA |		| 1 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA |
	| 2 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 |		| 2 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 |
	+-------+------------------------------------------------+		+-------+------------------------------------------------+
	7. Security Considerations		A TAM MUST support both ciphersuites. A TEEP Agent MUST support at
			least one of the two but can choose which one. For example, a TEEP
			Agent might choose ciphersuite 2 if it has hardware support for it.
			8. Security Considerations
	This section summarizes the security considerations discussed in this		This section summarizes the security considerations discussed in this
	specification:		specification:
	Cryptographic Algorithms		Cryptographic Algorithms
	TEEP protocol messages exchanged between the TAM and the TEEP		TEEP protocol messages exchanged between the TAM and the TEEP
	Agent are protected using COSE. This specification relies on the		Agent are protected using COSE. This specification relies on the
	cryptographic algorithms provided by COSE. Public key based		cryptographic algorithms provided by COSE. Public key based
	authentication is used by the TEEP Agent to authenticate the TAM		authentication is used by the TEEP Agent to authenticate the TAM
	and vice versa.		and vice versa.
	skipping to change at page 20, line 11 ¶		skipping to change at page 23, line 26 ¶
	revoked certificate. OCSP stapling data includes signature		revoked certificate. OCSP stapling data includes signature
	generation time, allowing certificate validity dates to be		generation time, allowing certificate validity dates to be
	compared to the current time.		compared to the current time.
	Compromised Time Source		Compromised Time Source
	As discussed above, certificate validity checks rely on comparing		As discussed above, certificate validity checks rely on comparing
	validity dates to the current time, which relies on having a		validity dates to the current time, which relies on having a
	trusted source of time, such as [RFC8915]. A compromised time		trusted source of time, such as [RFC8915]. A compromised time
	source could thus be used to subvert such validity checks.		source could thus be used to subvert such validity checks.
	8. IANA Considerations		9. IANA Considerations
	8.1. Media Type Registration		9.1. Media Type Registration
	IANA is requested to assign a media type for application/teep+cbor.		IANA is requested to assign a media type for application/teep+cbor.
	Type name: application		Type name: application
	Subtype name: teep+cbor		Subtype name: teep+cbor
	Required parameters: none		Required parameters: none
	Optional parameters: none		Optional parameters: none
	skipping to change at page 21, line 4 ¶		skipping to change at page 24, line 19 ¶
	Magic number(s): N/A		Magic number(s): N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
	Person to contact for further information: teep@ietf.org		Person to contact for further information: teep@ietf.org
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author: See the "Authors' Addresses" section of this document		Author: See the "Authors' Addresses" section of this document
	Change controller: IETF		Change controller: IETF
	8.2. Error Code Registry		9.2. Ciphersuite Registry
	IANA is also requested to create a new registry for the error codes
	defined in Section 4.
	Registration requests are evaluated after a three-week review period
	on the teep-reg-review@ietf.org mailing list, on the advice of one or
	more Designated Experts [RFC8126]. However, to allow for the
	allocation of values prior to publication, the Designated Experts may
	approve registration once they are satisfied that such a
	specification will be published.
	Registration requests sent to the mailing list for review should use
	an appropriate subject (e.g., "Request to register an error code:
	example"). Registration requests that are undetermined for a period
	longer than 21 days can be brought to the IESG's attention (using the
	iesg@ietf.org mailing list) for resolution.
	Criteria that should be applied by the Designated Experts includes
	determining whether the proposed registration duplicates existing
	functionality, whether it is likely to be of general applicability or
	whether it is useful only for a single extension, and whether the
	registration description is clear.
	IANA must only accept registry updates from the Designated Experts
	and should direct all requests for registration to the review mailing
	list.
	8.3. Ciphersuite Registry
	IANA is also requested to create a new registry for ciphersuites, as		IANA is also requested to create a new registry for ciphersuites, as
	defined in Section 6.		defined in Section 7.
	8.4. CBOR Tag Registry		9.3. CBOR Tag Registry
	IANA is requested to register a CBOR tag in the "CBOR Tags" registry		IANA is requested to register a CBOR tag in the "CBOR Tags" registry
	for use with TEEP messages.		for use with TEEP messages.
	The registry contents is:		The registry contents is:
	o CBOR Tag: TBD1		o CBOR Tag: TBD1
	o Data Item: TEEP Message		o Data Item: TEEP Message
	o Semantics: TEEP Message, as defined in [[TBD: This RFC]]		o Semantics: TEEP Message, as defined in [[TBD: This RFC]]
	o Reference: [[TBD: This RFC]]		o Reference: [[TBD: This RFC]]
	o Point of Contact: TEEP working group (teep@ietf.org)		o Point of Contact: TEEP working group (teep@ietf.org)
	9. References		10. References
	9.1. Normative References		10.1. Normative References
			[I-D.ietf-rats-architecture]
			Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
			W. Pan, "Remote Attestation Procedures Architecture",
			draft-ietf-rats-architecture-08 (work in progress),
			December 2020.
	[I-D.ietf-rats-eat]		[I-D.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Ballesteros, M., and J.		Mandyam, G., Lundblade, L., Ballesteros, M., and J.
	O'Donoghue, "The Entity Attestation Token (EAT)", draft-		O'Donoghue, "The Entity Attestation Token (EAT)", draft-
	ietf-rats-eat-04 (work in progress), August 2020.		ietf-rats-eat-06 (work in progress), December 2020.
	[I-D.ietf-suit-manifest]		[I-D.ietf-suit-manifest]
	Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,		Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
	"A Concise Binary Object Representation (CBOR)-based		"A Concise Binary Object Representation (CBOR)-based
	Serialization Format for the Software Updates for Internet		Serialization Format for the Software Updates for Internet
	of Things (SUIT) Manifest", draft-ietf-suit-manifest-09		of Things (SUIT) Manifest", draft-ietf-suit-manifest-11
	(work in progress), July 2020.		(work in progress), December 2020.
	[I-D.moran-suit-report]		[I-D.moran-suit-report]
	Moran, B., "Secure Reporting of Update Status", draft-		Moran, B., "Secure Reporting of Update Status", draft-
	moran-suit-report-00 (work in progress), October 2020.		moran-suit-report-00 (work in progress), October 2020.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	skipping to change at page 23, line 17 ¶		skipping to change at page 26, line 13 ¶
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[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>.
	[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>.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-sacm-coswid]		[I-D.birkholz-rats-suit-claims]
	Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.		Birkholz, H. and B. Moran, "Trustworthiness Vectors for
	Waltermire, "Concise Software Identification Tags", draft-		the Software Updates of Internet of Things (SUIT) Workflow
	ietf-sacm-coswid-15 (work in progress), May 2020.		Model", draft-birkholz-rats-suit-claims-01 (work in
			progress), January 2021.
	[I-D.ietf-teep-architecture]		[I-D.ietf-teep-architecture]
	Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,		Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
	"Trusted Execution Environment Provisioning (TEEP)		"Trusted Execution Environment Provisioning (TEEP)
	Architecture", draft-ietf-teep-architecture-12 (work in		Architecture", draft-ietf-teep-architecture-13 (work in
	progress), July 2020.		progress), November 2020.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005, <https://www.rfc-
	editor.org/info/rfc4122>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	skipping to change at page 24, line 27 ¶		skipping to change at page 27, line 20 ¶
	We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki		We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki
	(TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for		(TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for
	their valuable implementation feedback.		their valuable implementation feedback.
	We would also like to thank Carsten Bormann and Henk Birkholz for		We would also like to thank Carsten Bormann and Henk Birkholz for
	their help with the CDDL.		their help with the CDDL.
	C. Complete CDDL		C. Complete CDDL
	Valid TEEP messages MUST adhere to the following CDDL data		Valid TEEP messages MUST adhere to the following CDDL data
	definitions, except that "SUIT_Envelope" is specified in		definitions, except that "SUIT_Envelope" and
			"SUIT_Component_Identifier" are specified in
	[I-D.ietf-suit-manifest].		[I-D.ietf-suit-manifest].
	teep-message = $teep-message-type .within teep-message-framework		teep-message = $teep-message-type .within teep-message-framework
	SUIT_Envelope = any		SUIT_Envelope = any
	teep-message-framework = [		teep-message-framework = [
	type: 0..23 / $teep-type-extension,		type: uint (0..23) / $teep-type-extension,
	token: uint,
	options: { * teep-option },		options: { * teep-option },
	* int; further integers, e.g. for data-item-requested		* uint; further integers, e.g., for data-item-requested
	]		]
	teep-option = (uint => any)		teep-option = (uint => any)
	; messages defined below:		; messages defined below:
	$teep-message-type /= query-request		$teep-message-type /= query-request
	$teep-message-type /= query-response		$teep-message-type /= query-response
	$teep-message-type /= install		$teep-message-type /= update
	$teep-message-type /= delete
	$teep-message-type /= teep-success		$teep-message-type /= teep-success
	$teep-message-type /= teep-error		$teep-message-type /= teep-error
	; message type numbers		; message type numbers, uint (0..23)
	TEEP-TYPE-query-request = 1		TEEP-TYPE-query-request = 1
	TEEP-TYPE-query-response = 2		TEEP-TYPE-query-response = 2
	TEEP-TYPE-install = 3		TEEP-TYPE-update = 3
	TEEP-TYPE-delete = 4
	TEEP-TYPE-teep-success = 5		TEEP-TYPE-teep-success = 5
	TEEP-TYPE-teep-error = 6		TEEP-TYPE-teep-error = 6
	version = uint .size 4		version = .within uint .size 4
	ext-info = uint		ext-info = .within uint .size 4
	; data items as bitmaps		; data items as bitmaps
	data-item-requested = $data-item-requested .within uint .size 8		data-item-requested = $data-item-requested .within uint .size 8
	attestation = 1		attestation = 1
	$data-item-requested /= attestation		$data-item-requested /= attestation
	trusted-components = 2		trusted-components = 2
	$data-item-requested /= trusted-components		$data-item-requested /= trusted-components
	extensions = 4		extensions = 4
	$data-item-requested /= extensions		$data-item-requested /= extensions
	suit-commands = 8		suit-commands = 8
	$data-item-requested /= suit-commands		$data-item-requested /= suit-commands
	query-request = [		query-request = [
	type: TEEP-TYPE-query-request,		type: TEEP-TYPE-query-request,
	token: uint,
	options: {		options: {
			? token => bstr .size (8..64),
	? supported-cipher-suites => [ + suite ],		? supported-cipher-suites => [ + suite ],
	? challenge => bstr .size (8..64),		? challenge => bstr .size (8..64),
	? versions => [ + version ],		? versions => [ + version ],
	? ocsp-data => bstr,		? ocsp-data => bstr,
	* $$query-request-extensions		* $$query-request-extensions
	* $$teep-option-extensions		* $$teep-option-extensions
	},		},
	data-item-requested		data-item-requested: data-item-requested
	]		]
	; ciphersuites as bitmaps		; ciphersuites
	suite = $TEEP-suite .within uint .size 8		suite = $TEEP-suite .within uint .size 4
	TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1		TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1
	TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2		TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2
	$TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA		$TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA
	$TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256		$TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256
	query-response = [		query-response = [
	type: TEEP-TYPE-query-response,		type: TEEP-TYPE-query-response,
	token: uint,
	options: {		options: {
			? token => bstr .size (8..64),
	? selected-cipher-suite => suite,		? selected-cipher-suite => suite,
	? selected-version => version,		? selected-version => version,
	? evidence-format => text,		? evidence-format => text,
	? evidence => bstr,		? evidence => bstr,
	? tc-list => [ + tc-info ],		? tc-list => [ + tc-info ],
	? requested-tc-list => [ + requested-tc-info ],		? requested-tc-list => [ + requested-tc-info ],
	? unneeded-tc-list => [ + bstr ],		? unneeded-tc-list => [ + SUIT_Component_Identifier ],
	? ext-list => [ + ext-info ],		? ext-list => [ + ext-info ],
	* $$query-response-extensions,		* $$query-response-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	tc-info = {		tc-info = {
	component-id: bstr,		component-id => SUIT_Component_Identifier,
	? tc-manifest-sequence-number: uint		? tc-manifest-sequence-number => .within uint .size 8
	}		}
	requested-ta-info = {		requested-tc-info = {
	component-id: bstr,		component-id => SUIT_Component_Identifier,
	? tc-manifest-sequence-number: uint,		? tc-manifest-sequence-number => .within uint .size 8
	? have-binary: bool		? have-binary => bool
	}		}
	install = [		update = [
	type: TEEP-TYPE-install,		type: TEEP-TYPE-update,
	token: uint,		options: {
	option: {		? token => bstr .size (8..64),
	? manifest-list => [ + SUIT_Envelope ],		? unneeded-tc-list => [ + SUIT_Component_Identifier ],
	* $$install-extensions,		? manifest-list => [ + bstr .cbor SUIT_Envelope ],
	* $$teep-option-extensions		* $$update-extensions,
	}
	]
	delete = [
	type: TEEP-TYPE-delete,
	token: uint,
	option: {
	? tc-list => [ + bstr ],
	* $$delete-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	teep-success = [		teep-success = [
	type: TEEP-TYPE-teep-success,		type: TEEP-TYPE-teep-success,
	token: uint,		options: {
	option: {		? token => bstr .size (8..64),
	? msg => text,		? msg => text .size (1..128),
	? suit-reports => [ + suit-report ],		? suit-reports => [ + suit-report ],
	* $$teep-success-extensions,		* $$teep-success-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	teep-error = [		teep-error = [
	type: TEEP-TYPE-teep-error,		type: TEEP-TYPE-teep-error,
	token: uint,
	err-code: uint,
	options: {		options: {
	? err-msg => text,		? token => bstr .size (8..64),
			? err-msg => text .size (1..128),
	? supported-cipher-suites => [ + suite ],		? supported-cipher-suites => [ + suite ],
	? versions => [ + version ],		? versions => [ + version ],
	? suit-reports => [ + suit-report ],		? suit-reports => [ + suit-report ],
	* $$teep-error--extensions,		* $$teep-error-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		},
			err-code: uint (0..23)
	]		]
			; The err-code parameter, uint (0..23)
			ERR_PERMANENT_ERROR = 1
			ERR_UNSUPPORTED_EXTENSION = 2
			ERR_UNSUPPORTED_MSG_VERSION = 4
			ERR_UNSUPPORTED_CRYPTO_ALG = 5
			ERR_BAD_CERTIFICATE = 6
			ERR_CERTIFICATE_EXPIRED = 9
			ERR_TEMPORARY_ERROR = 10
			ERR_MANIFEST_PROCESSING_FAILED = 17
			; labels of mapkey for teep message parameters, uint (0..23)
	supported-cipher-suites = 1		supported-cipher-suites = 1
	challenge = 2		challenge = 2
	versions = 3		versions = 3
	ocsp-data = 4		ocsp-data = 4
	selected-cipher-suite = 5		selected-cipher-suite = 5
	selected-version = 6		selected-version = 6
	evidence = 7		evidence = 7
	tc-list = 8		tc-list = 8
	ext-list = 9		ext-list = 9
	manifest-list = 10		manifest-list = 10
	msg = 11		msg = 11
	err-msg = 12		err-msg = 12
	evidence-format = 13		evidence-format = 13
	requested-tc-list = 14		requested-tc-list = 14
	unneeded-tc-list = 15		unneeded-tc-list = 15
	component-id = 16		component-id = 16
	tc-manifest-sequence-number = 17		tc-manifest-sequence-number = 17
	have-binary = 18		have-binary = 18
	suit-reports = 19		suit-reports = 19
			token = 20
	D. Examples of Diagnostic Notation and Binary Representation		D. Examples of Diagnostic Notation and Binary Representation
	D.1. Some assumptions in examples		D.1. Some assumptions in examples
	o OCSP stapling data = h'010203'		o OCSP stapling data = h'010203'
	o TEEP Device will have 2 TAs		o TEEP Device will have 2 TAs with the following SUIT Component
	* TA-ID: 0x0102030405060708090a0b0c0d0e0f,		Identifiers:
	0x1102030405060708090a0b0c0d0e0f
	o SUIT manifest-list is set empty only for example purposes		* [ 0x0102030405060708090a0b0c0d0e0f ]
	o Not including Entity Attestation Token (EAT) parameters for		* [ 0x1102030405060708090a0b0c0d0e0f ]
	example purposes
			o SUIT manifest-list is set empty only for example purposes
	D.2. QueryRequest Message		D.2. QueryRequest Message
	D.2.1. CBOR Diagnostic Notation		D.2.1. CBOR Diagnostic Notation
	/ query-request = /		/ query-request = /
	[		[
	1, / type : TEEP-TYPE-query-request = 1 (fixed int) /		1, / type : TEEP-TYPE-query-request = 1 (uint (0..23)) /
	2004318071, / token : 0x77777777 (uint), generated by TAM /
	/ options : /		/ options : /
	{		{
	1 : [ 1 ] / supported-cipher-suites = 1 (mapkey) : /		20 : 0xa0a1a2a3a4a5a6a7,
	/ TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =		/ token = 20 (mapkey) :
	[ 1 ] (array of uint .size 8) /		h'a0a1a2a3a4a5a6a7' (bstr .size (8..64)),
	3 : [ 0 ] / version = 3 (mapkey) :		generated by TAM /
	[ 0 ] (array of uint .size 4) /		1 : [ 1 ], / supported-cipher-suites = 1 (mapkey) :
	4 : h'010203' / ocsp-data = 4 (mapkey) : 0x010203 (bstr) /		TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =
			[ 1 ] (array of .within uint .size 4) /
			3 : [ 0 ], / version = 3 (mapkey) :
			[ 0 ] (array of .within uint .size 4) /
			4 : h'010203' / ocsp-data = 4 (mapkey) : 0x010203 (bstr) /
	},		},
	2 / data-item-requested : trusted-components = 2 (uint) /		3 / data-item-requested :
	]		attestation | trusted-components = 3 (.within uint .size 8) /
			]
	D.2.2. CBOR Binary Representation		D.2.2. CBOR Binary Representation
	84 # array(4),		83 # array(3)
	01 # unsigned(1)		01 # unsigned(1) uint (0..23)
	1A 77777777 # unsigned(2004318071, 0x77777777)		A4 # map(4)
	A3 # map(3)		14 # unsigned(20) uint (0..23)
	01 # unsigned(1)		48 # bytes(8) (8..64)
	81 # array(1)		A0A1A2A3A4A5A6A7
	01 # unsigned(1) within .size 8		01 # unsigned(1) uint (0..23)
	03 # unsigned(3)		81 # array(1)
	81 # array(1)		01 # unsigned(1) within uint .size 4
	00 # unsigned(0) within .size 4		03 # unsigned(3) uint (0..23)
	04 # unsigned(4)		81 # array(1)
	43 # bytes(3)		00 # unsigned(0) within uint .size 4
	010203 # "\x01\x02\x03"		04 # unsigned(4) uint (0..23)
	02 # unsigned(2)		43 # bytes(3)
			010203 # "\x01\x02\x03"
	D.3. QueryResponse Message		03 # unsigned(3) .within uint .size 8
	D.3.1. CBOR Diagnostic Notation		D.3. Entity Attestation Token
	/ query-response = /		This is shown below in CBOR diagnostic form. Only the payload signed
	[		by COSE is shown.
	2, / type : TEEP-TYPE-query-response = 2 (fixed int) /
	2004318071, / token : 0x77777777 (uint), from TAM's QueryRequest
	message /
	/ options : /
	{
	5 : 1, / selected-cipher-suite = 5(mapkey) :/
	/ TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =
	1 (uint .size 8) /
	6 : 0, / selected-version = 6 (mapkey) : 0 (uint .size 4) /
	8 : [ h'0102030405060708090a0b0c0d0e0f',
	h'1102030405060708090a0b0c0d0e0f' ]
	/ ta-list = 8 (mapkey) :
	[ 0x0102030405060708090a0b0c0d0e0f,
	0x1102030405060708090a0b0c0d0e0f ]
	(array of bstr) /
	}
	]
	D.3.2. CBOR Binary Representation		D.3.1. CBOR Diagnostic Notation
	83 # array(3)		/ eat-claim-set = /
	02 # unsigned(2)		{
	1A 77777777 # unsigned(2004318071, 0x77777777)		/ issuer / 1: "joe",
	A3 # map(3)		/ timestamp (iat) / 6: 1(1526542894)
	05 # unsigned(5)		/ nonce / 10: h'948f8860d13a463e8e',
	01 # unsigned(1) within .size 8		/ secure-boot / 15: true,
	06 # unsigned(6)		/ debug-status / 16: 3, / disabled-permanently /
	00 # unsigned(0) within .size 4		/ security-level / <TBD>: 3, / secure-restricted /
	08 # unsigned(8)		/ device-identifier / <TBD>: h'e99600dd921649798b013e9752dcf0c5',
	82 # array(2)		/ vendor-identifier / <TBD>: h'2b03879b33434a7ca682b8af84c19fd4',
	4F # bytes(16)		/ class-identifier / <TBD>: h'9714a5796bd245a3a4ab4f977cb8487f',
	0102030405060708090A0B0C0D0D0F		/ chip-version-scheme / <TBD35>: "MyTEE v1.0",
	4F # bytes(16)		/ component-identifier / <TBD>: h'60822887d35e43d5b603d18bcaa3f08d',
	1102030405060708090A0B0C0D0D0F		/ version / <TBD>: "v0.1"
			}
	D.4. Install Message		D.4. QueryResponse Message
	D.4.1. CBOR Diagnostic Notation		D.4.1. CBOR Diagnostic Notation
	/ install = /		/ query-response = /
	[		[
	3, / type : TEEP-TYPE-install = 3 (fixed int) /		2, / type : TEEP-TYPE-query-response = 2 (uint (0..23)) /
	2004318072, / token : 0x777777778 (uint), generated by TAM /		/ options : /
	/ options : /		{
	{		20 : 0xa0a1a2a3a4a5a6a7,
	10 : [ ] / manifest-list = 10 (mapkey) :		/ token = 20 (mapkey) :
	[ ] (array of SUIT_Envelope(any)) /		h'a0a1a2a3a4a5a6a7' (bstr .size (8..64)),
	/ empty, example purpose only /		given from TAM's QueryRequest message /
			5 : 1, / selected-cipher-suite = 5 (mapkey) :
			TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =
			1 (.within uint .size 4) /
			6 : 0, / selected-version = 6 (mapkey) :
			0 (.within uint .size 4) /
			7 : ... / evidence = 7 (mapkey) :
			Entity Attestation Token /
			8 : [ / tc-list = 8 (mapkey) : (array of tc-info) /
			{
			16 : [ 0x0102030405060708090a0b0c0d0e0f ] / component-id =
			16 (mapkey) : [ h'0102030405060708090a0b0c0d0e0f' ]
			(SUIT_Component_Identifier = [* bstr]) /
			},
			{
			16 : [ 0x1102030405060708090a0b0c0d0e0f ] / component-id =
			16 (mapkey) : [ h'1102030405060708090a0b0c0d0e0f' ]
			(SUIT_Component_Identifier = [* bstr]) /
			}
			]
	}		}
	]		]
	D.4.2. CBOR Binary Representation		D.4.2. CBOR Binary Representation
			82 # array(2)
			02 # unsigned(2) uint (0..23)
			A5 # map(5)
			14 # unsigned(20) uint (0..23)
			48 # bytes(8) (8..64)
			A0A1A2A3A4A5A6A7
			05 # unsigned(5) uint (0..23)
			01 # unsigned(1) .within uint .size 4
			06 # unsigned(6) uint (0..23)
			00 # unsigned(0) .within uint .size 4
			07 # unsigned(7) uint (0..23)
			... # Entity Attestation Token
			08 # unsigned(8) uint (0..23)
			82 # array(2)
			81 # array(1)
			4F # bytes(15)
			0102030405060708090A0B0C0D0E0F
			81 # array(1)
			4F # bytes(15)
			1102030405060708090A0B0C0D0E0F
	83 # array(3)		D.5. Update Message
	03 # unsigned(3)
	1A 77777778 # unsigned(2004318072, 0x77777778)
	A1 # map(1)
	0A # unsigned(10)
	80 # array(0)
	D.5. Success Message (for Install)
	D.5.1. CBOR Diagnostic Notation		D.5.1. CBOR Diagnostic Notation
	/ teep-success = /		/ update = /
	[		[
	5, / type : TEEP-TYPE-teep-success = 5 (fixed int) /		3, / type : TEEP-TYPE-update = 3 (uint (0..23)) /
	2004318072, / token : 0x777777778 (uint), from Install message /		/ options : /
			{
			20 : 0xaba1a2a3a4a5a6a7,
			/ token = 20 (mapkey) :
			h'aba1a2a3a4a5a6a7' (bstr .size (8..64)),
			generated by TAM /
			15 : [ [ h'0102030405060708090a0b0c0d0e0f' ] ]
			/ unneeded-tc-list = 15 (mapkey) :
			[ [ h'0102030405060708090a0b0c0d0e0f' ] ]
			(array of SUIT_Component_Identifier = [* bstr]) /
			10 : [ ] / manifest-list = 10 (mapkey) :
			[ ] (array of bstr wrapped SUIT_Envelope(any)) /
			/ empty, example purpose only /
			}
	]		]
	D.5.2. CBOR Binary Representation		D.5.2. CBOR Binary Representation
	83 # array(3)		82 # array(2)
	05 # unsigned(5)		03 # unsigned(3) uint (0..23)
	1A 77777778 # unsigned(2004318072, 0x77777778)		A3 # map(3)
			14 # unsigned(20) uint (0..23)
			48 # bytes(8) (8..64)
			ABA1A2A3A4A5A6A7
			0F # unsigned(15) uint (0..23)
			81 # array(1)
			81 # array(1)
			4F # bytes(15)
			0102030405060708090A0B0C0D0E0F
			0A # unsigned(10) uint (0..23)
			80 # array(0)
	D.6. Error Message (for Install)		D.6. Success Message
	D.6.1. CBOR Diagnostic Notation		D.6.1. CBOR Diagnostic Notation
	/ teep-error = /
			/ teep-success = /
	[		[
	6, / type : TEEP-TYPE-teep-error = 6 (fixed int) /		5, / type : TEEP-TYPE-teep-success = 5 (uint (0..23)) /
	2004318072, / token : 0x777777778 (uint), from Install message /		/ options : /
	ERR_MANIFEST_PROCESSING_FAILED,		{
	/ err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint) /		20 : 0xaba1a2a3a4a5a6a7,
	/ options : /		/ token = 20 (mapkey) :
	{		h'aba1a2a3a4a5a6a7' (bstr .size (8..64)),
	12 : "disk-full" / err-msg = 12 (mapkey) :		given from TAM's Update message /
	"disk-full" (UTF-8 string) /		}
	}
	]		]
	D.6.2. CBOR binary Representation		D.6.2. CBOR Binary Representation
	83 # array(3)		82 # array(2)
	06 # unsigned(6)		05 # unsigned(5) uint (0..23)
	1A 77777778 # unsigned(2004318072, 0x77777778)		A1 # map(1)
	11 # unsigned(17)		14 # unsigned(20) uint (0..23)
	A1 # map(1)		48 # bytes(8) (8..64)
	0B # unsigned(12)		ABA1A2A3A4A5A6A7
	69 # text(9)
	6469736b2d66756c6c # "disk-full"		D.7. Error Message
			D.7.1. CBOR Diagnostic Notation
			/ teep-error = /
			[
			6, / type : TEEP-TYPE-teep-error = 6 (uint (0..23)) /
			/ options : /
			{
			20 : 0xaba1a2a3a4a5a6a7,
			/ token = 20 (mapkey) :
			h'aba1a2a3a4a5a6a7' (bstr .size (8..64)),
			given from TAM's Update message /
			12 : "disk-full" / err-msg = 12 (mapkey) :
			"disk-full" (text .size (1..128)) /
			},
			17, / err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint (0..23)) /
			]
			D.7.2. CBOR binary Representation
			83 # array(3)
			06 # unsigned(6) uint (0..23)
			A2 # map(2)
			14 # unsigned(20) uint (0..23)
			48 # bytes(8) (8..64)
			ABA1A2A3A4A5A6A7
			0C # unsigned(12) uint (0..23)
			69 # text(9) (1..128)
			6469736b2d66756c6c # "disk-full"
			11 # unsigned(17) uint (0..23)
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Arm Ltd.		Arm Ltd.
	Absam, Tirol 6067		Absam, Tirol 6067
	Austria		Austria
	Email: hannes.tschofenig@arm.com		Email: hannes.tschofenig@arm.com
End of changes. 139 change blocks.
	437 lines changed or deleted		620 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/