< draft-ietf-teep-protocol-06.txt		draft-ietf-teep-protocol-07.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: January 13, 2022 Broadcom		Expires: 28 April 2022 Broadcom
	D. Wheeler		D. Wheeler
	Amazon		Amazon
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	A. Tsukamoto		A. Tsukamoto
	AIST		AIST
	July 12, 2021		25 October 2021
	Trusted Execution Environment Provisioning (TEEP) Protocol		Trusted Execution Environment Provisioning (TEEP) Protocol
	draft-ietf-teep-protocol-06		draft-ietf-teep-protocol-07
	Abstract		Abstract
	This document specifies a protocol that installs, updates, and		This document specifies a protocol that installs, updates, and
	deletes Trusted Components in a device with a Trusted Execution		deletes Trusted Components in a device with a Trusted Execution
	Environment (TEE). This specification defines an interoperable		Environment (TEE). This specification defines an interoperable
	protocol for managing the lifecycle of Trusted Components.		protocol for managing the lifecycle of Trusted Components.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 January 13, 2022.		This Internet-Draft will expire on 28 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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 (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		Please review these documents carefully, as they describe your rights
	to this document. Code Components extracted from this document must		and restrictions with respect to this document. Code Components
	include Simplified BSD License text as described in Section 4.e of		extracted from this document must include Simplified BSD License text
	the Trust Legal Provisions and are provided without warranty as		as described in Section 4.e of the Trust Legal Provisions and are
	described in the Simplified BSD License.		provided without warranty as 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 . . . . . . . . . . . . . . . 5		4. Detailed Messages Specification . . . . . . . . . . . . . . . 5
	4.1. Creating and Validating TEEP Messages . . . . . . . . . . 5		4.1. Creating and Validating TEEP Messages . . . . . . . . . . 5
	4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 5		4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 5
	4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6		4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6
	4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 6		4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 6
	4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9		4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9
	4.3.1. Evidence . . . . . . . . . . . . . . . . . . . . . . 11		4.3.1. Evidence . . . . . . . . . . . . . . . . . . . . . . 11
	4.4. Update Message . . . . . . . . . . . . . . . . . . . . . 12		4.4. Update Message . . . . . . . . . . . . . . . . . . . . . 12
	4.5. Success Message . . . . . . . . . . . . . . . . . . . . . 14		4.5. Success Message . . . . . . . . . . . . . . . . . . . . . 14
	4.6. Error Message . . . . . . . . . . . . . . . . . . . . . . 15		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. Behavior Specification . . . . . . . . . . . . . . . . . . . 18		6. Behavior Specification . . . . . . . . . . . . . . . . . . . 20
	6.1. TAM Behavior . . . . . . . . . . . . . . . . . . . . . . 18		6.1. TAM Behavior . . . . . . . . . . . . . . . . . . . . . . 20
	6.2. TEEP Agent Behavior . . . . . . . . . . . . . . . . . . . 19		6.2. TEEP Agent Behavior . . . . . . . . . . . . . . . . . . . 21
	7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 20		7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 22
	8. Freshness Mechanisms . . . . . . . . . . . . . . . . . . . . 21		8. Freshness Mechanisms . . . . . . . . . . . . . . . . . . . . 22
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 21		9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Media Type Registration . . . . . . . . . . . . . . . . 23		10.1. Media Type Registration . . . . . . . . . . . . . . . . 25
	10.2. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 24		10.2. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 26
	10.3. Freshness Mechanism Registry . . . . . . . . . . . . . . 24		10.3. Freshness Mechanism Registry . . . . . . . . . . . . . . 27
	10.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . 25		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		11.1. Normative References . . . . . . . . . . . . . . . . . . 27
	11.1. Normative References . . . . . . . . . . . . . . . . . . 25		11.2. Informative References . . . . . . . . . . . . . . . . . 29
	11.2. Informative References . . . . . . . . . . . . . . . . . 26		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 30
	C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 27		D. Examples of Diagnostic Notation and Binary Representation . . 34
	D. Examples of Diagnostic Notation and Binary Representation . . 31		D.1. QueryRequest Message . . . . . . . . . . . . . . . . . . 34
	D.1. Some assumptions in examples . . . . . . . . . . . . . . 31		D.1.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 34
	D.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 31		D.1.2. CBOR Binary Representation . . . . . . . . . . . . . 34
	D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 32		D.2. Entity Attestation Token . . . . . . . . . . . . . . . . 35
	D.2.2. CBOR Binary Representation . . . . . . . . . . . . . 32		D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35
	D.3. Entity Attestation Token . . . . . . . . . . . . . . . . 32		D.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 35
	D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 33		D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35
	D.4. QueryResponse Message . . . . . . . . . . . . . . . . . . 33		D.3.2. CBOR Binary Representation . . . . . . . . . . . . . 36
	D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 33		D.4. Update Message . . . . . . . . . . . . . . . . . . . . . 37
	D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 34		D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 37
	D.5. Update Message . . . . . . . . . . . . . . . . . . . . . 35		D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 37
	D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35		D.5. Success Message . . . . . . . . . . . . . . . . . . . . . 38
	D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 35		D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 38
	D.6. Success Message . . . . . . . . . . . . . . . . . . . . . 36		D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 38
	D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 36		D.6. Error Message . . . . . . . . . . . . . . . . . . . . . . 38
	D.6.2. CBOR Binary Representation . . . . . . . . . . . . . 36		D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 38
	D.7. Error Message . . . . . . . . . . . . . . . . . . . . . . 36		D.6.2. CBOR binary Representation . . . . . . . . . . . . . 39
	D.7.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 36		E. Examples of SUIT Manifests . . . . . . . . . . . . . . . . . 39
	D.7.2. CBOR binary Representation . . . . . . . . . . . . . 37		E.1. Install a Trusted Component . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37		E.2. Delete a Trusted Component . . . . . . . . . . . . . . . 43
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	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 Trusted		systems in the REE and may use different types of TEEs. When Trusted
	Component Developers or Device Administrators use Trusted Application		Component Developers or Device Administrators use Trusted Application
	Managers (TAMs) to install, update, and delete Trusted Applications		Managers (TAMs) to install, update, and delete Trusted Applications
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 13 ¶
	message created by a TAM.		message created by a TAM.
	2. Create a COSE Header containing the desired set of Header		2. Create a COSE Header containing the desired set of Header
	Parameters. The COSE Header MUST be valid per the [RFC8152]		Parameters. The COSE Header MUST be valid per the [RFC8152]
	specification.		specification.
	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
	the CBOR-encoded message is indeed a TEEP message.
	4.1.2. Validating a TEEP Message		4.1.2. Validating a TEEP Message
	When TEEP message is received (see the ProcessTeepMessage conceptual		When TEEP message is received (see the ProcessTeepMessage conceptual
	API defined in [I-D.ietf-teep-architecture] section 6.2.1), the		API defined in [I-D.ietf-teep-architecture] section 6.2.1), the
	following validation steps are performed. If any of the listed steps		following validation steps are performed. If any of the listed steps
	fail, then the TEEP message MUST be rejected.		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. Verify that the message contains a COSE_Sign1 structure.
	CBOR tags follows it.
	3. Verify that the message contains a COSE_Sign1 structure.
	4. Verify that the resulting COSE Header includes only parameters		3. 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
	supported or that are specified as being ignored when not		supported or that are specified as being ignored when not
	understood.		understood.
	5. Follow the steps specified in Section 4 of [RFC8152] ("Signing		4. Follow the steps specified in Section 4 of [RFC8152] ("Signing
	Objects") for validating a COSE_Sign1 object. The COSE_Sign1		Objects") for validating a COSE_Sign1 object. The COSE_Sign1
	payload is the content of the TEEP message.		payload is the content of the TEEP message.
	6. Verify that the TEEP message is a valid CBOR map and verify the		5. Verify that the TEEP message is a valid CBOR map and verify the
	fields of the TEEP message according to this specification.		fields of the TEEP message according to this specification.
	4.2. QueryRequest Message		4.2. QueryRequest Message
	A QueryRequest message is used by the TAM to learn information from		A QueryRequest message is used by the TAM to learn information from
	the TEEP Agent, such as the features supported by the TEEP Agent,		the TEEP Agent, such as the features supported by the TEEP Agent,
	including ciphersuites, and protocol versions. Additionally, the TAM		including ciphersuites, and protocol versions. Additionally, the TAM
	can selectively request data items from the TEEP Agent via the		can selectively request data items from the TEEP Agent via the
	request parameter. Currently, the following features are supported:		request parameter. Currently, the following features are supported:
	o Request for attestation information,		* Request for attestation information,
	o Listing supported extensions,		* Listing supported extensions,
	o Querying installed Trusted Components, and		* Querying installed Trusted Components, and
	o Listing supported SUIT commands.		* Listing supported 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 Appendix C.		shown in Appendix C.
	query-request = [		query-request = [
	type: TEEP-TYPE-query-request,		type: TEEP-TYPE-query-request,
	options: {		options: {
	? token => bstr .size (8..64),		? token => bstr .size (8..64),
	? supported-cipher-suites => [ + suite ],		? supported-cipher-suites => [ + suite ],
	? supported-freshness-mechanisms => [ + freshness-mechanism ],		? supported-freshness-mechanisms => [ + freshness-mechanism ],
	? challenge => bstr .size (8..512),		? challenge => bstr .size (8..512),
	? versions => [ + version ],		? versions => [ + version ],
	? ocsp-data => bstr,
	* $$query-request-extensions		* $$query-request-extensions
	* $$teep-option-extensions		* $$teep-option-extensions
	},		},
	data-item-requested: 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. The token MUST be present if		concurrent requests to a TEEP Agent. The token MUST be present if
	and only if the attestation bit is clear in the data-item-		and only if the attestation bit is clear in the data-item-
	requested value. The size of the token is at least 8 bytes (64		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		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).		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 SHOULD set an expiration time for each token
			and MUST ignore any messages with expired tokens. The TAM MUST
			expire the token value after receiving the first response
			containing the token value 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.
	trusted-components (2) With this value the TAM queries the TEEP		trusted-components (2) With this value the TAM queries the TEEP
	Agent for all installed Trusted Components.		Agent for all installed Trusted Components.
	extensions (4) With this value the TAM queries the TEEP Agent for		extensions (4) With this value the TAM queries the TEEP Agent for
	supported capabilities and extensions, which allows a TAM to		supported capabilities and extensions, which allows a TAM to
	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
	for supported commands offered by the SUIT manifest
	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. If this parameter is not present, it is to		supported by the TAM. If this parameter is not present, it is to
	be treated the same as if it contained both ciphersuites defined		be treated the same as if it contained both ciphersuites defined
	in this document. Details about the ciphersuite encoding can be		in this document. Details about the ciphersuite encoding can be
	found in Section 7.		found in Section 7.
	supported-freshness-mechanisms		supported-freshness-mechanisms
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 41 ¶
	mechanism(s) supported by the TAM. Details about the encoding can		mechanism(s) supported by the TAM. Details about the encoding can
	be found in Section 8. If this parameter is absent, it means only		be found in Section 8. If this parameter is absent, it means only
	the nonce mechanism is supported.		the nonce mechanism is supported.
	challenge		challenge
	The challenge field is an optional parameter used for ensuring the		The challenge field is an optional parameter used for ensuring the
	freshness of the attestation evidence returned with a		freshness of the attestation evidence returned with a
	QueryResponse message. It MUST be absent if the attestation bit		QueryResponse message. It MUST be absent if the attestation bit
	is clear (since the token is used instead in that case). When a		is clear (since the token is used instead in that case). When a
	challenge is provided in the QueryRequest and an EAT is returned		challenge is provided in the QueryRequest and an EAT is returned
	with the QueryResponse message then the challenge contained in		with a QueryResponse message then the challenge contained in this
	this request MUST be copied into the nonce claim found in the EAT.		request MUST be used to generate the EAT, such as by copying the
	If any format other than EAT is used, it is up to that format to		challengt into the nonce claim found in the EAT if using the Nonce
	define the use of the challenge field.		freshness mechanism. For more details see Section 8. If any
			format other than EAT is used, it is up to that format to define
			the use of the challenge field.
	versions		versions
	The versions parameter enumerates the TEEP protocol version(s)		The versions parameter enumerates the TEEP protocol version(s)
	supported by the TAM. A value of 0 refers to the current version		supported by the TAM. A value of 0 refers to the current version
	of the TEEP protocol. If this field is not present, it is to be		of the TEEP protocol. If this field is not present, it is to be
	treated the same as if it contained only version 0.		treated the same as if it contained only version 0.
	ocsp-data
	The ocsp-data parameter contains a list of OCSP stapling data
	respectively for the TAM certificate and each of the CA
	certificates up to, but not including, the trust anchor. The TAM
	provides OCSP data so that the TEEP Agent can validate the status
	of the TAM certificate chain without making its own external OCSP
	service call. OCSP data MUST be conveyed as a DER-encoded OCSP
	response (using the ASN.1 type OCSPResponse defined in [RFC6960]).
	The use of OCSP is OPTIONAL to implement for both the TAM and the
	TEEP Agent. A TAM can query the TEEP Agent for the support of
	this functionality via the capability discovery exchange, as
	described above.
	4.3. QueryResponse Message		4.3. QueryResponse Message
	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 Appendix C.		structure is shown in Appendix C.
	query-response = [		query-response = [
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	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 Trusted Component can be deleted. Each		in determining whether a Trusted Component can be deleted. Each
	unneeded Trusted Component is identified by its SUIT Component		unneeded Trusted Component is identified by its SUIT Component
	Identifier. A TEEP Agent can get this information from the		Identifier. A TEEP Agent can get this information from the
	UnrequestTA conceptual API defined in [I-D.ietf-teep-architecture]		UnrequestTA conceptual API defined in [I-D.ietf-teep-architecture]
	section 6.2.1.		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. This parameter MUST be
			present if the QueryResponse is sent in response to a QueryRequest
			with the extensions bit set.
	The tc-info object has the following fields:		The tc-info object has the following fields:
	component-id		component-id
	A SUIT Component Identifier.		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.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	have-binary is true, the tc-manifest-sequence-number field MUST be		have-binary is true, the tc-manifest-sequence-number field MUST be
	present.		present.
	4.3.1. Evidence		4.3.1. Evidence
	Section 7.1 of [I-D.ietf-teep-architecture] lists information that		Section 7.1 of [I-D.ietf-teep-architecture] lists information that
	may be required in the evidence depend on the circumstance. When an		may be required in the evidence depend on the circumstance. When an
	Entity Attestation Token is used, the following claims can be used to		Entity Attestation Token is used, the following claims can be used to
	meet those requirements:		meet those requirements:
	+------------+---------------------+--------------------------------+		+===========+=====================+=================================+
	| Requiremen | Claim | Reference |		|Requirement|Claim | Reference |
	| t | | |		+===========+=====================+=================================+
	+------------+---------------------+--------------------------------+		|Device |device-identifier | [I-D.birkholz-rats-suit-claims] |
	| Device | device-identifier | [I-D.birkholz-rats-suit-claims |		|unique | | section 3.1.3 |
	| unique | | ] section 3.1.3 |		|identifier | | |
	| identifier | | |		+-----------+---------------------+---------------------------------+
	| Vendor of | vendor-identifier | [I-D.birkholz-rats-suit-claims |		|Vendor of |vendor-identifier | [I-D.birkholz-rats-suit-claims] |
	| the device | | ] section 3.1.1 |		|the device | | section 3.1.1 |
	| Class of | class-identifier | [I-D.birkholz-rats-suit-claims |		+-----------+---------------------+---------------------------------+
	| the device | | ] section 3.1.2 |		|Class of |class-identifier | [I-D.birkholz-rats-suit-claims] |
	| TEE | chip-version-scheme | [I-D.ietf-rats-eat] section |		|the device | | section 3.1.2 |
	| hardware | | 3.7 |		+-----------+---------------------+---------------------------------+
	| type | | |		|TEE |chip-version | [I-D.ietf-rats-eat] section 3.7 |
	| TEE | chip-version-scheme | [I-D.ietf-rats-eat] section |		|hardware | | |
	| hardware | | 3.7 |		|type | | |
	| version | | |		+-----------+---------------------+---------------------------------+
	| TEE | component- | [I-D.birkholz-rats-suit-claims |		|TEE |chip-version | [I-D.ietf-rats-eat] section 3.7 |
	| firmware | identifier | ] section 3.1.4 |		|hardware | | |
	| type | | |		|version | | |
	| TEE | version | [I-D.birkholz-rats-suit-claims |		+-----------+---------------------+---------------------------------+
	| firmware | | ] section 3.1.8 |		|TEE |component-identifier | [I-D.birkholz-rats-suit-claims] |
	| version | | |		|firmware | | section 3.1.4 |
	| Freshness | nonce | [I-D.ietf-rats-eat] section |		|type | | |
	| proof | | 3.3 |		+-----------+---------------------+---------------------------------+
	+------------+---------------------+--------------------------------+		|TEE |version | [I-D.birkholz-rats-suit-claims] |
			|firmware | | section 3.1.8 |
			|version | | |
			+-----------+---------------------+---------------------------------+
			|Freshness |nonce | [I-D.ietf-rats-eat] section 3.3 |
			|proof | | |
			+-----------+---------------------+---------------------------------+
			Table 1
	4.4. Update Message		4.4. Update Message
	The Update message is used by the TAM to install and/or delete one or		The Update message is used by the TAM to install and/or delete one or
	more Trusted Components via the TEEP Agent.		more Trusted Components via the TEEP Agent.
	Like other TEEP messages, the Update message is signed, and the		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 Appendix C.		shown in Appendix C.
	skipping to change at page 15, line 50 ¶		skipping to change at page 16, line 8 ¶
	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.		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 7. This field is optional but		encoding can be found in Section 7. This otherwise optional
	MUST be returned with the ERR_UNSUPPORTED_CRYPTO_ALG error		parameter MUST be returned if err-code is
	message.		ERR_UNSUPPORTED_CIPHER_SUITES.
	supported-freshness-mechanisms		supported-freshness-mechanisms
	The supported-freshness-mechanisms parameter lists the freshness		The supported-freshness-mechanisms parameter lists the freshness
	mechanism(s) supported by the TEEP Agent. Details about the		mechanism(s) supported by the TEEP Agent. Details about the
	encoding can be found in Section 8. If this parameter is absent,		encoding can be found in Section 8. This otherwise optional
	it means only the nonce mechanism is supported.		parameter MUST be returned if err-code is
			ERR_UNSUPPORTED_FRESHNESS_MECHANISMS.
	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 if err-code is ERR_UNSUPPORTED_MSG_VERSION.
	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]. If		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		the suit-report-nonce field is present in the SUIT Report, is
	value MUST match the value of the token parameter in the Update		value MUST match the value of the token parameter in the Update
	message the Error message is in response to.		message the Error message is in response to.
	err-code		err-code
	The err-code parameter contains one of the error codes listed		The err-code parameter contains one of the error codes listed
	skipping to change at page 16, line 49 ¶		skipping to change at page 17, line 12 ¶
	ERR_TEMPORARY_ERROR is an indication that a more agressive retry		ERR_TEMPORARY_ERROR is an indication that a more agressive retry
	is warranted.		is warranted.
	ERR_UNSUPPORTED_EXTENSION (2)		ERR_UNSUPPORTED_EXTENSION (2)
	The TEEP Agent does not support an extension included in the		The TEEP Agent does not support an extension included in the
	request message. For diagnosis purposes it is RECOMMMENDED to		request message. For diagnosis purposes it is RECOMMMENDED to
	identify the unsupported extension in the error message. A TAM		identify the unsupported extension in the error message. A TAM
	receiving this error might retry the request without using		receiving this error might retry the request without using
	extensions.		extensions.
			ERR_UNSUPPORTED_FRESHNESS_MECHANISMS (3)
			The TEEP Agent does not support any freshness algorithm mechanisms
			in the request message. A TAM receiving this error might retry
			the request using a different set of supported freshness
			mechanisms in the request 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. A TAM receiving this error		indicated in the request message. A TAM receiving this error
	might retry the request using a different TEEP protocol version.		might retry the request using a different TEEP protocol version.
	ERR_UNSUPPORTED_CRYPTO_ALG (5)		ERR_UNSUPPORTED_CIPHER_SUITES (5)
	The TEEP Agent does not support the cryptographic algorithm		The TEEP Agent does not support any ciphersuites indicated in the
	indicated in the request message. A TAM receiving this error		request message. A TAM receiving this error might retry the
	might retry the request using a different cryptographic algorithm.		request using a different set of supported ciphersuites in the
			request message.
	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. For example, the certificate was of an		in the error message. For example, the certificate was of an
	unsupported type, or the certificate was revoked by its signer. A		unsupported type, or the certificate was revoked by its signer. A
	TAM receiving this error might attempt to use an alternate		TAM receiving this error might attempt to use an alternate
	certificate.		certificate.
	ERR_CERTIFICATE_EXPIRED (9)		ERR_CERTIFICATE_EXPIRED (9)
	skipping to change at page 18, line 5 ¶		skipping to change at page 19, line 5 ¶
	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:
	+--------------------------------+-------+		+================================+=======+
	| Name | Label |		| Name | Label |
	+--------------------------------+-------+		+================================+=======+
	| supported-cipher-suites | 1 |		| supported-cipher-suites | 1 |
			+--------------------------------+-------+
	| challenge | 2 |		| challenge | 2 |
			+--------------------------------+-------+
	| version | 3 |		| version | 3 |
	| 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 |		| token | 20 |
			+--------------------------------+-------+
	| supported-freshness-mechanisms | 21 |		| supported-freshness-mechanisms | 21 |
	+--------------------------------+-------+		+--------------------------------+-------+
			Table 2
	6. Behavior Specification		6. Behavior Specification
	Behavior is specified in terms of the conceptual APIs defined in		Behavior is specified in terms of the conceptual APIs defined in
	section 6.2.1 of [I-D.ietf-teep-architecture].		section 6.2.1 of [I-D.ietf-teep-architecture].
	6.1. TAM Behavior		6.1. TAM Behavior
	When the ProcessConnect API is invoked, the TAM sends a QueryRequest		When the ProcessConnect API is invoked, the TAM sends a QueryRequest
	message.		message.
	skipping to change at page 20, line 38 ¶		skipping to change at page 22, line 12 ¶
	some time, and the Success or Error message is generated only after		some time, and the Success or Error message is generated only after
	completing the Update Procedure.		completing the Update Procedure.
	7. Ciphersuites		7. Ciphersuites
	A ciphersuite consists of an AEAD algorithm, a MAC algorithm, and a		A ciphersuite consists of an AEAD algorithm, a MAC 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 10.2. This document specifies two ciphersuites.		Section 10.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 |
	+-------+------------------------------------------------+		+-------+------------------------------------------------+
			Table 3
	A TAM MUST support both ciphersuites. A TEEP Agent MUST support at		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		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.		Agent might choose ciphersuite 2 if it has hardware support for it.
	Any ciphersuites without confidentiality protection can only be added		Any ciphersuites without confidentiality protection can only be added
	if the associated specification includes a discussion of security		if the associated specification includes a discussion of security
	considerations and applicability, since manifests may carry sensitive		considerations and applicability, since manifests may carry sensitive
	information. For example, Section 6 of [I-D.ietf-teep-architecture]		information. For example, Section 6 of [I-D.ietf-teep-architecture]
	permits implementations that terminate transport security inside the		permits implementations that terminate transport security inside the
	TEE and if the transport security provides confidentiality then		TEE and if the transport security provides confidentiality then
	skipping to change at page 21, line 24 ¶		skipping to change at page 23, line 5 ¶
	A freshness mechanism determines how a TAM can tell whether evidence		A freshness mechanism determines how a TAM can tell whether evidence
	provided in a Query Response is fresh. There are multiple ways this		provided in a Query Response is fresh. There are multiple ways this
	can be done as discussed in Section 10 of		can be done as discussed in Section 10 of
	[I-D.ietf-rats-architecture].		[I-D.ietf-rats-architecture].
	Each freshness mechanism is identified with an integer value, which		Each freshness mechanism is identified with an integer value, which
	corresponds to an IANA registered freshness mechanism (see		corresponds to an IANA registered freshness mechanism (see
	Section 10.3. This document defines the following freshness		Section 10.3. This document defines the following freshness
	mechanisms:		mechanisms:
	+-------+---------------------+		+=======+=====================+
	| Value | Freshness mechanism |		| Value | Freshness mechanism |
	+-------+---------------------+		+=======+=====================+
	| 1 | Nonce |		| 1 | Nonce |
			+-------+---------------------+
	| 2 | Timestamp |		| 2 | Timestamp |
			+-------+---------------------+
	| 3 | Epoch ID |		| 3 | Epoch ID |
	+-------+---------------------+		+-------+---------------------+
			Table 4
	In the Nonce mechanism, the evidence MUST include a nonce provided in		In the Nonce mechanism, the evidence MUST include a nonce provided in
	the QueryRequest challenge. In other mechanisms, a timestamp or		the QueryRequest challenge. In other mechanisms, a timestamp or
	epoch ID determined via mechanisms outside the TEEP protocol is used,		epoch ID determined via mechanisms outside the TEEP protocol is used,
	and the challenge is only needed in the QueryRequest message if a		and the challenge is only needed in the QueryRequest message if a
	challenge is needed in generating evidence for reasons other than		challenge is needed in generating evidence for reasons other than
	freshness.		freshness.
			If a TAM supports multiple freshness mechanisms that require
			different challenge formats, the QueryRequest message can currently
			only send one such challenge. This situation is expected to be rare,
			but should it occur, the TAM can choose to prioritize one of them and
			exclude the other from the supported-freshness-mechanisms in the
			QueryRequest, and resend the QueryRequest with the other mechanism if
			an ERR_UNSUPPORTED_FRESHNESS_MECHANISMS Error is received that
			indicates the TEEP Agent supports the other mechanism.
	9. Security Considerations		9. 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
	skipping to change at page 23, line 4 ¶		skipping to change at page 24, line 45 ¶
	compromised it can drop messages, delay the delivery of messages,		compromised it can drop messages, delay the delivery of messages,
	and replay messages but it cannot modify those messages. (A		and replay messages but it cannot modify those messages. (A
	replay would be, however, detected by the TEEP Agent.) A		replay would be, however, detected by the TEEP Agent.) A
	compromised TEEP Broker could reorder messages in an attempt to		compromised TEEP Broker could reorder messages in an attempt to
	install an old version of a Trusted Component. Information in the		install an old version of a Trusted Component. Information in the
	manifest ensures that TEEP Agents are protected against such		manifest ensures that TEEP Agents are protected against such
	downgrade attacks based on features offered by the manifest		downgrade attacks based on features offered by the manifest
	itself.		itself.
	Trusted Component Signer Compromise		Trusted Component Signer Compromise
	The QueryRequest message from a TAM to the TEEP Agent can include		A TAM is responsible for vetting a Trusted Component and before
	OCSP stapling data for the TAM's certificate and for intermediate		distributing them to TEEP Agents.
	CA certificates up to, but not including, the trust anchor so that
	the TEEP Agent can verify the certificate's revocation status. A
	certificate revocation status check on a Trusted Component Signer
	certificate is OPTIONAL by a TEEP Agent. A TAM is responsible for
	vetting a Trusted Component and before distributing them to TEEP
	Agents, so TEEP Agents can instead simply trust that a Trusted
	Component Signer certificate's status was done by the TAM.
	CA Compromise		It is RECOMMENDED to provide a way to update the trust anchor
	The CA issuing certificates to a TAM or a Trusted Component Signer
	might get compromised. A compromised intermediate CA certificate
	can be detected by a TEEP Agent by using OCSP information,
	assuming the revocation information is available. Additionally,
	it is RECOMMENDED to provide a way to update the trust anchor
	store used by the TEE, for example using a firmware update		store used by the TEE, for example using a firmware update
	mechanism. If the CA issuing certificates to devices gets		mechanism. Thus, if a Trusted Component Signer is later
	compromised then these devices might be rejected by a TAM, if		compromised, the TAM can update the trust anchor store used by the
	revocation is available to the TAM.		TEE, for example using a firmware update mechanism.
	Compromised TAM		CA Compromise
	The TEEP Agent SHOULD use OCSP information to verify the validity		The CA issuing certificates to a TEE or a Trusted Component Signer
	of the TAM's certificate (as well as the validity of intermediate		might get compromised. It is RECOMMENDED to provide a way to
	CA certificates). The integrity and the accuracy of the clock		update the trust anchor store used by the TEE, for example using a
	within the TEE determines the ability to determine an expired or		firmware update mechanism. If the CA issuing certificates to
	revoked certificate. OCSP stapling data includes signature		devices gets compromised then these devices might be rejected by a
	generation time, allowing certificate validity dates to be		TAM, if revocation is available to the TAM.
	compared to the current time.
			TAM Certificate Expiry
			The integrity and the accuracy of the clock within the TEE
			determines the ability to determine an expired TAM certificate, if
			certificates are used.
	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.
	10. IANA Considerations		10. IANA Considerations
	10.1. Media Type Registration		10.1. Media Type Registration
	skipping to change at page 24, line 4 ¶		skipping to change at page 25, line 41 ¶
	10.1. Media Type Registration		10.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
	Encoding considerations: Same as encoding considerations of		Encoding considerations: Same as encoding considerations of
	application/cbor.		application/cbor.
	Security considerations: See Security Considerations Section of this		Security considerations: See Security Considerations Section of this
	document.		document.
	Interoperability considerations: Same as interoperability		Interoperability considerations: Same as interoperability
	considerations of application/cbor as specified in [RFC7049].		considerations of application/cbor as specified in [RFC7049].
	Published specification: This document.		Published specification: This document.
	Applications that use this media type: TEEP protocol implementations		Applications that use this media type: TEEP protocol implementations
	Fragment identifier considerations: N/A		Fragment identifier considerations: N/A
	Additional information:		Additional information: Deprecated alias names for this type: N/A
	Deprecated alias names for this type: N/A
	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
	10.2. Ciphersuite Registry		10.2. 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.
	defined in Section 7.
			Name of registry: TEEP Ciphersuites
			Policy: Specification Required
			Additional requirements: The specification must document relevant
			security considerations.
			Initial values:
			+=======+=========================+===============+
			| Value | Ciphersuite | Specification |
			+=======+=========================+===============+
			| 1 | AES-CCM-16-64-128, HMAC | RFC TBD |
			| | 256/256, X25519, EdDSA | Section 7 |
			+-------+-------------------------+---------------+
			| 2 | AES-CCM-16-64-128, HMAC | RFC TBD |
			| | 256/256, P-256, ES256 | Section 7 |
			+-------+-------------------------+---------------+
			Table 5
			[RFC Editor: please replace TBD above with the number assigned to
			this document]
	10.3. Freshness Mechanism Registry		10.3. Freshness Mechanism Registry
	IANA is also requested to create a new registry for freshness		IANA is also requested to create a new registry for freshness
	mechanisms, as defined in Section 8.		mechanisms.
	10.4. CBOR Tag Registry
	IANA is requested to register a CBOR tag in the "CBOR Tags" registry		Name of registry: TEEP Freshness Mechanisms
	for use with TEEP messages.
	The registry contents is:		Policy: Specification Required
	o CBOR Tag: TBD1		Additional requirements: The specification must document relevant
			security considerations.
	o Data Item: TEEP Message		Initial values:
	o Semantics: TEEP Message, as defined in draft-ietf-teep-protocol		+=======+=====================+===================+
	(TODO: replace with RFC once published)		| Value | Freshness mechanism | Specification |
			+=======+=====================+===================+
			| 1 | Nonce | RFC TBD Section 8 |
			+-------+---------------------+-------------------+
			| 2 | Timestamp | RFC TBD Section 8 |
			+-------+---------------------+-------------------+
			| 3 | Epoch ID | RFC TBD Section 8 |
			+-------+---------------------+-------------------+
	o Reference: draft-ietf-teep-protocol (TODO: replace with RFC once		Table 6
	published)
	o Point of Contact: TEEP working group (teep@ietf.org)		[RFC Editor: please replace TBD above with the number assigned to
			this document]
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-rats-architecture]		[I-D.ietf-rats-architecture]
	Birkholz, H., Thaler, D., Richardson, M., Smith, N., and		Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
	W. Pan, "Remote Attestation Procedures Architecture",		W. Pan, "Remote Attestation Procedures Architecture", Work
	draft-ietf-rats-architecture-12 (work in progress), April		in Progress, Internet-Draft, draft-ietf-rats-architecture-
	2021.		12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
			ietf-rats-architecture-12.txt>.
	[I-D.ietf-rats-eat]		[I-D.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Ballesteros, M., and J.		Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
	O'Donoghue, "The Entity Attestation Token (EAT)", draft-		Attestation Token (EAT)", Work in Progress, Internet-
	ietf-rats-eat-10 (work in progress), June 2021.		Draft, draft-ietf-rats-eat-11, 24 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-rats-eat-
			11.txt>.
	[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-14		of Things (SUIT) Manifest", Work in Progress, Internet-
	(work in progress), July 2021.		Draft, draft-ietf-suit-manifest-14, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-suit-manifest-
			14.txt>.
	[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", Work in
	moran-suit-report-01 (work in progress), February 2021.		Progress, Internet-Draft, draft-moran-suit-report-01, 22
			February 2021, <https://www.ietf.org/archive/id/draft-
			moran-suit-report-01.txt>.
	[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>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <https://www.rfc-editor.org/info/rfc3629>.		2003, <https://www.rfc-editor.org/info/rfc3629>.
	[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network		[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
	Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,		Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
	<https://www.rfc-editor.org/info/rfc5198>.		<https://www.rfc-editor.org/info/rfc5198>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
	Galperin, S., and C. Adams, "X.509 Internet Public Key
	Infrastructure Online Certificate Status Protocol - OCSP",
	RFC 6960, DOI 10.17487/RFC6960, June 2013,
	<https://www.rfc-editor.org/info/rfc6960>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	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>.
	11.2. Informative References		11.2. Informative References
	[I-D.birkholz-rats-suit-claims]		[I-D.birkholz-rats-suit-claims]
	Birkholz, H. and B. Moran, "Trustworthiness Vectors for		Birkholz, H. and B. Moran, "Trustworthiness Vectors for
	the Software Updates of Internet of Things (SUIT) Workflow		the Software Updates of Internet of Things (SUIT) Workflow
	Model", draft-birkholz-rats-suit-claims-02 (work in		Model", Work in Progress, Internet-Draft, draft-birkholz-
	progress), July 2021.		rats-suit-claims-02, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-birkholz-rats-suit-
			claims-02.txt>.
	[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-15 (work in		Architecture", Work in Progress, Internet-Draft, draft-
	progress), July 2021.		ietf-teep-architecture-15, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-teep-
			architecture-15.txt>.
	[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 28, line 33 ¶		skipping to change at page 31, line 4 ¶
	; message type numbers, uint (0..23)		; 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-update = 3		TEEP-TYPE-update = 3
	TEEP-TYPE-teep-success = 5		TEEP-TYPE-teep-success = 5
	TEEP-TYPE-teep-error = 6		TEEP-TYPE-teep-error = 6
	version = .within uint .size 4		version = .within uint .size 4
	ext-info = .within uint .size 4		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
	$data-item-requested /= suit-commands
	query-request = [		query-request = [
	type: TEEP-TYPE-query-request,		type: TEEP-TYPE-query-request,
	options: {		options: {
	? token => bstr .size (8..64),		? token => bstr .size (8..64),
	? supported-cipher-suites => [ + suite ],		? supported-cipher-suites => [ + suite ],
	? supported-freshness-mechanisms => [ + freshness-mechanism ],		? supported-freshness-mechanisms => [ + freshness-mechanism ],
	? challenge => bstr .size (8..512),		? challenge => bstr .size (8..512),
	? versions => [ + version ],		? versions => [ + version ],
	? ocsp-data => bstr,
	* $$query-request-extensions		* $$query-request-extensions
	* $$teep-option-extensions		* $$teep-option-extensions
	},		},
	data-item-requested: data-item-requested		data-item-requested: data-item-requested
	]		]
	; ciphersuites		; ciphersuites
	suite = $TEEP-suite .within uint .size 4		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
	skipping to change at page 30, line 52 ¶		skipping to change at page 33, line 19 ¶
	? 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)		err-code: uint (0..23)
	]		]
	; The err-code parameter, uint (0..23)		; The err-code parameter, uint (0..23)
	ERR_PERMANENT_ERROR = 1		ERR_PERMANENT_ERROR = 1
	ERR_UNSUPPORTED_EXTENSION = 2		ERR_UNSUPPORTED_EXTENSION = 2
			ERR_UNSUPPORTED_FRESHNESS_MECHANISMS = 3
	ERR_UNSUPPORTED_MSG_VERSION = 4		ERR_UNSUPPORTED_MSG_VERSION = 4
	ERR_UNSUPPORTED_CRYPTO_ALG = 5		ERR_UNSUPPORTED_CIPHER_SUITES = 5
	ERR_BAD_CERTIFICATE = 6		ERR_BAD_CERTIFICATE = 6
	ERR_CERTIFICATE_EXPIRED = 9		ERR_CERTIFICATE_EXPIRED = 9
	ERR_TEMPORARY_ERROR = 10		ERR_TEMPORARY_ERROR = 10
	ERR_MANIFEST_PROCESSING_FAILED = 17		ERR_MANIFEST_PROCESSING_FAILED = 17
	; labels of mapkey for teep message parameters, uint (0..23)		; 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
	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		token = 20
			supported-freshness-mechanisms = 21
	D. Examples of Diagnostic Notation and Binary Representation		D. Examples of Diagnostic Notation and Binary Representation
	D.1. Some assumptions in examples		This section includes some examples with the following assumptions:
	o OCSP stapling data = h'010203'
	o TEEP Device will have two TCs with the following SUIT Component		* TEEP Device will have two TCs with the following SUIT Component
	Identifiers:		Identifiers:
	* [ 0x000102030405060708090a0b0c0d0e0f ]		- [ 0x000102030405060708090a0b0c0d0e0f ]
	* [ 0x100102030405060708090a0b0c0d0e0f ]		- [ 0x100102030405060708090a0b0c0d0e0f ]
	o SUIT manifest-list is set empty only for example purposes		* SUIT manifest-list is set empty only for example purposes (see
			Appendix E for actual manifest examples)
	D.2. QueryRequest Message		D.1. QueryRequest Message
	D.2.1. CBOR Diagnostic Notation
			D.1.1. CBOR Diagnostic Notation
	/ query-request = /		/ query-request = /
	[		[
	1, / type : TEEP-TYPE-query-request = 1 (uint (0..23)) /		1, / type : TEEP-TYPE-query-request = 1 (uint (0..23)) /
	/ options : /		/ options : /
	{		{
	20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,		20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
	/ token = 20 (mapkey) :		/ token = 20 (mapkey) :
	h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),		h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
	generated by TAM /		generated by TAM /
	1 : [ 1 ], / supported-cipher-suites = 1 (mapkey) :		1 : [ 1 ], / supported-cipher-suites = 1 (mapkey) :
	TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =		TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =
	[ 1 ] (array of .within uint .size 4) /		[ 1 ] (array of .within uint .size 4) /
	3 : [ 0 ], / version = 3 (mapkey) :		3 : [ 0 ] / version = 3 (mapkey) :
	[ 0 ] (array of .within uint .size 4) /		[ 0 ] (array of .within uint .size 4) /
	4 : h'010203' / ocsp-data = 4 (mapkey) : 0x010203 (bstr) /
	},		},
	3 / data-item-requested :		3 / data-item-requested :
	attestation | trusted-components = 3 (.within uint .size 8) /		attestation | trusted-components = 3 (.within uint .size 8) /
	]		]
	D.2.2. CBOR Binary Representation		D.1.2. CBOR Binary Representation
	83 # array(3)		83 # array(3)
	01 # unsigned(1) uint (0..23)		01 # unsigned(1) uint (0..23)
	A4 # map(4)		A4 # map(4)
	14 # unsigned(20) uint (0..23)		14 # unsigned(20) uint (0..23)
	4F # bytes(16) (8..64)		4F # bytes(16) (8..64)
	A0A1A2A3A4A5A6A7A8A9AAABACADAEAF		A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
	01 # unsigned(1) uint (0..23)		01 # unsigned(1) uint (0..23)
	81 # array(1)		81 # array(1)
	01 # unsigned(1) within uint .size 4		01 # unsigned(1) within uint .size 4
	03 # unsigned(3) uint (0..23)		03 # unsigned(3) uint (0..23)
	81 # array(1)		81 # array(1)
	00 # unsigned(0) within uint .size 4		00 # unsigned(0) within uint .size 4
	04 # unsigned(4) uint (0..23)		04 # unsigned(4) uint (0..23)
	43 # bytes(3)		43 # bytes(3)
	010203 # "\x01\x02\x03"		010203 # "\x01\x02\x03"
	03 # unsigned(3) .within uint .size 8		03 # unsigned(3) .within uint .size 8
	D.3. Entity Attestation Token		D.2. Entity Attestation Token
	This is shown below in CBOR diagnostic form. Only the payload signed		This is shown below in CBOR diagnostic form. Only the payload signed
	by COSE is shown.		by COSE is shown.
	D.3.1. CBOR Diagnostic Notation		D.2.1. CBOR Diagnostic Notation
	/ eat-claim-set = /		/ eat-claim-set = /
	{		{
	/ issuer / 1: "joe",		/ issuer / 1: "joe",
	/ timestamp (iat) / 6: 1(1526542894)		/ timestamp (iat) / 6: 1(1526542894)
	/ nonce / 10: h'948f8860d13a463e8e',		/ nonce / 10: h'948f8860d13a463e8e',
	/ secure-boot / 15: true,		/ secure-boot / 15: true,
	/ debug-status / 16: 3, / disabled-permanently /		/ debug-status / 16: 3, / disabled-permanently /
	/ security-level / <TBD>: 3, / secure-restricted /		/ security-level / 14: 3, / secure-restricted /
	/ device-identifier / <TBD>: h'e99600dd921649798b013e9752dcf0c5',		/ device-identifier / <TBD>: h'e99600dd921649798b013e9752dcf0c5',
	/ vendor-identifier / <TBD>: h'2b03879b33434a7ca682b8af84c19fd4',		/ vendor-identifier / <TBD>: h'2b03879b33434a7ca682b8af84c19fd4',
	/ class-identifier / <TBD>: h'9714a5796bd245a3a4ab4f977cb8487f',		/ class-identifier / <TBD>: h'9714a5796bd245a3a4ab4f977cb8487f',
	/ chip-version-scheme / <TBD>: "MyTEE v1.0",		/ chip-version / 26: [ "MyTEE", 1 ],
	/ component-identifier / <TBD>: h'60822887d35e43d5b603d18bcaa3f08d',		/ component-identifier / <TBD>: h'60822887d35e43d5b603d18bcaa3f08d',
	/ version / <TBD>: "v0.1"		/ version / <TBD>: "v0.1"
	}		}
	D.4. QueryResponse Message		D.3. QueryResponse Message
	D.4.1. CBOR Diagnostic Notation		D.3.1. CBOR Diagnostic Notation
	/ query-response = /		/ query-response = /
	[		[
	2, / type : TEEP-TYPE-query-response = 2 (uint (0..23)) /		2, / type : TEEP-TYPE-query-response = 2 (uint (0..23)) /
	/ options : /		/ options : /
	{		{
	20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,		20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
	/ token = 20 (mapkey) :		/ token = 20 (mapkey) :
	h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),		h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
	given from TAM's QueryRequest message /		given from TAM's QueryRequest message /
	5 : 1, / selected-cipher-suite = 5 (mapkey) :		5 : 1, / selected-cipher-suite = 5 (mapkey) :
	skipping to change at page 34, line 35 ¶		skipping to change at page 36, line 35 ¶
	},		},
	{		{
	16 : [ 0x100102030405060708090a0b0c0d0e0f ] / component-id =		16 : [ 0x100102030405060708090a0b0c0d0e0f ] / component-id =
	16 (mapkey) : [ h'100102030405060708090a0b0c0d0e0f' ]		16 (mapkey) : [ h'100102030405060708090a0b0c0d0e0f' ]
	(SUIT_Component_Identifier = [* bstr]) /		(SUIT_Component_Identifier = [* bstr]) /
	}		}
	]		]
	}		}
	]		]
	D.4.2. CBOR Binary Representation		D.3.2. CBOR Binary Representation
	82 # array(2)		82 # array(2)
	02 # unsigned(2) uint (0..23)		02 # unsigned(2) uint (0..23)
	A5 # map(5)		A5 # map(5)
	14 # unsigned(20) uint (0..23)		14 # unsigned(20) uint (0..23)
	4F # bytes(16) (8..64)		4F # bytes(16) (8..64)
	A0A1A2A3A4A5A6A7A8A9AAABACADAEAF		A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
	05 # unsigned(5) uint (0..23)		05 # unsigned(5) uint (0..23)
	01 # unsigned(1) .within uint .size 4		01 # unsigned(1) .within uint .size 4
	06 # unsigned(6) uint (0..23)		06 # unsigned(6) uint (0..23)
	00 # unsigned(0) .within uint .size 4		00 # unsigned(0) .within uint .size 4
	skipping to change at page 35, line 25 ¶		skipping to change at page 37, line 25 ¶
	... # Entity Attestation Token		... # Entity Attestation Token
	08 # unsigned(8) uint (0..23)		08 # unsigned(8) uint (0..23)
	82 # array(2)		82 # array(2)
	81 # array(1)		81 # array(1)
	4F # bytes(16)		4F # bytes(16)
	000102030405060708090A0B0C0D0E0F		000102030405060708090A0B0C0D0E0F
	81 # array(1)		81 # array(1)
	4F # bytes(16)		4F # bytes(16)
	100102030405060708090A0B0C0D0E0F		100102030405060708090A0B0C0D0E0F
	D.5. Update Message		D.4. Update Message
	D.5.1. CBOR Diagnostic Notation		D.4.1. CBOR Diagnostic Notation
	/ update = /		/ update = /
	[		[
	3, / type : TEEP-TYPE-update = 3 (uint (0..23)) /		3, / type : TEEP-TYPE-update = 3 (uint (0..23)) /
	/ options : /		/ options : /
	{		{
	20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,		20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
	/ token = 20 (mapkey) :		/ token = 20 (mapkey) :
	h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),		h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
	generated by TAM /		generated by TAM /
	10 : [ ] / manifest-list = 10 (mapkey) :		10 : [ ] / manifest-list = 10 (mapkey) :
	[ ] (array of bstr wrapped SUIT_Envelope(any)) /		[ ] (array of bstr wrapped SUIT_Envelope(any)) /
	/ empty, example purpose only /		/ empty, example purpose only /
	}		}
	]		]
	D.5.2. CBOR Binary Representation		D.4.2. CBOR Binary Representation
	82 # array(2)		82 # array(2)
	03 # unsigned(3) uint (0..23)		03 # unsigned(3) uint (0..23)
	A3 # map(3)		A3 # map(3)
	14 # unsigned(20) uint (0..23)		14 # unsigned(20) uint (0..23)
	4F # bytes(16) (8..64)		4F # bytes(16) (8..64)
	A0A1A2A3A4A5A6A7A8A9AAABACADAEAF		A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
	0A # unsigned(10) uint (0..23)		0A # unsigned(10) uint (0..23)
	80 # array(0)		80 # array(0)
	D.6. Success Message		D.5. Success Message
	D.6.1. CBOR Diagnostic Notation		D.5.1. CBOR Diagnostic Notation
	/ teep-success = /		/ teep-success = /
	[		[
	5, / type : TEEP-TYPE-teep-success = 5 (uint (0..23)) /		5, / type : TEEP-TYPE-teep-success = 5 (uint (0..23)) /
	/ options : /		/ options : /
	{		{
	20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,		20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
	/ token = 20 (mapkey) :		/ token = 20 (mapkey) :
	h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),		h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
	given from TAM's Update message /		given from TAM's Update message /
	}		}
	]		]
	D.6.2. CBOR Binary Representation		D.5.2. CBOR Binary Representation
	82 # array(2)		82 # array(2)
	05 # unsigned(5) uint (0..23)		05 # unsigned(5) uint (0..23)
	A1 # map(1)		A1 # map(1)
	14 # unsigned(20) uint (0..23)		14 # unsigned(20) uint (0..23)
	4F # bytes(16) (8..64)		4F # bytes(16) (8..64)
	A0A1A2A3A4A5A6A7A8A9AAABACADAEAF		A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
	D.7. Error Message		D.6. Error Message
	D.7.1. CBOR Diagnostic Notation		D.6.1. CBOR Diagnostic Notation
	/ teep-error = /		/ teep-error = /
	[		[
	6, / type : TEEP-TYPE-teep-error = 6 (uint (0..23)) /		6, / type : TEEP-TYPE-teep-error = 6 (uint (0..23)) /
	/ options : /		/ options : /
	{		{
	20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,		20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf,
	/ token = 20 (mapkey) :		/ token = 20 (mapkey) :
	h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),		h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)),
	given from TAM's Update message /		given from TAM's Update message /
	12 : "disk-full" / err-msg = 12 (mapkey) :		12 : "disk-full" / err-msg = 12 (mapkey) :
	"disk-full" (text .size (1..128)) /		"disk-full" (text .size (1..128)) /
	},		},
	17, / err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint (0..23)) /		17, / err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint (0..23)) /
	]		]
	D.7.2. CBOR binary Representation		D.6.2. CBOR binary Representation
	83 # array(3)		83 # array(3)
	06 # unsigned(6) uint (0..23)		06 # unsigned(6) uint (0..23)
	A2 # map(2)		A2 # map(2)
	14 # unsigned(20) uint (0..23)		14 # unsigned(20) uint (0..23)
	4F # bytes(16) (8..64)		4F # bytes(16) (8..64)
	A0A1A2A3A4A5A6A7A8A9AAABACADAEAF		A0A1A2A3A4A5A6A7A8A9AAABACADAEAF
	0C # unsigned(12) uint (0..23)		0C # unsigned(12) uint (0..23)
	69 # text(9) (1..128)		69 # text(9) (1..128)
	6469736B2D66756C6C # "disk-full"		6469736B2D66756C6C # "disk-full"
	11 # unsigned(17) uint (0..23)		11 # unsigned(17) uint (0..23)
			E. Examples of SUIT Manifests
			This section shows some examples of SUIT manifests for a case where
			the TEE will use a Trusted Application (TA) for OP-TEE on Arm
			TrustZone, storing the TA in Replay Protected Memory Block (RPMB)
			secure storage in a file named "edd94cd8-9d9c-4cc8-9216-
			b3ad5a2d5b8a.ta".
			The TA developer places personalization data for the device on an
			HTTPS server and puts the URI in the TA manifest. The
			personalization data will also be stored in RPMB secure storage in a
			file named "config.json".
			E.1. Install a Trusted Component
			This sample manifest installs a Trusted Component that depends on
			personalization data resolved separately.
			TA Manifest:
			107({
			/ authentication-wrapper / 2:<<[
			digest: <<[
			/ algorithm-id / -16 / "sha256" /,
			/ digest-bytes / h'd6c1fc7200483092e2db59d4907f9b15'
			h'05cb3af2795cf78f7ae3d88166fdf743'
			]>>,
			signature: <<18([
			/ protected / <<{
			/ alg / 1:-7 / "ES256" /,
			}>>,
			/ unprotected / {},
			/ payload / F6 / nil /,
			/ signature / h'd11a2dd9610fb62a707335f584079225'
			h'709f96e8117e7eeed98a2f207d05c8ec'
			h'fba1755208f6abea977b8a6efe3bc2ca'
			h'3215e1193be201467d052b42db6b7287'
			])>>
			]>>,
			/ manifest / 3:<<{
			/ manifest-version / 1:1,
			/ manifest-sequence-number / 2:3,
			/ common / 3:<<{
			/ components / 2:[
			["OP-TEE","RPMB","edd94cd8-9d9c-4cc8-9216- b3ad5a2d5b8a","ta"]
			],
			/ common-sequence / 4:<<[
			/ directive-override-parameters / 20,{
			/ vendor-id / 1:h'c0ddd5f15243566087db4f5b0aa26c2f',
			/ class-id / 2:h'db42f7093d8c55baa8c5265fc5820f4e',
			/ image-digest / 3:<<[
			/ algorithm-id / -16 / "sha256" /,
			/ digest-bytes / h'00112233445566778899aabbccddeeff'
			h'0123456789abcdeffedcba9876543210'
			]>>,
			/ image-size / 14:76778,
			},
			/ condition-vendor-identifier / 1,15,
			/ condition-class-identifier / 2,15
			]>>,
			}>>,
			/ install / 9:<<[
			/ directive-set-parameters / 19,{
			/ uri / 21:
			'https://teep.example/edd94cd8-9d9c-4cc8-9216-b3ad5a2d5b8a.ta',
			} ,
			/ directive-fetch / 21,2,
			/ condition-image-match / 3,15
			]>>,
			/ validate / 10:<<[
			/ condition-image-match / 3,15
			]>>,
			/ run / 12:<<[
			/ directive-run / 23,2
			]>>,
			/ text / 13:<<{
			[
			h'4f502d544545',
			h'44f301',
			h'edd94cd89d9c4cc89216b3ad5a2d5b8a',
			h'7461'
			]:{
			/ model-name / 2: 'OP-TEE on TF-A on TrustZone',
			/ vendor-domain / 3:'teep.example'
			}
			}>>
			}>>
			})
			Personalization Data Manifest:
			107({
			2:<<[
			digest: <<[
			/ algorithm-id / -16 / "sha256" /,
			/ digest-bytes / h'a7fd6593eac32eb4be578278e6540c5c'
			h'09cfd7d4d234973054833b2b93030609'
			]>>
			]>>,
			/ manifest / 3:<<{
			/ manifest-version / 1:1,
			/ manifest-sequence-number / 2:3,
			/ dependencies / 1:[
			{
			/ dependency-digest / 1:[
			/ algorithm-id / -16 / "sha256" /,
			/ digest-bytes / h'd6c1fc7200483092e2db59d4907f9b15'
			h'05cb3af2795cf78f7ae3d88166fdf743'
			]
			}
			],
			/ components / 2:[
			["OP-TEE","RPMB","config.json"]
			],
			/ common-sequence / 4:<<[
			/ directive-set-component-index / 12,0,
			/ directive-override-parameters / 20,{
			/ vendor-id / 1:h'ec41787224345ae580003de697ff8d43'
			/ ec417872-2434-5ae5-8000-3de697ff8d43 /,
			/ class-id / 2:h'eb1701b48be85709aca0adf89f056a64'
			/ eb1701b4-8be8-5709-aca0-adf89f056a64 /,
			/ image-digest / 3:<<[
			/ algorithm-id / -16 / "sha256" /,
			/ digest-bytes / h'aaabcccdeeef00012223444566678889'
			h'abbbcdddefff01112333455567778999'
			]>>
			},
			/ condition-vendor-identifier / 1,15,
			/ condition-class-identifier / 2,15
			]>>,
			/ dependency-resolution / 7:<<[
			/ directive-set-dependency-index / 13,0,
			/ directive-set-parameters / 19,{
			/ uri / 21:'tam.teep.example/'
			'edd94cd8-9d9c-4cc8-'
			'9216-b3ad5a2d5b8a.suit',
			},
			/ directive-fetch / 21,2,
			/ condition-image-match / 3,15
			]>>,
			/ install / 9:<<[
			/ directive-set-component-index / 12,0,
			/ directive-set-parameters / 19,{
			/ uri / 21:
			'http://tam.teep.example/config.json',
			},
			/ directive-set-dependency-index / 13,0,
			/ directive-process-dependency / 18,0,
			/ directive-set-component-index / 12,0,
			/ directive-fetch / 21,2,
			/ condition-image-match / 3,15
			]>>,
			/ validate / 10:<<[
			/ directive-set-component-index / 12,0,
			/ condition-image-match / 3,15,
			/ directive-set-dependency-index / 13,0,
			/ directive-process-dependency / 18,0
			]>>,
			/ run / 12:<<[
			/ directive-set-dependency-index / 13,0,
			/ directive-process-dependency / 18,0
			]>>,
			/ text / 13:<<{
			[h'4f502d544545', h'44f301',
			h'636f6e6669672e6a736f6e']:{
			/ model-name / 2: 'Personalised OP-TEE on TF-A on TrustZone',
			/ vendor-domain / 3:'tam.teep.example',
			},
			[
			h'4f502d544545',
			h'44f301',
			h'edd94cd89d9c4cc89216b3ad5a2d5b8a',
			h'7461'
			]:{
			/ model-name / 2:'OP-TEE on TF-A on TrustZone',
			/ vendor-domain / 3:'teep.example'
			}
			}>>
			}>>
			})
			E.2. Delete a Trusted Component
			This sample manifest removes a Trusted Component and its dependency.
			107({
			/ authentication-wrapper / 2:<<[
			digest: <<[
			/ algorithm-id / -16 / "sha256" /,
			/ digest-bytes /
			h'a6c4590ac53043a98e8c4106e1e31b305516d7cf0a655eddfac6d45c810e036a'
			]>>,
			signature: <<18([
			/ protected / <<{
			/ alg / 1:-7 / "ES256" /,
			}>>,
			/ unprotected / {
			},
			/ payload / F6 / nil /,
			/ signature / h'd11a2dd9610fb62a707335f58407922570
			9f96e8117e7eeed98a2f207d05c8ecfba1755208f6abea977b8a6efe3bc2ca3215e119
			3be201467d052b42db6b7287'
			])>>
			]
			]>>,
			/ manifest / 3:<<{
			/ manifest-version / 1:1,
			/ manifest-sequence-number / 2:0,
			/ common / 3:<<{
			/ components / 2:[
			[h'00']
			],
			/ common-sequence / 4:<<[
			/ directive-override-parameters / 20,{
			/ vendor-id /
			1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf-
			be9d-e663e4d41ffe /,
			/ class-id /
			2:h'1492af1425695e48bf429b2d51f2ab45' /
			1492af14-2569-5e48-bf42-9b2d51f2ab45 /,
			/ image-digest / 3:<<[
			/ algorithm-id / -16 / "sha256" /,
			/ digest-bytes /
			h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210'
			]>>,
			/ image-size / 14:34768,
			} ,
			/ condition-vendor-identifier / 1,15 ,
			/ condition-class-identifier / 2,15
			]>>,
			}>>,
			/ validate / 10:<<[
			/ condition-image-match / 3,15
			]>>,
			/ run / 12:<<[
			/ directive-run / 23,2
			]>>,
			}>>,
			})
			Total size of Envelope without COSE authentication object: 161
			Envelope:
			d86ba2025827815824822f5820a6c4590ac53043a98e8c4106e1e31b3055
			16d7cf0a655eddfac6d45c810e036a035871a50101020003585fa2028181
			41000458568614a40150fa6b4a53d5ad5fdfbe9de663e4d41ffe02501492
			af1425695e48bf429b2d51f2ab45035824822f5820001122334455667788
			99aabbccddeeff0123456789abcdeffedcba98765432100e1987d0010f02
			0f0a4382030f0c43821702
			Total size of Envelope with COSE authentication object: 237
			Envelope with COSE authentication object:
			d86ba2025873825824822f5820a6c4590ac53043a98e8c4106e1e31b3055
			16d7cf0a655eddfac6d45c810e036a584ad28443a10126a0f65840d11a2d
			d9610fb62a707335f584079225709f96e8117e7eeed98a2f207d05c8ecfb
			a1755208f6abea977b8a6efe3bc2ca3215e1193be201467d052b42db6b72
			87035871a50101020003585fa202818141000458568614a40150fa6b4a53
			d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45
			035824822f582000112233445566778899aabbccddeeff0123456789abcd
			effedcba98765432100e1987d0010f020f0a4382030f0c43821702
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Arm Ltd.		Arm Ltd.
	Absam, Tirol 6067		6067 Absam
	Austria		Austria
	Email: hannes.tschofenig@arm.com		Email: hannes.tschofenig@arm.com
	Mingliang Pei		Mingliang Pei
	Broadcom		Broadcom
	350 Ellis St		350 Ellis St
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		United States of America
	Email: mingliang.pei@broadcom.com		Email: mingliang.pei@broadcom.com
	David Wheeler		David Wheeler
	Amazon		Amazon
	US		United States of America
	Email: davewhee@amazon.com		Email: davewhee@amazon.com
	Dave Thaler		Dave Thaler
	Microsoft		Microsoft
	US		United States of America
	Email: dthaler@microsoft.com		Email: dthaler@microsoft.com
	Akira Tsukamoto		Akira Tsukamoto
	AIST		AIST
	JP		Japan
	Email: akira.tsukamoto@aist.go.jp		Email: akira.tsukamoto@aist.go.jp
End of changes. 123 change blocks.
	241 lines changed or deleted		567 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/