draft-ietf-teep-architecture-06.txt		draft-ietf-teep-architecture-07.txt
	TEEP M. Pei		TEEP M. Pei
	Internet-Draft Symantec		Internet-Draft Symantec
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: August 11, 2020 Arm Limited		Expires: September 8, 2020 Arm Limited
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	D. Wheeler		D. Wheeler
	Intel		Intel
	February 08, 2020		March 07, 2020
	Trusted Execution Environment Provisioning (TEEP) Architecture		Trusted Execution Environment Provisioning (TEEP) Architecture
	draft-ietf-teep-architecture-06		draft-ietf-teep-architecture-07
	Abstract		Abstract
	A Trusted Execution Environment (TEE) is an environment that enforces		A Trusted Execution Environment (TEE) is an environment that enforces
	that only authorized code can execute within that environment, and		that only authorized code can execute within that environment, 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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 11, 2020.		This Internet-Draft will expire on September 8, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	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 . . . . . . . . . . . . . . . . . . . . . 7		3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7		3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7
	3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8		3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. System Components . . . . . . . . . . . . . . . . . . . . 8		4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
	4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 10		4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 10
	4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12		4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12
	4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 13		4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14
	4.4.1. Examples of Application Delivery Mechanisms in		4.4.1. Examples of Application Delivery Mechanisms in
	Existing TEEs . . . . . . . . . . . . . . . . . . . . 14		Existing TEEs . . . . . . . . . . . . . . . . . . . . 15
	4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16		4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16
	5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17		5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17
	5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 18		5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 19
	5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 19		5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 19
	5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 19		5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 19
	5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19		5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
	5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20		5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20
	6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 20		6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20		6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20
	6.2. TEEP Broker Implementation Consideration . . . . . . . . 21		6.2. TEEP Broker Implementation Consideration . . . . . . . . 21
	6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 21		6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 21
	6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22		6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22
	7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22		7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24		8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 25		9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25		9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25
	9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 25		9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 25
	9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 25		9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 25
	9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26		9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26
	9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26		9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26
	9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 26		9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 26
	9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 27		9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 27
	9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 27		9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 27
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	13. Informative References . . . . . . . . . . . . . . . . . . . 28		13. Informative References . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	Applications executing in a device are exposed to many different		Applications executing in a device are exposed to many different
	attacks intended to compromise the execution of the application or		attacks intended to compromise the execution of the application or
	reveal the data upon which those applications are operating. These		reveal the data upon which those applications are operating. These
	attacks increase with the number of other applications on the device,		attacks increase with the number of other applications on the device,
	with such other applications coming from potentially untrustworthy		with such other applications coming from potentially untrustworthy
	sources. The potential for attacks further increases with the		sources. The potential for attacks further increases with the
	complexity of features and applications on devices, and the		complexity of features and applications on devices, and the
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	with other human beings as secondary device users (e.g., parent		with other human beings as secondary device users (e.g., parent
	allowing children to use their tablet or laptop). Other devices		allowing children to use their tablet or laptop). Other devices
	are not used by a human being and hence have no device user.		are not used by a human being and hence have no device user.
	Relates to Device Owner and Device Administrator.		Relates to Device Owner and Device Administrator.
	- Rich Execution Environment (REE): An environment that is provided		- Rich Execution Environment (REE): An environment that is provided
	and governed by a typical OS (e.g., Linux, Windows, Android, iOS),		and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
	potentially in conjunction with other supporting operating systems		potentially in conjunction with other supporting operating systems
	and hypervisors; it is outside of any TEE. This environment and		and hypervisors; it is outside of any TEE. This environment and
	applications running on it are considered untrusted (or more		applications running on it are considered untrusted (or more
	precisely, less trusted than the TEE).		precisely, less trusted than a TEE).
	- Trust Anchor: As defined in [RFC6024] and		- Trust Anchor: As defined in [RFC6024] and
	[I-D.ietf-suit-manifest], "A trust anchor represents an		[I-D.ietf-suit-manifest], "A trust anchor represents an
	authoritative entity via a public key and associated data. The		authoritative entity via a public key and associated data. The
	public key is used to verify digital signatures, and the		public key is used to verify digital signatures, and the
	associated data is used to constrain the types of information for		associated data is used to constrain the types of information for
	which the trust anchor is authoritative." The Trust Anchor may be		which the trust anchor is authoritative." The Trust Anchor may be
	a certificate or it may be a raw public key along with additional		a certificate or it may be a raw public key along with additional
	data if necessary such as its public key algorithm and parameters.		data if necessary such as its public key algorithm and parameters.
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 12 ¶
	keys in their device's Trust Anchor list. Alternatively, a TAM		keys in their device's Trust Anchor list. Alternatively, a TAM
	may publish its certificate and allow Device Administrators to		may publish its certificate and allow Device Administrators to
	install the TAM's certificate in their devices as an after-market-		install the TAM's certificate in their devices as an after-market-
	action.		action.
	- TEEP Broker: A TEEP Broker is an application component running in		- TEEP Broker: A TEEP Broker is an application component running in
	a Rich Execution Environment (REE) that enables the message		a Rich Execution Environment (REE) that enables the message
	protocol exchange between a TAM and a TEE in a device. A TEEP		protocol exchange between a TAM and a TEE in a device. A TEEP
	Broker does not process messages on behalf of a TEE, but merely is		Broker does not process messages on behalf of a TEE, but merely is
	responsible for relaying messages from the TAM to the TEE, and for		responsible for relaying messages from the TAM to the TEE, and for
	returning the TEE's responses to the TAM. In devices with no REE,		returning the TEE's responses to the TAM. In devices with no REE
	the TEEP Broker would be absent and instead the TEEP protocol		(e.g., a microcontroller where all code runs in an environment
	transport would be implemented inside the TEE itself.		that meets the definition of a Trusted Execution Environment in
			Section 2), the TEEP Broker would be absent and instead the TEEP
			protocol transport would be implemented inside the TEE itself.
	- TEEP Agent: The TEEP Agent is a processing module running inside a		- TEEP Agent: The TEEP Agent is a processing module running inside a
	TEE that receives TAM requests (typically relayed via a TEEP		TEE that receives TAM requests (typically relayed via a TEEP
	Broker that runs in an REE). A TEEP Agent in the TEE may parse		Broker that runs in an REE). A TEEP Agent in the TEE may parse
	requests or forward requests to other processing modules in a TEE,		requests or forward requests to other processing modules in a TEE,
	which is up to a TEE provider's implementation. A response		which is up to a TEE provider's implementation. A response
	message corresponding to a TAM request is sent back to the TAM,		message corresponding to a TAM request is sent back to the TAM,
	again typically relayed via a TEEP Broker.		again typically relayed via a TEEP Broker.
	- Certification Authority (CA): Certificate-based credentials used		- Certification Authority (CA): Certificate-based credentials used
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 17 ¶
	resource usage.		resource usage.
	4.3. Multiple TAMs and Relationship to TAs		4.3. Multiple TAMs and Relationship to TAs
	As shown in Figure 2, a TEEP Broker provides communication between		As shown in Figure 2, a TEEP Broker provides communication between
	one or more TEEP Agents and one or more TAMs. The selection of which		one or more TEEP Agents and one or more TAMs. The selection of which
	TAM to communicate with might be made with or without input from an		TAM to communicate with might be made with or without input from an
	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 TA,
			whether that TA is installed (or minimally, is running) in a TEE with
			which the TEEP Agent is associated.
	Each TA is digitally signed, protecting its integrity, and linking		Each TA is digitally signed, protecting its integrity, and linking
	the TA back to the signer. The signer is usually the TA software		the TA back to the signer. The signer is usually the TA software
	author, but in some cases might be another party that the TA software		author, but in some cases might be another party that the TA software
	author trusts, or a party to whom the code has been licensed (in		author trusts, or a party to whom the code has been licensed (in
	which case the same code might be signed by multiple licensees and		which case the same code might be signed by multiple licensees and
	distributed as if it were different TAs).		distributed as if it were different TAs).
	A TA author or signer selects one or more TAMs through which to offer		A TA author or signer selects one or more TAMs through which to offer
	their TA(s), and communicates the TA(s) to the TAM. In this		their TA(s), and communicates the TA(s) to the TAM. In this
	document, we use the term "TA developer" to refer to the entity that		document, we use the term "TA developer" to refer to the entity that
	skipping to change at page 18, line 22 ¶		skipping to change at page 18, line 22 ¶
	Code Signing 1 per TA TA binary TEE		Code Signing 1 per TA TA binary TEE
	developer		developer
	Figure 4: Keys		Figure 4: Keys
	Note that personalization data is not included in the table above.		Note that personalization data is not included in the table above.
	The use of personalization data is dependent on how TAs are used and		The use of personalization data is dependent on how TAs are used and
	what their security requirements are.		what their security requirements are.
	The TEE key pair and certificate are used for authenticating the TEE		TEEP requests from a TAM to a TEEP Agent can be encrypted with the
	to a remote TAM. Often, the key pair is burned into the TEE by the		TEE public key (to provide confidentiality), and are then signed with
	TEE manufacturer and the key pair and its certificate are valid for		the TAM private key (for authentication and integrity protection).
	the expected lifetime of the TEE. A TAM provider is responsible for		Conversely, TEEP responses from a TEEP Agent to a TAM can be
	configuring the TAM's Trust Anchor Store with the manufacturer		encrypted with the TAM public key, and are then signed with the TEE
	certificates or CAs that are used to sign TEE keys. This is		private key.
	discussed further in Section 5.3 below.
			The TEE key pair and certificate are thus used for authenticating the
			TEE to a remote TAM, and for sending private data to the TEE. Often,
			the key pair is burned into the TEE by the TEE manufacturer and the
			key pair and its certificate are valid for the expected lifetime of
			the TEE. A TAM provider is responsible for configuring the TAM's
			Trust Anchor Store with the manufacturer certificates or CAs that are
			used to sign TEE keys. This is discussed further in Section 5.3
			below.
	The TAM key pair and certificate are used for authenticating a TAM to		The TAM key pair and certificate are used for authenticating a TAM to
	a remote TEE. A TAM provider is responsible for acquiring a		a remote TEE, and for sending private data to the TAM. A TAM
	certificate from a CA that is trusted by the TEEs it manages. This		provider is responsible for acquiring a certificate from a CA that is
	is discussed further in Section 5.1 below.		trusted by the TEEs it manages. This is discussed further in
			Section 5.1 below.
	The TA developer key pair and certificate are used to sign TAs that		The TA developer key pair and certificate are used to sign TAs that
	the TEE will consider authorized to execute. TEEs must be configured		the TEE will consider authorized to execute. TEEs must be configured
	with the certificates or keys that it considers authorized to sign		with the certificates or keys that it considers authorized to sign
	TAs that it will execute. This is discussed further in Section 5.2		TAs that it will execute. This is discussed further in Section 5.2
	below.		below.
	5.1. Trust Anchors in a TEEP Agent		5.1. Trust Anchors in a TEEP Agent
	A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors,		A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors,
	skipping to change at page 25, line 17 ¶		skipping to change at page 25, line 21 ¶
	9. Security Considerations		9. Security Considerations
	9.1. Broker Trust Model		9.1. Broker Trust Model
	The architecture enables the TAM to communicate, via a TEEP Broker,		The architecture enables the TAM to communicate, via a TEEP Broker,
	with the device's TEE to manage TAs. Since the TEEP Broker runs in a		with the device's TEE to manage TAs. Since the TEEP Broker runs in a
	potentially vulnerable REE, the TEEP Broker could, however, be (or be		potentially vulnerable REE, the TEEP Broker could, however, be (or be
	infected by) malware. As such, all TAM messages are signed and		infected by) malware. As such, all TAM messages are signed and
	sensitive data is encrypted such that the TEEP Broker cannot modify		sensitive data is encrypted such that the TEEP Broker cannot modify
	or capture sensitive data.		or capture sensitive data, but the TEEP Broker can still conduct DoS
			attacks as discussed in Section 9.3.
	A TEEP Agent in a TEE is responsible for protecting against potential		A TEEP Agent in a TEE is responsible for protecting against potential
	attacks from a compromised TEEP Broker or rogue malware in the REE.		attacks from a compromised TEEP Broker or rogue malware in the REE.
	A rogue TEEP Broker might send corrupted data to the TEEP Agent, or		A rogue TEEP Broker might send corrupted data to the TEEP Agent, or
	launch a DoS attack by sending a flood of TEEP protocol requests.		launch a DoS attack by sending a flood of TEEP protocol requests.
	The TEEP Agent validates the signature of each TEEP protocol request		The TEEP Agent validates the signature of each TEEP protocol request
	and checks the signing certificate against its Trust Anchors. To		and checks the signing certificate against its Trust Anchors. To
	mitigate DoS attacks, it might also add some protection scheme such		mitigate DoS attacks, it might also add some protection scheme such
	as a threshold on repeated requests or number of TAs that can be		as a threshold on repeated requests or number of TAs that can be
	installed.		installed.
	skipping to change at page 25, line 39 ¶		skipping to change at page 25, line 44 ¶
	9.2. Data Protection at TAM and TEE		9.2. Data Protection at TAM and TEE
	The TEE implementation provides protection of data on the device. It		The TEE implementation provides protection of data on the device. It
	is the responsibility of the TAM to protect data on its servers.		is the responsibility of the TAM to protect data on its servers.
	9.3. Compromised REE		9.3. Compromised REE
	It is possible that the REE of a device is compromised. If the REE		It is possible that the REE of a device is compromised. If the REE
	is compromised, several DoS attacks may be launched. The compromised		is compromised, several DoS attacks may be launched. The compromised
	REE may terminate the TEEP Broker such that TEEP transactions cannot		REE may terminate the TEEP Broker such that TEEP transactions cannot
	reach the TEE. However, while a DoS attack cannot be prevented, the		reach the TEE, or might drop or delay messages between a TAM and a
	REE cannot access anything in the TEE if it is implemented correctly.		TEEP Agent. However, while a DoS attack cannot be prevented, the REE
			cannot access anything in the TEE if it is implemented correctly.
	Some TEEs may have some watchdog scheme to observe REE state and		Some TEEs may have some watchdog scheme to observe REE state and
	mitigate DoS attacks against it but most TEEs don't have have such		mitigate DoS attacks against it but most TEEs don't have have such
	capability.		capability.
	In some other scenarios, the compromised REE may ask a TEEP Broker to		In some other scenarios, the compromised REE may ask a TEEP Broker to
	make repeated requests to a TEEP Agent in a TEE to install or		make repeated requests to a TEEP Agent in a TEE to install or
	uninstall a TA. A TA installation or uninstallation request		uninstall a TA. A TA installation or uninstallation request
	constructed by the TEEP Broker or REE will be rejected by the TEEP		constructed by the TEEP Broker or REE will be rejected by the TEEP
	Agent because the request won't have the correct signature from a TAM		Agent because the request won't have the correct signature from a TAM
	to pass the request signature validation.		to pass the request signature validation.
	skipping to change at page 27, line 7 ¶		skipping to change at page 27, line 9 ¶
	It may happen that a TA was previously considered trustworthy but is		It may happen that a TA was previously considered trustworthy but is
	later found to be buggy or compromised. In this case, the TAM can		later found to be buggy or compromised. In this case, the TAM can
	initiate the removal of the TA by notifying devices to remove the TA		initiate the removal of the TA by notifying devices to remove the TA
	(and potentially the REE or device owner to remove any Untrusted		(and potentially the REE or device owner to remove any Untrusted
	Application that depend on the TA). If the TAM does not currently		Application that depend on the TA). If the TAM does not currently
	have a connection to the TEEP Agent on a device, such a notification		have a connection to the TEEP Agent on a device, such a notification
	would occur the next time connectivity does exist.		would occur the next time connectivity does exist.
	Furthermore the policy in the Verifier in an attestation process can		Furthermore the policy in the Verifier in an attestation process can
	be updated so that any evidence that includes the malicious TA would		be updated so that any evidence that includes the malicious TA would
	result in an attestation failure.		result in an attestation failure. There is, however, a time window
			during which a malicious TA might be able to operate successfully,
			which is the validity time of the previous attestation result. For
			example, if the Verifier in Figure 5 is updated to treat a previously
			valid TA as no longer trustworthy, any attestation result it
			previously generated saying that the TA is valid will continue to be
			used until the attestation result expires. As such, the TAM's
			Verifier should take into account the acceptable time window when
			generating attestation results. See [I-D.ietf-rats-architecture] for
			further discussion.
	9.7. Certificate Renewal		9.7. Certificate Renewal
	TEE device certificates are expected to be long lived, longer than		TEE device certificates are expected to be long lived, longer than
	the lifetime of a device. A TAM certificate usually has a moderate		the lifetime of a device. A TAM certificate usually has a moderate
	lifetime of 2 to 5 years. A TAM should get renewed or rekeyed		lifetime of 2 to 5 years. A TAM should get renewed or rekeyed
	certificates. The root CA certificates for a TAM, which are embedded		certificates. The root CA certificates for a TAM, which are embedded
	into the Trust Anchor store in a device, should have long lifetimes		into the Trust Anchor store in a device, should have long lifetimes
	that don't require device Trust Anchor update. On the other hand, it		that don't require device Trust Anchor update. On the other hand, it
	is imperative that OEMs or device providers plan for support of Trust		is imperative that OEMs or device providers plan for support of Trust
	skipping to change at page 28, line 27 ¶		skipping to change at page 28, line 44 ¶
	[I-D.ietf-suit-manifest]		[I-D.ietf-suit-manifest]
	Moran, B., Tschofenig, H., and H. Birkholz, "A Concise		Moran, B., Tschofenig, H., and H. Birkholz, "A Concise
	Binary Object Representation (CBOR)-based Serialization		Binary Object Representation (CBOR)-based Serialization
	Format for the Software Updates for Internet of Things		Format for the Software Updates for Internet of Things
	(SUIT) Manifest", draft-ietf-suit-manifest-03 (work in		(SUIT) Manifest", draft-ietf-suit-manifest-03 (work in
	progress), February 2020.		progress), February 2020.
	[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-03 (work in progress),		draft-ietf-teep-otrp-over-http-04 (work in progress),
	November 2019.		February 2020.
	[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management		[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
	Requirements", RFC 6024, DOI 10.17487/RFC6024, October		Requirements", RFC 6024, DOI 10.17487/RFC6024, October
	2010, <https://www.rfc-editor.org/info/rfc6024>.		2010, <https://www.rfc-editor.org/info/rfc6024>.
	[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm		[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",		Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.		<https://www.rfc-editor.org/info/rfc7696>.
End of changes. 18 change blocks.
	31 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/