draft-ietf-teep-otrp-over-http-11.txt		draft-ietf-teep-otrp-over-http-12.txt
	TEEP WG D. Thaler		TEEP WG D. Thaler
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Informational July 12, 2021		Intended status: Standards Track 26 July 2021
	Expires: January 13, 2022		Expires: 27 January 2022
	HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-		HTTP Transport for Trusted Execution Environment Provisioning: Agent
	TAM Communication		Initiated Communication
	draft-ietf-teep-otrp-over-http-11		draft-ietf-teep-otrp-over-http-12
	Abstract		Abstract
	The Trusted Execution Environment Provisioning (TEEP) Protocol is		The Trusted Execution Environment Provisioning (TEEP) Protocol is
	used to manage code and configuration data in a Trusted Execution		used to manage code and configuration data in a Trusted Execution
	Environment (TEE). This document specifies the HTTP transport for		Environment (TEE). This document specifies the HTTP transport for
	TEEP communication where a Trusted Application Manager (TAM) service		TEEP communication where a Trusted Application Manager (TAM) service
	is used to manage code and data in TEEs on devices that can initiate		is used to manage code and data in TEEs on devices that can initiate
	communication to the TAM. An implementation of this document can (if		communication to the TAM. An implementation of this document can (if
	desired) run outside of any TEE, but interacts with a TEEP		desired) run outside of any TEE, but interacts with a TEEP
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 27 January 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		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 4		3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 4
	4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 5		4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 5
	5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 6		5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 6
	5.1. Receiving a request to install a new Trusted Application 6		5.1. Receiving a request to install a new Trusted
			Application . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7		5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7
	5.2. Receiving a notification that a Trusted Application is no		5.2. Receiving a notification that a Trusted Application is no
	longer needed . . . . . . . . . . . . . . . . . . . . . . 7		longer needed . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. Getting a message buffer back from a TEEP Agent . . . . . 8		5.3. Getting a message buffer back from a TEEP Agent . . . . . 8
	5.4. Receiving an HTTP response . . . . . . . . . . . . . . . 8		5.4. Receiving an HTTP response . . . . . . . . . . . . . . . 8
	5.5. Handling checks for policy changes . . . . . . . . . . . 9		5.5. Handling checks for policy changes . . . . . . . . . . . 9
	5.6. Error handling . . . . . . . . . . . . . . . . . . . . . 9		5.6. Error handling . . . . . . . . . . . . . . . . . . . . . 9
	6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10		6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 9
	6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10		6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10
	6.2. Getting an empty buffer back from the TAM . . . . . . . . 10		6.2. Getting an empty buffer back from the TAM . . . . . . . . 10
	6.3. Getting a message buffer from the TAM . . . . . . . . . . 10		6.3. Getting a message buffer from the TAM . . . . . . . . . . 10
	6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10		6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10
	7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10		7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	A Trusted Execution Environment (TEE) is an environment that enforces		A Trusted Execution Environment (TEE) is an environment that enforces
	that any code within that environment cannot be tampered with, and		that any code within that environment cannot be tampered with, and
	that any data used by such code cannot be read or tampered with by		that any data used by such code cannot be read or tampered with by
	any code outside that environment. The Trusted Execution Environment		any code outside that environment. The Trusted Execution Environment
	Provisioning (TEEP) protocol is designed to provision authorized code		Provisioning (TEEP) protocol is designed to provision authorized code
	and configuration into TEEs.		and configuration into TEEs.
	skipping to change at page 3, line 49 ¶		skipping to change at page 3, line 49 ¶
	+------------------+ +------------------+		+------------------+ +------------------+
	| |		| |
	+------------------+ TEEP-over-HTTP +------------------+		+------------------+ TEEP-over-HTTP +------------------+
	| TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server |		| TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server |
	+------------------+ +------------------+		+------------------+ +------------------+
	| |		| |
	+------------------+ HTTP +------------------+		+------------------+ HTTP +------------------+
	| HTTP Client | <----------------------> | HTTP Server |		| HTTP Client | <----------------------> | HTTP Server |
	+------------------+ +------------------+		+------------------+ +------------------+
	Figure 1: Agent-to-TAM Communication		Figure 1: Agent Initiated Communication
	This document specifies the middle layer (TEEP-over-HTTP), whereas		This document specifies the middle layer (TEEP-over-HTTP), whereas
	the top layer (TEEP) is specified in [I-D.ietf-teep-protocol].		the top layer (TEEP) is specified in [I-D.ietf-teep-protocol].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	5. TEEP/HTTP Client Behavior		5. TEEP/HTTP Client Behavior
	5.1. Receiving a request to install a new Trusted Application		5.1. Receiving a request to install a new Trusted Application
	In some environments, an application installer can determine (e.g.,		In some environments, an application installer can determine (e.g.,
	from an application manifest) that the application being installed or		from an application manifest) that the application being installed or
	updated has a dependency on a given Trusted Application (TA) being		updated has a dependency on a given Trusted Application (TA) being
	available in a given type of TEE. In such a case, it will notify a		available in a given type of TEE. In such a case, it will notify a
	TEEP Broker, where the notification will contain the following:		TEEP Broker, where the notification will contain the following:
	- A unique identifier of the TA		* A unique identifier of the TA
	- Optionally, any metadata to provide to the TEEP Agent. This might		* Optionally, any metadata to provide to the TEEP Agent. This might
	include a TAM URI provided in the application manifest, for		include a TAM URI provided in the application manifest, for
	example.		example.
	- Optionally, any requirements that may affect the choice of TEE, if		* Optionally, any requirements that may affect the choice of TEE, if
	multiple are available to the TEEP Broker.		multiple are available to the TEEP Broker.
	When a TEEP Broker receives such a notification, it first identifies		When a TEEP Broker receives such a notification, it first identifies
	in an implementation-dependent way which TEE (if any) is most		in an implementation-dependent way which TEE (if any) is most
	appropriate based on the constraints expressed. If there is only one		appropriate based on the constraints expressed. If there is only one
	TEE, the choice is obvious. Otherwise, the choice might be based on		TEE, the choice is obvious. Otherwise, the choice might be based on
	factors such as capabilities of available TEE(s) compared with TEE		factors such as capabilities of available TEE(s) compared with TEE
	requirements in the notification. Once the TEEP Broker picks a TEE,		requirements in the notification. Once the TEEP Broker picks a TEE,
	it passes the notification to the TEEP/HTTP Client for that TEE.		it passes the notification to the TEEP/HTTP Client for that TEE.
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 22 ¶
	HTTP(S) POST to the TAM URI with an Accept header with the TEEP media		HTTP(S) POST to the TAM URI with an Accept header with the TEEP media
	type requested, and an empty body. The HTTP request is then		type requested, and an empty body. The HTTP request is then
	associated with the TEEP/HTTP Client's session state.		associated with the TEEP/HTTP Client's session state.
	If the TEEP Agent instead passes back a TAM URI with a message		If the TEEP Agent instead passes back a TAM URI with a message
	buffer, the TEEP/HTTP Client attempts to create session state and		buffer, the TEEP/HTTP Client attempts to create session state and
	handles the message buffer as specified in Section 5.3.		handles the message buffer as specified in Section 5.3.
	Session state consists of:		Session state consists of:
	- Any context (e.g., a handle) that identifies the API session with		* Any context (e.g., a handle) that identifies the API session with
	the TEEP Agent.		the TEEP Agent.
	- Any context that identifies an HTTP request, if one is		* Any context that identifies an HTTP request, if one is
	outstanding. Initially, none exists.		outstanding. Initially, none exists.
	5.2. Receiving a notification that a Trusted Application is no longer		5.2. Receiving a notification that a Trusted Application is no longer
	needed		needed
	In some environments, an application installer can determine (e.g.,		In some environments, an application installer can determine (e.g.,
	from an application manifest) that a given Trusted Application is no		from an application manifest) that a given Trusted Application is no
	longer needed, such as if the application that previously depended on		longer needed, such as if the application that previously depended on
	the TA is uninstalled or updated in a way that removes the		the TA is uninstalled or updated in a way that removes the
	dependency. In such a case, it will notify a TEEP Broker, where the		dependency. In such a case, it will notify a TEEP Broker, where the
	notification will contain the following:		notification will contain the following:
	- A unique identifier of the TA		* A unique identifier of the TA
	- Optionally, any requirements that may affect the choice of TEE, if		* Optionally, any requirements that may affect the choice of TEE, if
	multiple are available to the TEEP Broker.		multiple are available to the TEEP Broker.
	When a TEEP Broker receives such a notification, it first identifies		When a TEEP Broker receives such a notification, it first identifies
	in an implementation-dependent way which TEE (if any) is appropriate		in an implementation-dependent way which TEE (if any) is appropriate
	based on the constraints expressed, as in Section 5.1.		based on the constraints expressed, as in Section 5.1.
	The TEEP/HTTP Client then informs the TEEP Agent in that TEE by		The TEEP/HTTP Client then informs the TEEP Agent in that TEE by
	invoking an appropriate "UnrequestTA" API that identifies the		invoking an appropriate "UnrequestTA" API that identifies the
	unneeded TA. The TEEP/HTTP Client need not know whether the TEE		unneeded TA. The TEEP/HTTP Client need not know whether the TEE
	actually has the TA installed.		actually has the TA installed.
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 18 ¶
	2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API,		2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API,
	passing TA Needed = X.		passing TA Needed = X.
	3. The TEEP Agent finds that no such TA is already installed, but		3. The TEEP Agent finds that no such TA is already installed, but
	that it can be obtained from a given TAM. The TEEP Agent passes		that it can be obtained from a given TAM. The TEEP Agent passes
	the TAM URI (e.g., "https://example.com/tam") to the TEEP/HTTP		the TAM URI (e.g., "https://example.com/tam") to the TEEP/HTTP
	Client.		Client.
	4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI:		4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI:
	POST /tam HTTP/1.1		POST /tam HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/teep+cbor		Accept: application/teep+cbor
	Content-Length: 0		Content-Length: 0
	User-Agent: Foo/1.0		User-Agent: Foo/1.0
	where the TEEP/HTTP Client fills in an implementation-specific		where the TEEP/HTTP Client fills in an implementation-specific
	value in the User-Agent header.		value in the User-Agent header.
	5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST		5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST
	request, and calls the TAM's "ProcessConnect" API.		request, and calls the TAM's "ProcessConnect" API.
	6. The TAM generates a TEEP message (where typically QueryRequest		6. The TAM generates a TEEP message (where typically QueryRequest
	is the first message) and passes it to the TEEP/HTTP Server.		is the first message) and passes it to the TEEP/HTTP Server.
	7. The TEEP/HTTP Server sends an HTTP successful response with the		7. The TEEP/HTTP Server sends an HTTP successful response with the
	TEEP message in the body:		TEEP message in the body:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/teep+cbor		Content-Type: application/teep+cbor
	Content-Length: [length of TEEP message here]		Content-Length: [length of TEEP message here]
	Server: Bar/2.2		Server: Bar/2.2
	X-Content-Type-Options: nosniff		X-Content-Type-Options: nosniff
	Content-Security-Policy: default-src 'none'		Content-Security-Policy: default-src 'none'
	Referrer-Policy: no-referrer		Referrer-Policy: no-referrer
	[TEEP message here]		[TEEP message here]
	where the TEEP/HTTP Server fills in an implementation-specific		where the TEEP/HTTP Server fills in an implementation-specific
	value in the Server header.		value in the Server header.
	8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP		8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP
	response, extracts the TEEP message and pass it up to the TEEP		response, extracts the TEEP message and pass it up to the TEEP
	Agent.		Agent.
	9. The TEEP Agent processes the TEEP message, and generates a TEEP		9. The TEEP Agent processes the TEEP message, and generates a TEEP
	response (e.g., QueryResponse) which it passes back to the TEEP/		response (e.g., QueryResponse) which it passes back to the TEEP/
	HTTP Client.		HTTP Client.
	10. The TEEP/HTTP Client gets the TEEP message buffer and sends an		10. The TEEP/HTTP Client gets the TEEP message buffer and sends an
	HTTP POST request to the TAM URI, with the TEEP message in the		HTTP POST request to the TAM URI, with the TEEP message in the
	body:		body:
	POST /tam HTTP/1.1		POST /tam HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/teep+cbor		Accept: application/teep+cbor
	Content-Type: application/teep+cbor		Content-Type: application/teep+cbor
	Content-Length: [length of TEEP message here]		Content-Length: [length of TEEP message here]
	User-Agent: Foo/1.0		User-Agent: Foo/1.0
	[TEEP message here]		[TEEP message here]
	11. The TEEP/HTTP Server receives the HTTP POST request, and passes		11. The TEEP/HTTP Server receives the HTTP POST request, and passes
	the payload up to the TAM.		the payload up to the TAM.
	12. Steps 6-11 are then repeated until the TAM passes no data back		12. Steps 6-11 are then repeated until the TAM passes no data back
	to the TEEP/HTTP Server in step 6.		to the TEEP/HTTP Server in step 6.
	13. The TEEP/HTTP Server sends an HTTP successful response with no		13. The TEEP/HTTP Server sends an HTTP successful response with no
	body:		body:
	HTTP/1.1 204 No Content		HTTP/1.1 204 No Content
	Server: Bar/2.2		Server: Bar/2.2
	14. The TEEP/HTTP Client deletes its session state.		14. The TEEP/HTTP Client deletes its session state.
	8. Security Considerations		8. Security Considerations
	Section 4 discussed security recommendations for HTTPS transport of		Section 4 discussed security recommendations for HTTPS transport of
	TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for		TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for
	additional discussion of HTTP(S) security considerations.		additional discussion of HTTP(S) security considerations.
	9. IANA Considerations		9. IANA Considerations
	skipping to change at page 13, line 21 ¶		skipping to change at page 13, line 13 ¶
	10.1. Normative References		10.1. Normative References
	[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,		[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <https://www.rfc-editor.org/info/rfc7525>.		2015, <https://www.rfc-editor.org/info/rfc7525>.
	[I-D.ietf-httpbis-semantics]		[I-D.ietf-httpbis-semantics]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", draft-ietf-httpbis-semantics-16 (work in		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	progress), May 2021.		httpbis-semantics-17, 25 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-httpbis-
			semantics-17.txt>.
	[I-D.ietf-teep-protocol]		[I-D.ietf-teep-protocol]
	Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.		Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.
	Tsukamoto, "Trusted Execution Environment Provisioning		Tsukamoto, "Trusted Execution Environment Provisioning
	(TEEP) Protocol", draft-ietf-teep-protocol-05 (work in		(TEEP) Protocol", Work in Progress, Internet-Draft, draft-
	progress), February 2021.		ietf-teep-protocol-06, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-teep-protocol-
			06.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>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 12 ¶
	10.2. Informative References		10.2. Informative References
	[GP-OTrP] Global Platform, "TEE Management Framework: Open Trust		[GP-OTrP] Global Platform, "TEE Management Framework: Open Trust
	Protocol (OTrP) Profile Version 1.0", Global		Protocol (OTrP) Profile Version 1.0", Global
	Platform GPD_SPE_123, May 2019,		Platform GPD_SPE_123, May 2019,
	<https://globalplatform.org/specs-library/tee-management-		<https://globalplatform.org/specs-library/tee-management-
	framework-open-trust-protocol/>.		framework-open-trust-protocol/>.
	[I-D.ietf-httpbis-bcp56bis]		[I-D.ietf-httpbis-bcp56bis]
	Nottingham, M., "Building Protocols with HTTP", draft-		Nottingham, M., "Building Protocols with HTTP", Work in
	ietf-httpbis-bcp56bis-12 (work in progress), April 2021.		Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-12,
			27 April 2021, <https://www.ietf.org/archive/id/draft-
			ietf-httpbis-bcp56bis-12.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-14 (work in		Architecture", Work in Progress, Internet-Draft, draft-
	progress), February 2021.		ietf-teep-architecture-15, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-teep-
			architecture-15.txt>.
	[I-D.ietf-teep-opentrustprotocol]		[I-D.ietf-teep-opentrustprotocol]
	Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,		Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
	"The Open Trust Protocol (OTrP)", draft-ietf-teep-		"The Open Trust Protocol (OTrP)", Work in Progress,
	opentrustprotocol-03 (work in progress), May 2019.		Internet-Draft, draft-ietf-teep-opentrustprotocol-03, 15
			May 2019, <https://www.ietf.org/archive/id/draft-ietf-
			teep-opentrustprotocol-03.txt>.
	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.		<https://www.rfc-editor.org/info/rfc9000>.
	Author's Address		Author's Address
	Dave Thaler		Dave Thaler
	Microsoft		Microsoft
	EMail: dthaler@microsoft.com		Email: dthaler@microsoft.com
End of changes. 27 change blocks.
	60 lines changed or deleted		70 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/