< draft-ietf-teep-architecture-14.txt		draft-ietf-teep-architecture-15.txt >
	TEEP M. Pei		TEEP M. Pei
	Internet-Draft Broadcom		Internet-Draft Broadcom
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: August 26, 2021 Arm Limited		Expires: January 13, 2022 Arm Limited
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	D. Wheeler		D. Wheeler
	Intel		Amazon
	February 22, 2021		July 12, 2021
	Trusted Execution Environment Provisioning (TEEP) Architecture		Trusted Execution Environment Provisioning (TEEP) Architecture
	draft-ietf-teep-architecture-14		draft-ietf-teep-architecture-15
	Abstract		Abstract
	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. This architecture document		any code outside that environment. This architecture document
	motivates the design and standardization of a protocol for managing		motivates the design and standardization of a protocol for managing
	the lifecycle of trusted applications running inside such a TEE.		the lifecycle of trusted applications running inside such a TEE.
	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 August 26, 2021.		This Internet-Draft will expire on January 13, 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/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.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8		3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8		3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8
	3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8		3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 3, line 4 ¶		skipping to change at page 2, line 40 ¶
	5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 21		5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 21
	5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 21		5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 21
	5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 21		5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 21
	5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 21		5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 21
	5.5. Message Security . . . . . . . . . . . . . . . . . . . . 22		5.5. Message Security . . . . . . . . . . . . . . . . . . . . 22
	6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 22		6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 23		6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 23
	6.2. TEEP Broker Implementation Consideration . . . . . . . . 23		6.2. TEEP Broker Implementation Consideration . . . . . . . . 23
	6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 24		6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 24
	6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 25		6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 25
	7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 25		7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 25
	8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 27		8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 27
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 28		9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28		9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28
	9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 28		9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 28
	9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 29		9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 29
	9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 30		9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 30
	9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 30		9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 30
	9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 30		9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 31
	9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 31		9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 31
	9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 32		9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 32
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	13. Informative References . . . . . . . . . . . . . . . . . . . 32		13. Informative References . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	skipping to change at page 7, line 8 ¶		skipping to change at page 6, line 47 ¶
	is a set of one or more trust anchors stored in a device. A		is a set of one or more trust anchors stored in a device. A
	device may have more than one trust anchor store, each of which		device may have more than one trust anchor store, each of which
	may be used by one or more applications." As noted in		may be used by one or more applications." As noted in
	[I-D.ietf-suit-manifest], a Trust Anchor Store must resist		[I-D.ietf-suit-manifest], a Trust Anchor Store must resist
	modification against unauthorized insertion, deletion, and		modification against unauthorized insertion, deletion, and
	modification.		modification.
	- Trusted Application (TA): An application (or, in some		- Trusted Application (TA): An application (or, in some
	implementations, an application component) that runs in a TEE.		implementations, an application component) that runs in a TEE.
	- Trusted Application (TA) Developer: An entity that develops one or
	more TAs.
	- Trusted Component (TA) Signer: An entity that signs a Trusted
	Component with a key that a TEE will trust. The signer might or
	might not be the same entity as the TA Developer. For example, a
	TA might be signed (or re-signed) by a Device Administrator if the
	TEE will only trust the Device Administrator. A TA might also be
	encrypted, if the code is considered confidential.
	- Trusted Application Manager (TAM): An entity that manages Trusted		- Trusted Application Manager (TAM): An entity that manages Trusted
	Components running in TEEs of various devices.		Applications and other Trusted Components running in TEEs of
			various devices.
	- Trusted Component: A set of code and/or data in a TEE managed as a		- Trusted Component: A set of code and/or data in a TEE managed as a
	unit by a Trusted Application Manager. Trusted Applications and		unit by a Trusted Application Manager. Trusted Applications and
	Personalization Data are thus managed by being included in Trusted		Personalization Data are thus managed by being included in Trusted
	Components. Trusted OS code or trusted firmware can also be		Components. Trusted OS code or trusted firmware can also be
	expressed as Trusted Components that a TA depends on.		expressed as Trusted Components that a Trusted Component depends
			on.
			- Trusted Component Developer: An entity that develops one or more
			Trusted Components.
			- Trusted Component Signer: An entity that signs a Trusted Component
			with a key that a TEE will trust. The signer might or might not
			be the same entity as the Trusted Component Developer. For
			example, a Trusted Component might be signed (or re-signed) by a
			Device Administrator if the TEE will only trust the Device
			Administrator. A Trusted Component might also be encrypted, if
			the code is considered confidential.
	- Trusted Execution Environment (TEE): An execution environment that		- Trusted Execution Environment (TEE): An execution environment that
	enforces that only authorized code can execute within the TEE, and		enforces that only authorized code can execute within the TEE, and
	data used by that code cannot be read or tampered with by code		data used by that code cannot be read or tampered with by code
	outside the TEE. A TEE also generally has a device unique		outside the TEE. A TEE also generally has a device unique
	credential that cannot be cloned. There are multiple technologies		credential that cannot be cloned. There are multiple technologies
	that can be used to implement a TEE, and the level of security		that can be used to implement a TEE, and the level of security
	achieved varies accordingly. In addition, TEEs typically use an		achieved varies accordingly. In addition, TEEs typically use an
	isolation mechanism between Trusted Applications to ensure that		isolation mechanism between Trusted Applications to ensure that
	one TA cannot read, modify or delete the data and code of another		one TA cannot read, modify or delete the data and code of another
	skipping to change at page 13, line 20 ¶		skipping to change at page 13, line 20 ¶
	Untrusted Application, but is ultimately the decision of a TEEP		Untrusted Application, but is ultimately the decision of a TEEP
	Agent.		Agent.
	A TEEP Agent is assumed to be able to determine, for any given		A TEEP Agent is assumed to be able to determine, for any given
	Trusted Component, whether that Trusted Component is installed (or		Trusted Component, whether that Trusted Component is installed (or
	minimally, is running) in a TEE with which the TEEP Agent is		minimally, is running) in a TEE with which the TEEP Agent is
	associated.		associated.
	Each Trusted Component is digitally signed, protecting its integrity,		Each Trusted Component is digitally signed, protecting its integrity,
	and linking the Trusted Component back to the Trusted Component		and linking the Trusted Component back to the Trusted Component
	Signer. The Trusted Component Signer is often the TA Developer, but		Signer. The Trusted Component Signer is often the Trusted Component
	in some cases might be another party such as a Device Administrator		Developer, but in some cases might be another party such as a Device
	or other party to whom the code has been licensed (in which case the		Administrator or other party to whom the code has been licensed (in
	same code might be signed by multiple licensees and distributed as if		which case the same code might be signed by multiple licensees and
	it were different TAs).		distributed as if it were different TAs).
	A Trusted Component Signer selects one or more TAMs and communicates		A Trusted Component Signer selects one or more TAMs and communicates
	the Trusted Component(s) to the TAM. For example, the Trusted		the Trusted Component(s) to the TAM. For example, the Trusted
	Component Signer might choose TAMs based upon the markets into which		Component Signer might choose TAMs based upon the markets into which
	the TAM can provide access. There may be TAMs that provide services		the TAM can provide access. There may be TAMs that provide services
	to specific types of devices, or device operating systems, or		to specific types of devices, or device operating systems, or
	specific geographical regions or network carriers. A Trusted		specific geographical regions or network carriers. A Trusted
	Component Signer may be motivated to utilize multiple TAMs in order		Component Signer may be motivated to utilize multiple TAMs in order
	to maximize market penetration and availability on multiple types of		to maximize market penetration and availability on multiple types of
	devices. This means that the same Trusted Component will often be		devices. This means that the same Trusted Component will often be
	skipping to change at page 17, line 19 ¶		skipping to change at page 17, line 19 ¶
	from SGX since in TrustZone the TA lifetime is not inherently tied to		from SGX since in TrustZone the TA lifetime is not inherently tied to
	a specific Untrused Application process lifetime as occurs in SGX. A		a specific Untrused Application process lifetime as occurs in SGX. A
	TA is loaded by a trusted OS running in the TEE such as a		TA is loaded by a trusted OS running in the TEE such as a
	GlobalPlatform compliant TEE, where the trusted OS is separate from		GlobalPlatform compliant TEE, where the trusted OS is separate from
	the OS in the REE. Thus Cases 2 and 3 are equally applicable. In		the OS in the REE. Thus Cases 2 and 3 are equally applicable. In
	addition, it is possible for TAs to communicate with each other		addition, it is possible for TAs to communicate with each other
	without involving any Untrusted Application, and so the complexity of		without involving any Untrusted Application, and so the complexity of
	Case 1 is lower than in the SGX example. Thus, Case 1 is possible as		Case 1 is lower than in the SGX example. Thus, Case 1 is possible as
	well, though still more complex than Cases 2 and 3.		well, though still more complex than Cases 2 and 3.
	TEE OS's (e.g., OP-TEE) that support loading and verifying signed TAs		A trusted OS running in the TEE (e.g., OP-TEE) that supports loading
	from an untrusted filesystem can, like SGX, use classic file		and verifying signed TAs from an untrusted filesystem can, like SGX,
	distribution mechanisms. If secure TA storage is used (e.g., a		use classic file distribution mechanisms. If secure TA storage is
	Replay-Protected Memory Block device) on the other hand, the TEEP		used (e.g., a Replay-Protected Memory Block device) on the other
	protocol can be used to manage such storage.		hand, the TEEP protocol can be used to manage such storage.
	4.5. Entity Relations		4.5. Entity Relations
	This architecture leverages asymmetric cryptography to authenticate a		This architecture leverages asymmetric cryptography to authenticate a
	device to a TAM. Additionally, a TEEP Agent in a device		device to a TAM. Additionally, a TEEP Agent in a device
	authenticates a TAM. The provisioning of Trust Anchors to a device		authenticates a TAM. The provisioning of Trust Anchors to a device
	may be different from one use case to the other. A Device		may be different from one use case to the other. A Device
	Administrator may want to have the capability to control what TAs are		Administrator may want to have the capability to control what TAs are
	allowed. A device manufacturer enables verification by one or more		allowed. A device manufacturer enables verification by one or more
	TAMs and by Trusted Component Signers; it may embed a list of default		TAMs and by Trusted Component Signers; it may embed a list of default
	skipping to change at page 20, line 9 ¶		skipping to change at page 20, line 9 ¶
	messages are always signed, where the signer key is the message		messages are always signed, where the signer key is the message
	originator's private key, such as that of a TAM or a TEE. In		originator's private key, such as that of a TAM or a TEE. In
	addition to the keys shown in Figure 4, there may be additional keys		addition to the keys shown in Figure 4, there may be additional keys
	used for attestation. Refer to the RATS Architecture		used for attestation. Refer to the RATS Architecture
	[I-D.ietf-rats-architecture] for more discussion.		[I-D.ietf-rats-architecture] for more discussion.
	Cardinality & Location of		Cardinality & Location of
	Location of Private Key Trust Anchor		Location of Private Key Trust Anchor
	Purpose Private Key Signs Store		Purpose Private Key Signs Store
	------------------ ----------- ------------- -------------		------------------ ----------- ------------- -------------
	Authenticating TEE 1 per TEE TEEP responses TAM		Authenticating 1 per TEE TEEP responses TAM
			TEEP Agent
	Authenticating TAM 1 per TAM TEEP requests TEEP Agent		Authenticating TAM 1 per TAM TEEP requests TEEP Agent
	Code Signing 1 per Trusted TA binary TEE		Code Signing 1 per Trusted TA binary TEE
	Component		Component
	Signer		Signer
	Figure 4: Signature Keys		Figure 4: Signature Keys
	Note that Personalization Data is not included in the table above.		Note that Personalization Data is not included in the table above.
	skipping to change at page 24, line 19 ¶		skipping to change at page 24, line 19 ¶
	| TEEP | Agent | | | Agent		| TEEP | Agent | | | Agent
	| implementation | | | |		| implementation | | | |
	+----------------+ v | |		+----------------+ v | |
	| | |		| | |
	+----------------+ ^ | |		+----------------+ ^ | |
	| TEEP/HTTP | Broker | | |		| TEEP/HTTP | Broker | | |
	| implementation | | | |		| implementation | | | |
	+----------------+ | v |		+----------------+ | v |
	| | |		| | |
	+----------------+ | ^ |		+----------------+ | ^ |
	| HTTP | | | |		| HTTP(S) | | | |
	| implementation | | | |		| implementation | | | |
	+----------------+ | | v		+----------------+ | | v
	| | |		| | |
	+----------------+ | | ^		+----------------+ | | ^
	| TCP or QUIC | | | | Broker		| TCP or QUIC | | | | Broker
	| implementation | | | |		| implementation | | | |
	+----------------+ | | |		+----------------+ | | |
	REE REE REE		REE REE REE
	Figure 5: TEEP Broker Models		Figure 5: TEEP Broker Models
	skipping to change at page 29, line 10 ¶		skipping to change at page 29, line 10 ¶
	Similarly, it is the responsibility of the TEE implementation to		Similarly, it is the responsibility of the TEE implementation to
	provide protection of data against integrity and confidentiality		provide protection of data against integrity and confidentiality
	attacks from outside the TEE. TEEs that provide isolation among TAs		attacks from outside the TEE. TEEs that provide isolation among TAs
	within the TEE are likewise responsible for protecting TA data		within the TEE are likewise responsible for protecting TA data
	against the REE and other TAs. For example, this can be used to		against the REE and other TAs. For example, this can be used to
	protect one user's or tenant's data from compromise by another user		protect one user's or tenant's data from compromise by another user
	or tenant, even if the attacker has TAs.		or tenant, even if the attacker has TAs.
	The protocol between TEEP Agents and TAMs similarly is responsible		The protocol between TEEP Agents and TAMs similarly is responsible
	for securely providing integrity and confidentiality protection		for securely providing integrity and confidentiality protection
	against adversaries between them. Since the transport protocol under		against adversaries between them. It is a design choice at what
	the TEEP protocol might be implemented outside a TEE, as discussed in		layers to best provide protection against network adversaries. As
	Section 6, it cannot be relied upon for sufficient protection. The		discussed in Section 6, the transport protocol and any security
	TEEP protocol provides integrity protection, but confidentiality must		mechanism associated with it (e.g., the Transport Layer Security
	be provided by payload encryption, i.e., using encrypted TA binaries		protocol) under the TEEP protocol may terminate outside a TEE. If it
	and encrypted attestation information. See [I-D.ietf-teep-protocol]		does, the TEEP protocol itself must provide integrity protection and
	for more discussion.		confidentiality protection to secure data end-to-end. For example,
			confidentiality protection for payloads may be provided by utilizing
			encrypted TA binaries and encrypted attestation information. See
			[I-D.ietf-teep-protocol] for how a specific solution addresses the
			design question of how to provide integrity and confidentiality
			protection.
	9.3. Compromised REE		9.3. Compromised REE
	It is possible that the REE of a device is compromised. We have		It is possible that the REE of a device is compromised. We have
	already seen examples of attacks on the public Internet of billions		already seen examples of attacks on the public Internet of billions
	of compromised devices being used to mount DDoS attacks. A		of compromised devices being used to mount DDoS attacks. A
	compromised REE can be used for such an attack but it cannot tamper		compromised REE can be used for such an attack but it cannot tamper
	with the TEE's code or data in doing so. A compromised REE can,		with the TEE's code or data in doing so. A compromised REE can,
	however, launch DoS attacks against the TEE.		however, launch DoS attacks against the TEE.
	skipping to change at page 30, line 12 ¶		skipping to change at page 30, line 18 ¶
	request. A TEEP Agent implementation is responsible for ensuring		request. A TEEP Agent implementation is responsible for ensuring
	that it can recognize and decline such repeated requests. It is also		that it can recognize and decline such repeated requests. It is also
	responsible for protecting the resource usage allocated for Trusted		responsible for protecting the resource usage allocated for Trusted
	Component management.		Component management.
	9.4. CA Compromise or Expiry of CA Certificate		9.4. CA Compromise or Expiry of CA Certificate
	A root CA for TAM certificates might get compromised or its		A root CA for TAM certificates might get compromised or its
	certificate might expire, or a Trust Anchor other than a root CA		certificate might expire, or a Trust Anchor other than a root CA
	certificate may also expire or be compromised. TEEs are responsible		certificate may also expire or be compromised. TEEs are responsible
	for validating the entire TAM certificate chain, including the TAM		for validating the entire TAM certificate path, including the TAM
	certificate and any intermediate certificates up to the root		certificate and any intermediate certificates up to the root
	certificate. Such validation includes checking for certificate		certificate. Such validation includes checking for certificate
	revocation.		revocation. See Section 6 of [RFC5280] for details.
	If a TAM certificate chain validation fails, the TAM might be		If a TAM certificate path validation fails, the TAM might be rejected
	rejected by a TEEP Agent. To address this, some certificate chain		by a TEEP Agent. To address this, some certificate path update
	update mechanism is expected from TAM operators, so that the TAM can		mechanism is expected from TAM operators, so that the TAM can get a
	get a new certificate chain that can be validated by a TEEP Agent.		new certificate path that can be validated by a TEEP Agent. In
	In addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store		addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store may
	may need to be updated. To address this, some TEE Trust Anchor		need to be updated. To address this, some TEE Trust Anchor update
	update mechanism is expected from device OEMs.		mechanism is expected from device OEMs.
	Similarly, a root CA for TEE certificates might get compromised or		Similarly, a root CA for TEE certificates might get compromised or
	its certificate might expire, or a Trust Anchor other than a root CA		its certificate might expire, or a Trust Anchor other than a root CA
	certificate may also expire or be compromised. TAMs are responsible		certificate may also expire or be compromised. TAMs are responsible
	for validating the entire TEE certificate chain, including the TEE		for validating the entire TEE certificate path, including the TEE
	certificate and any intermediate certificates up to the root		certificate and any intermediate certificates up to the root
	certificate. Such validation includes checking for certificate		certificate. Such validation includes checking for certificate
	revocation.		revocation.
	If a TEE certificate chain validation fails, the TEE might be		If a TEE certificate path validation fails, the TEE might be rejected
	rejected by a TAM, subject to the TAM's policy. To address this,		by a TAM, subject to the TAM's policy. To address this, some
	some certificate chain update mechanism is expected from device OEMs,		certificate path update mechanism is expected from device OEMs, so
	so that the TEE can get a new certificate chain that can be validated		that the TEE can get a new certificate path that can be validated by
	by a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor		a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor Store
	Store may need to be updated.		may need to be updated.
	9.5. Compromised TAM		9.5. Compromised TAM
	Device TEEs are responsible for validating the supplied TAM		Device TEEs are responsible for validating the supplied TAM
	certificates to determine that the TAM is trustworthy.		certificates to determine that the TAM is trustworthy.
	9.6. Malicious TA Removal		9.6. Malicious TA Removal
	It is possible that a rogue developer distributes a malicious		It is possible that a rogue developer distributes a malicious
	Untrusted Application and intends to get a malicious TA installed.		Untrusted Application and intends to get a malicious TA installed.
	skipping to change at page 33, line 8 ¶		skipping to change at page 33, line 12 ¶
	January 2017, <https://globalplatform.org/specs-library/		January 2017, <https://globalplatform.org/specs-library/
	tee-system-architecture-v1-1/>.		tee-system-architecture-v1-1/>.
	[GSMA] GSM Association, "GP.22 RSP Technical Specification,		[GSMA] GSM Association, "GP.22 RSP Technical Specification,
	Version 2.2.2", June 2020, <https://www.gsma.com/esim/wp-		Version 2.2.2", June 2020, <https://www.gsma.com/esim/wp-
	content/uploads/2020/06/SGP.22-v2.2.2.pdf>.		content/uploads/2020/06/SGP.22-v2.2.2.pdf>.
	[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",
	draft-ietf-rats-architecture-08 (work in progress),		draft-ietf-rats-architecture-12 (work in progress), April
	December 2020.		2021.
	[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-11		of Things (SUIT) Manifest", draft-ietf-suit-manifest-14
	(work in progress), December 2020.		(work in progress), July 2021.
	[I-D.ietf-teep-otrp-over-http]		[I-D.ietf-teep-otrp-over-http]
	Thaler, D., "HTTP Transport for Trusted Execution		Thaler, D., "HTTP Transport for Trusted Execution
	Environment Provisioning: Agent-to- TAM Communication",		Environment Provisioning: Agent-to- TAM Communication",
	draft-ietf-teep-otrp-over-http-09 (work in progress),		draft-ietf-teep-otrp-over-http-11 (work in progress), July
	November 2020.		2021.
	[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-04 (work in		(TEEP) Protocol", draft-ietf-teep-protocol-05 (work in
	progress), November 2020.		progress), February 2021.
	[OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1",		[OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1",
	GlobalPlatform GPD_SPE_123, July 2020,		GlobalPlatform GPD_SPE_123, July 2020,
	<https://globalplatform.org/specs-library/tee-management-		<https://globalplatform.org/specs-library/tee-management-
	framework-open-trust-protocol/>.		framework-open-trust-protocol/>.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/info/rfc4949>.		<https://www.rfc-editor.org/info/rfc4949>.
	skipping to change at page 34, line 33 ¶		skipping to change at page 34, line 38 ¶
	Arm Limited		Arm Limited
	EMail: hannes.tschofenig@arm.com		EMail: hannes.tschofenig@arm.com
	Dave Thaler		Dave Thaler
	Microsoft		Microsoft
	EMail: dthaler@microsoft.com		EMail: dthaler@microsoft.com
	David Wheeler		David Wheeler
	Intel		Amazon
	EMail: david.m.wheeler@intel.com		EMail: davewhee@amazon.com
End of changes. 26 change blocks.
	75 lines changed or deleted		71 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/