Diff: draft-tschofenig-teep-protocol-00.txt - draft-tschofenig-teep-protocol-01.txt

	< draft-tschofenig-teep-protocol-00.txt	draft-tschofenig-teep-protocol-01.txt >


	TEEP M. Pei	TEEP H. Tschofenig
	Internet-Draft Symantec	Internet-Draft Arm Ltd.
	Intended status: Standards Track H. Tschofenig	Intended status: Standards Track M. Pei
	Expires: May 7, 2020 Arm Ltd.	Expires: May 20, 2020 Broadcom
	D. Wheeler	D. Wheeler
	Intel	Intel

	November 4, 2019	D. Thaler
		Microsoft
		November 17, 2019


	Trusted Execution Environment Provisioning (TEEP) Protocol	Trusted Execution Environment Provisioning Protocol (teep-p)
	draft-tschofenig-teep-protocol-00	draft-tschofenig-teep-protocol-01

	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). Due to its function it is called	Execution Environment (TEE). This specification defines an
	"Trusted Execution Environment Provisioning (TEEP) Protocol", which	interoperable protocol for managing the lifecycle of TAs.
	provides interoperability for mantaining the lifecycle of TAs.
		The protocol name is teep-p, pronounced teepee. This conjures an
		image of a wedge-shaped protective covering for one's belongings,
		which sort of matches the intent of this protocol.

	Status of This Memo	Status of This Memo

	This Internet-Draft is submitted in full conformance with the	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.	provisions of BCP 78 and BCP 79.

	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 May 7, 2020.	This Internet-Draft will expire on May 20, 2020.

	Copyright Notice	Copyright Notice

	Copyright (c) 2019 IETF Trust and the persons identified as the	Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of	(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2

	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 3	3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 3

	4. Detailed Messages Specification . . . . . . . . . . . . . . . 4	4. Detailed Messages Specification . . . . . . . . . . . . . . . 5
	5. Security Consideration . . . . . . . . . . . . . . . . . . . 11	4.1. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13	4.2. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15	4.3. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 15	4.4. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 17	4.5. Success . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17	4.6. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17	5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18	6. Security Consideration . . . . . . . . . . . . . . . . . . . 13
		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
		7.1. Media Type Registration . . . . . . . . . . . . . . . . . 14
		7.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 16
		7.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 17
		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
		8.1. Normative References . . . . . . . . . . . . . . . . . . 17
		8.2. Informative References . . . . . . . . . . . . . . . . . 18
		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
		Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 19
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20

	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 an TEE ecosystem, different device vendors may use different	In an TEE ecosystem, different device vendors may use different
	operating systems in the REE and may use different types of TEEs.	operating systems in the REE and may use different types of TEEs.
	When application providers or device administrators use Trusted	When application providers or device administrators use Trusted
	Application Managers (TAMs) to install, update, and delete Trusted	Application Managers (TAMs) to install, update, and delete Trusted

	skipping to change at page 3, line 20 ¶	skipping to change at page 3, line 36 ¶
	The TEEP protocol consists of a couple of messages exchanged between	The TEEP protocol consists of a couple of messages exchanged between
	a TAM and a TEEP Agent via a TEEP Broker. The messages are encoded	a TAM and a TEEP Agent via a TEEP Broker. The messages are encoded
	either in JSON or CBOR and designed to provide end-to-end security.	either in JSON or CBOR and designed to provide end-to-end security.
	TEEP protocol messages are signed and/or encrypted by the endpoints,	TEEP protocol messages are signed and/or encrypted by the endpoints,
	i.e., the TAM and the TEEP Agent, but trusted applications may as	i.e., the TAM and the TEEP Agent, but trusted applications may as
	well be encrypted and signed by the service provider. The TEEP	well be encrypted and signed by the service provider. The TEEP
	protocol not only re-use JSON and CBOR but also the respective	protocol not only re-use JSON and CBOR but also the respective
	security wrappers, namely JOSE (JWS [RFC7515] and JWE [RFC7516], to	security wrappers, namely JOSE (JWS [RFC7515] and JWE [RFC7516], to
	be more specific) and COSE [RFC8152]. Furthermore, for attestation	be more specific) and COSE [RFC8152]. Furthermore, for attestation
	the Entity Attestation Token (EAT) [I-D.ietf-rats-eat] and for	the Entity Attestation Token (EAT) [I-D.ietf-rats-eat] and for

	software updates the SUIT manifest format [I-D.ietf-suit-manifest] is	software updates the SUIT manifest format [I-D.ietf-suit-manifest]
	re-used.	are re-used.

	This specification defines six messages.	This specification defines six 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 TAs, and provide information	report attestation information, list all TAs, and provide information
	about supported algorithms and extensions in a QueryResponse message.	about supported algorithms and extensions in a QueryResponse message.
	An error message is returned if the request could not be processed.	An error message is returned if the request could not be processed.
	A TAM will process the QueryResponse message and determine whether	A TAM will process the QueryResponse message and determine whether
	subsequent message exchanges to install, update, or delete trusted	subsequent message exchanges to install, update, or delete trusted

	skipping to change at page 5, line 27 ¶	skipping to change at page 5, line 32 ¶
	teep-message = 2	teep-message = 2

	Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged /	Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged /
	COSE_Sign_Tagged /	COSE_Sign_Tagged /
	COSE_Mac0_Tagged /	COSE_Mac0_Tagged /
	COSE_Sign1_Tagged)]	COSE_Sign1_Tagged)]

	A future version of this specification will also describe the	A future version of this specification will also describe the
	security wrapper for JSON (in CDDL format).	security wrapper for JSON (in CDDL format).


		4.1. QueryRequest
	suite = int	suite = int

	version = int	version = int

	data_items = (	data_items = (
	attestation: 1,	attestation: 1,

	ta: 2,	trusted_apps: 2,
	ext: 3	extensions: 3,
		suit_commands: 4
	)	)

	QueryRequest = (	QueryRequest = (
	TYPE : int,	TYPE : int,
	TOKEN : bstr,	TOKEN : bstr,
	REQUEST : [+data_items],	REQUEST : [+data_items],
	? CIPHER_SUITE : [+suite],	? CIPHER_SUITE : [+suite],
	? NONCE : bstr,	? NONCE : bstr,
	? VERSION : [+version],	? VERSION : [+version],
	? OCSP_DATA : bstr,	? OCSP_DATA : bstr,

	skipping to change at page 6, line 12 ¶	skipping to change at page 6, line 39 ¶
	TYPE TYPE = 1 corresponds to a QueryRequest message sent from the	TYPE TYPE = 1 corresponds to a QueryRequest message sent from the
	TAM to the TEEP Agent.	TAM to the TEEP Agent.

	TOKEN The value in the TOKEN field is used to match requests to	TOKEN The value in the TOKEN field is used to match requests to
	responses.	responses.

	REQUEST The REQUEST field indicates what information the TAM	REQUEST The REQUEST field indicates what information the TAM
	requests from the TEEP Agent in form of a list of integer values.	requests from the TEEP Agent in form of a list of integer values.
	Each integer value corresponds to an IANA registered information	Each integer value corresponds to an IANA registered information
	element. This specification defines the initial set of	element. This specification defines the initial set of

	information elements. With 'attestation' (1) the TAM requests the	information elements:
	TEEP Agent to return an EAT entity attestation token in the
	response, with 'ta' (2) the TAM wants to query the TEEP Agent for	attestation (1) With this value the TAM requests the TEEP Agent
	all installed TAs, and with 'ext' (3) the TAM wants to query the	to return an entity attestation token (EAT) in the response.
	TEEP Agent for supported extensions. Further values may be added
	in the future via IANA registration.	trusted_apps (2) With this value the TAM queries the TEEP Agent
		for all installed TAs.

		extensions (3) With this value the TAM queries the TEEP Agent for
		supported capabilities and extensions, which allows a TAM to
		discover the capabilities of a TEEP Agent implementation.

		suit_commands (4) 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.

	CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s)	CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s)

	supported by the TAM.	supported by the TAM. Details about the ciphersuite encoding can
		be found in Section 5.

	NONCE NONCE is an optional field used for ensuring the refreshness	NONCE NONCE is an optional field used for ensuring the refreshness
	of the Entity Attestation Token (EAT) contained in the response.	of the Entity Attestation Token (EAT) contained in the response.

	VERSION The VERSION field lists the version(s) supported by the TAM.	VERSION The VERSION field lists the version(s) supported by the TAM.
	For this version of the specification this field can be omitted.	For this version of the specification this field can be omitted.

	OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data	OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data
	respectively for the TAM certificate and each of the CA	respectively for the TAM certificate and each of the CA
	certificates up to the root certificate. The TAM provides OCSP	certificates up to the root certificate. The TAM provides OCSP
	data so that the TEEP Agent can validate the status of the TAM	data so that the TEEP Agent can validate the status of the TAM
	certificate chain without making its own external OCSP service	certificate chain without making its own external OCSP service

	call.	call. OCSP data MUST be conveyed as a DER-encoded OCSP response
		(using the ASN.1 type OCSPResponse defined in [RFC2560]). 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.2. QueryResponse
	ta_id = (	ta_id = (
	Vendor_ID = bstr,	Vendor_ID = bstr,
	Class_ID = bstr,	Class_ID = bstr,
	Device_ID = bstr,	Device_ID = bstr,
	* $$extensions	* $$extensions
	)	)

	ext_info = int	ext_info = int

	QueryResponse = (	QueryResponse = (

	skipping to change at page 7, line 36 ¶	skipping to change at page 8, line 35 ¶
	and returned to the TAM. It has the following fields:	and returned to the TAM. It has the following fields:

	TYPE TYPE = 2 corresponds to a QueryResponse message sent from the	TYPE TYPE = 2 corresponds to a QueryResponse message sent from the
	TEEP Agent to the TAM.	TEEP Agent to the TAM.

	TOKEN The value in the TOKEN field is used to match requests to	TOKEN The value in the TOKEN field is used to match requests to
	responses. The value MUST correspond to the value received with	responses. The value MUST correspond to the value received with
	the QueryRequest.	the QueryRequest.

	SELECTED_CIPHER_SUITE The SELECTED_CIPHER_SUITE field indicates the	SELECTED_CIPHER_SUITE The SELECTED_CIPHER_SUITE field indicates the

	selected ciphersuite.	selected ciphersuite. Details about the ciphersuite encoding can
		be found in Section 5.

	SELECTED_VERSION The SELECTED_VERSION field indicates the protocol	SELECTED_VERSION The SELECTED_VERSION field indicates the protocol
	version selected by the TEEP Agent.	version selected by the TEEP Agent.

	EAT The EAT field contains an Entity Attestation Token following the	EAT The EAT field contains an Entity Attestation Token following the
	encoding defined in [I-D.ietf-rats-eat].	encoding defined in [I-D.ietf-rats-eat].

	TA_LIST The TA_LIST field enumerates the trusted applications	TA_LIST The TA_LIST field enumerates the trusted applications
	installed on the device in form of ta_ids, i.e., a vendor id/class	installed on the device in form of ta_ids, i.e., a vendor id/class
	id/device id triple.	id/device id triple.

	EXT_LIST The EXT_LIST field lists the supported extensions. This	EXT_LIST The EXT_LIST field lists the supported extensions. This
	document does not define any extensions.	document does not define any extensions.


		4.3. TrustedAppInstall

	TrustedAppInstall = (	TrustedAppInstall = (
	TYPE : int,	TYPE : int,
	TOKEN : bstr,	TOKEN : bstr,

	? TA : [+SUIT_Outer_Wrapper],	? MANIFEST_LIST : [+ SUIT_Outer_Wrapper],
	* $$extensions	* $$extensions
	)	)

	The TrustedAppInstall message is MACed and encrypted by the TAM and	The TrustedAppInstall message is MACed and encrypted by the TAM and
	has the following fields:	has the following fields:

	TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from	TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from
	the TAM to the TEEP Agent. In case of successful processing, an	the TAM to the TEEP Agent. In case of successful processing, an
	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	error, an Error message is returned. Note that the
	TrustedAppInstall message is used for initial TA installation but	TrustedAppInstall message is used for initial TA installation but
	also for TA updates.	also for TA updates.

	TOKEN The value in the TOKEN field is used to match requests to	TOKEN The value in the TOKEN field is used to match requests to
	responses.	responses.


	TA The TA field is used to convey one or multiple SUIT manifests.	TA The MANIFEST_LIST field is used to convey one or multiple SUIT
	The SUIT manifest contains the code for the trusted app but may	manifests. A manifest is a bundle of metadata about the trusted
	also convey personalization data. TA binaries and personalization	app, where to find the code, the devices to which it applies, and
	data is often signed and encrypted by the SP. Other combinations	cryptographic information protecting the manifest. The manifest
	are, however, possible as well. For example, it is also possible	may also convey personalization data. TA binaries and
	for the TAM to sign and encrypt the personalization data and to	personalization data is typically signed and encrypted by the SP.
	let the SP sign and/or encrypt the TA binary.	Other combinations are, however, possible as well. For example,
		it is also possible for the TAM to sign and encrypt the
		personalization data and to let the SP sign and/or encrypt the TA
		binary.

		4.4. TrustedAppDelete

	TrustedAppDelete = (	TrustedAppDelete = (
	TYPE : int,	TYPE : int,
	TOKEN : bstr,	TOKEN : bstr,
	? TA_LIST : [+ta_id],	? TA_LIST : [+ta_id],
	* $$extensions	* $$extensions
	)	)

	The TrustedAppDelete message is MACed and encrypted by the TAM and	The TrustedAppDelete message is MACed and encrypted by the TAM and
	has the following fields:	has the following fields:

	skipping to change at page 9, line 5 ¶	skipping to change at page 10, line 12 ¶
	TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from	TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from
	the TAM to the TEEP Agent. In case of successful processing, an	the TAM to the TEEP Agent. In case of successful processing, an
	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.	error, an Error message is returned.

	TOKEN The value in the TOKEN field is used to match requests to	TOKEN The value in the TOKEN field is used to match requests to
	responses.	responses.

	TA_LIST The TA_LIST field enumerates the TAs to be deleted.	TA_LIST The TA_LIST field enumerates the TAs to be deleted.


		4.5. Success

	Success = (	Success = (
	TYPE : int,	TYPE : int,
	TOKEN : bstr,	TOKEN : bstr,
	? MSG : tstr,	? MSG : tstr,
	* $$extensions	* $$extensions
	)	)

	The Success message is MACed and encrypted by the TEEP Agent and has	The Success message is MACed and encrypted by the TEEP Agent and has
	the following fields:	the following fields:

	TYPE TYPE = 5 corresponds to a Error message sent from the TEEP	TYPE TYPE = 5 corresponds to a Error message sent from the TEEP
	Agent to the TAM.	Agent to the TAM.

	TOKEN The value in the TOKEN field is used to match requests to	TOKEN The value in the TOKEN field is used to match requests to
	responses.	responses.

	MSG The MSG field contains optional diagnostics information encoded	MSG The MSG field contains optional diagnostics information encoded
	in UTF-8 [RFC3629] returned by the TEEP Agent.	in UTF-8 [RFC3629] returned by the TEEP Agent.


		4.6. Error

	Error = (	Error = (
	TYPE : int,	TYPE : int,
	TOKEN : bstr,	TOKEN : bstr,
	ERR_CODE : int,	ERR_CODE : int,
	? ERR_MSG : tstr,	? ERR_MSG : tstr,
	? CIPHER_SUITE : [+suite],	? CIPHER_SUITE : [+suite],
	? VERSION : [+version],	? VERSION : [+version],
	* $$extensions	* $$extensions
	)	)


	skipping to change at page 11, line 29 ¶	skipping to change at page 12, line 42 ¶
	it fails to decompress the TA binary.	it fails to decompress the TA binary.

	ERR_MANIFEST_PROCESSING_FAILED The TEEP Agent returns this error	ERR_MANIFEST_PROCESSING_FAILED The TEEP Agent returns this error
	when manifest processing failures occur that are less specific	when manifest processing failures occur that are less specific
	than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and	than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and
	ERR_TA_DECOMPRESSION_FAILED.	ERR_TA_DECOMPRESSION_FAILED.

	ERR_PD_PROCESSING_FAILED The TEEP Agent returns this error when it	ERR_PD_PROCESSING_FAILED The TEEP Agent returns this error when it
	fails to process the provided personalization data.	fails to process the provided personalization data.


	5. Security Consideration	5. Ciphersuites

		A ciphersuite consists of an AEAD algorithm, a HMAC algorithm, and a
		signature algorithm. Each ciphersuite is identified with an integer
		value, which corresponds to an IANA registered ciphersuite. This
		document specifies two ciphersuites.

		Value \| Ciphersuite
		------+------------------------------------------------
		0 \| AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA
		1 \| AES-CCM-16-64-128, HMAC 256/256, P-256, ES256

		6. Security Consideration

	This section summarizes the security considerations discussed in this	This section summarizes the security considerations discussed in this
	specification:	specification:

	Cryptographic Algorithms This specification relies on the	Cryptographic Algorithms This specification relies on the
	cryptographic algorithms provided by the security wrappers JOSE	cryptographic algorithms provided by the security wrappers JOSE
	and COSE, respectively. A companion document makes algorithm	and COSE, respectively. A companion document makes algorithm
	recommendations but this document is written in an algorithm-	recommendations but this document is written in an algorithm-
	agnostic way. TEEP protocol messages exchanged between the TAM	agnostic way. TEEP protocol messages exchanged between the TAM
	and the TEEP Agent are protected using JWS and JWE (for JSON-	and the TEEP Agent are protected using JWS and JWE (for JSON-

	skipping to change at page 13, line 17 ¶	skipping to change at page 14, line 39 ¶
	available to the TAM.	available to the TAM.

	Compromised TAM The TEEP Agent SHOULD use OCSP information to verify	Compromised TAM The TEEP Agent SHOULD use OCSP information to verify
	the validity of the TAM-provided certificate (as well as the	the validity of the TAM-provided certificate (as well as the
	validity of intermediate CA certificates). The integrity and the	validity of intermediate CA certificates). The integrity and the
	accuracy of the clock within the TEE determines the ability to	accuracy of the clock within the TEE determines the ability to
	determine an expired or revoked certificate since OCSP stapling	determine an expired or revoked certificate since OCSP stapling
	includes signature generation time, certificate validity dates are	includes signature generation time, certificate validity dates are
	compared to the current time.	compared to the current time.


	6. IANA Considerations	7. IANA Considerations


	There are two IANA requests: a media type and list of error codes.	7.1. Media Type Registration


	IANA is requested to assign a media type for application/otrpv2+json.	IANA is requested to assign a media type for application/teep-p+json.

	Type name: application	Type name: application


	Subtype name: teep+json	Subtype name: teep-p+json

	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/json as specified in Section 11 of [RFC7159]	application/json as specified in Section 11 of [RFC7159]

	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/json as specified in [RFC7159]	considerations of application/json as specified in [RFC7159]

	Published specification: This document.	Published specification: This document.

	skipping to change at page 14, line 4 ¶	skipping to change at page 15, line 26 ¶

	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


	IANA is requested to assign a media type for application/teep+cbor.	IANA is requested to assign a media type for application/teep-p+cbor.

	Type name: application	Type name: application


	Subtype name: teep+cbor	Subtype name: teep-p+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.

	skipping to change at page 15, line 4 ¶	skipping to change at page 16, line 28 ¶

	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


		7.2. Error Code Registry

	IANA is also requested to create a new registry for the error codes	IANA is also requested to create a new registry for the error codes
	defined in Section 4.	defined in Section 4.

	Registration requests are evaluated after a three-week review period	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	on the teep-reg-review@ietf.org mailing list, on the advice of one or
	more Designated Experts [RFC8126]. However, to allow for the	more Designated Experts [RFC8126]. However, to allow for the
	allocation of values prior to publication, the Designated Experts may	allocation of values prior to publication, the Designated Experts may
	approve registration once they are satisfied that such a	approve registration once they are satisfied that such a
	specification will be published.	specification will be published.


	skipping to change at page 15, line 38 ¶	skipping to change at page 17, line 17 ¶
	Criteria that should be applied by the Designated Experts includes	Criteria that should be applied by the Designated Experts includes
	determining whether the proposed registration duplicates existing	determining whether the proposed registration duplicates existing
	functionality, whether it is likely to be of general applicability or	functionality, whether it is likely to be of general applicability or
	whether it is useful only for a single extension, and whether the	whether it is useful only for a single extension, and whether the
	registration description is clear.	registration description is clear.

	IANA must only accept registry updates from the Designated Experts	IANA must only accept registry updates from the Designated Experts
	and should direct all requests for registration to the review mailing	and should direct all requests for registration to the review mailing
	list.	list.


	7. References	7.3. Ciphersuite Registry


	7.1. Normative References	IANA is also requested to create a new registry for ciphersuites, as
		defined in Section 5.

		8. References

		8.1. Normative References

	[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-01 (work in progress), July 2019.	ietf-rats-eat-01 (work in progress), July 2019.

	[I-D.ietf-suit-manifest]	[I-D.ietf-suit-manifest]
	Moran, B., Tschofenig, H., and H. Birkholz, "SUIT CBOR	Moran, B., Tschofenig, H., and H. Birkholz, "SUIT CBOR
	manifest serialisation format", draft-ietf-suit-	manifest serialisation format", draft-ietf-suit-
	manifest-01 (work in progress), October 2019.	manifest-01 (work in progress), October 2019.

	[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>.


		[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
		Adams, "X.509 Internet Public Key Infrastructure Online
		Certificate Status Protocol - OCSP", RFC 2560,
		DOI 10.17487/RFC2560, June 1999,
		<https://www.rfc-editor.org/info/rfc2560>.

	[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>.

	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.	<https://www.rfc-editor.org/info/rfc4648>.

	[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,

	skipping to change at page 17, line 5 ¶	skipping to change at page 18, line 41 ¶
	<https://www.rfc-editor.org/info/rfc7517>.	<https://www.rfc-editor.org/info/rfc7517>.

	[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,	[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
	DOI 10.17487/RFC7518, May 2015,	DOI 10.17487/RFC7518, May 2015,
	<https://www.rfc-editor.org/info/rfc7518>.	<https://www.rfc-editor.org/info/rfc7518>.

	[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>.


	7.2. Informative References	8.2. Informative References

	[I-D.ietf-cbor-cddl]	[I-D.ietf-cbor-cddl]
	Birkholz, H., Vigano, C., and C. Bormann, "Concise data	Birkholz, H., Vigano, C., and C. Bormann, "Concise data
	definition language (CDDL): a notational convention to	definition language (CDDL): a notational convention to
	express CBOR and JSON data structures", draft-ietf-cbor-	express CBOR and JSON data structures", draft-ietf-cbor-
	cddl-08 (work in progress), March 2019.	cddl-08 (work in progress), March 2019.

	[I-D.ietf-teep-architecture]	[I-D.ietf-teep-architecture]
	Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.	Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
	Liu, "Trusted Execution Environment Provisioning (TEEP)	Liu, "Trusted Execution Environment Provisioning (TEEP)

	skipping to change at page 17, line 35 ¶	skipping to change at page 19, line 27 ¶
	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>.

	Appendix A. Acknowledgements	Appendix A. Acknowledgements

	This work is based on the initial version of OTrP	This work is based on the initial version of OTrP
	[I-D.ietf-teep-opentrustprotocol] and hence credits go to those who	[I-D.ietf-teep-opentrustprotocol] and hence credits go to those who
	have contributed to it.	have contributed to it.


		We would like to thank Eve Schooler for the suggestion of the
		protocol name.

	Appendix B. Contributors	Appendix B. Contributors

	We would like to thank the following individuals for their	We would like to thank the following individuals for their
	contributions to an earlier version of this specification.	contributions to an earlier version of this specification.

	- Brian Witten	- Brian Witten
	Symantec	Symantec
	brian_witten@symantec.com	brian_witten@symantec.com

	- Tyler Kim	- Tyler Kim

	skipping to change at page 18, line 23 ¶	skipping to change at page 20, line 7 ¶
	- Nick Cook	- Nick Cook
	Arm Ltd.	Arm Ltd.
	nicholas.cook@arm.com	nicholas.cook@arm.com

	- Minho Yoo	- Minho Yoo
	IoTrust	IoTrust
	minho.yoo@iotrust.kr	minho.yoo@iotrust.kr

	Authors' Addresses	Authors' Addresses


	Mingliang Pei
	Symantec
	350 Ellis St
	Mountain View, CA 94043
	USA

	Email: mingliang_pei@symantec.com

	Hannes Tschofenig	Hannes Tschofenig
	Arm Ltd.	Arm Ltd.
	110 Fulbourn Rd	110 Fulbourn Rd
	Cambridge, CB1 9NJ	Cambridge, CB1 9NJ
	Great Britain	Great Britain

	Email: hannes.tschofenig@arm.com	Email: hannes.tschofenig@arm.com


		Mingliang Pei
		Broadcom
		350 Ellis St
		Mountain View, CA 94043
		USA

		Email: mingliang.pei@broadcom.com

	David Wheeler	David Wheeler
	Intel	Intel
	US	US

	Email: david.m.wheeler@intel.com	Email: david.m.wheeler@intel.com


		Dave Thaler
		Microsoft
		US

		Email: dthaler@microsoft.com

End of changes. 39 change blocks.
	61 lines changed or deleted	137 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/