draft-ietf-teep-architecture-16.txt   draft-ietf-teep-architecture-17.txt 
TEEP M. Pei TEEP M. Pei
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: 1 September 2022 Arm Limited Expires: 21 October 2022 Arm Limited
D. Thaler D. Thaler
Microsoft Microsoft
D. Wheeler D. Wheeler
Amazon Amazon
28 February 2022 19 April 2022
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-16 draft-ietf-teep-architecture-17
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 1 September 2022. This Internet-Draft will expire on 21 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . 9 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. System Components . . . . . . . . . . . . . . . . . . . . 9 4.1. System Components . . . . . . . . . . . . . . . . . . . . 9
4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11
4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13
4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 15 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 15
4.4.1. Example: Application Delivery Mechanisms in Intel 4.4.1. Example: Application Delivery Mechanisms in Intel
SGX . . . . . . . . . . . . . . . . . . . . . . . . . 16 SGX . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2. Example: Application Delivery Mechanisms in Arm 4.4.2. Example: Application Delivery Mechanisms in Arm
TrustZone . . . . . . . . . . . . . . . . . . . . . . 17 TrustZone . . . . . . . . . . . . . . . . . . . . . . 17
4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 2, line 50 skipping to change at page 2, line 50
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 . . . . . . . . . . . . . . 28 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28
9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 29 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 29
9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 30 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 30
9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 31 9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 31
9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 31 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 31
9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 31 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 31
9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 32 9.7. TEE Certificate Expiry and Renewal . . . . . . . . . . . 32
9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 33 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 33
9.9. REE Privacy . . . . . . . . . . . . . . . . . . . . . . . 33 9.9. REE Privacy . . . . . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
13. Informative References . . . . . . . . . . . . . . . . . . . 34 13. Informative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
skipping to change at page 4, line 14 skipping to change at page 4, line 14
TEEs are typically used in cases where a software or data asset needs TEEs are typically used in cases where a software or data asset needs
to be protected from unauthorized entities that may include the owner to be protected from unauthorized entities that may include the owner
(or pwner) or possesser of a device. This situation arises for (or pwner) or possesser of a device. This situation arises for
example in gaming consoles where anti-cheat protection is a concern, example in gaming consoles where anti-cheat protection is a concern,
devices such as ATMs or IoT devices placed in locations where devices such as ATMs or IoT devices placed in locations where
attackers might have physical access, cell phones or other devices attackers might have physical access, cell phones or other devices
used for mobile payments, and hosted cloud environments. Such used for mobile payments, and hosted cloud environments. Such
environments can be thought of as hybrid devices where one user or environments can be thought of as hybrid devices where one user or
administrator controls the REE and a different (remote) user or administrator controls the REE and a different (remote) user or
administrator controls a TEE in the same physical device. It may administrator controls a TEE in the same physical device.
also be the case in some constrained devices that there is no REE It may also be the case in some constrained devices that there is no
(only a TEE) and there may be no local "user" per se, only a remote REE (only a TEE) and there may be no local "user" per se, only a
TEE administrator. For further discussion of such confidential remote TEE administrator. For further discussion of such
computing use cases and threat model, see [CC-Overview] and confidential computing use cases and threat model, see [CC-Overview]
[CC-Technical-Analysis]. and [CC-Technical-Analysis].
TEEs use hardware enforcement combined with software protection to TEEs use hardware enforcement combined with software protection to
secure TAs and its data. TEEs typically offer a more limited set of secure TAs and its data. TEEs typically offer a more limited set of
services to TAs than is normally available to Untrusted Applications. services to TAs than is normally available to Untrusted Applications.
Not all TEEs are the same, however, and different vendors may have Not all TEEs are the same, however, and different vendors may have
different implementations of TEEs with different security properties, different implementations of TEEs with different security properties,
different features, and different control mechanisms to operate on different features, and different control mechanisms to operate on
TAs. Some vendors may themselves market multiple different TEEs with TAs. Some vendors may themselves market multiple different TEEs with
different properties attuned to different markets. A device vendor different properties attuned to different markets. A device vendor
skipping to change at page 5, line 32 skipping to change at page 5, line 32
the TEE. the TEE.
* A Device Administrator wants to remove a TA from a device's TEE if * A Device Administrator wants to remove a TA from a device's TEE if
the TA developer is no longer maintaining that TA, when the TA has the TA developer is no longer maintaining that TA, when the TA has
been revoked, or is not used for other reasons anymore (e.g., due been revoked, or is not used for other reasons anymore (e.g., due
to an expired subscription). to an expired subscription).
For TEEs that simply verify and load signed TA's from an untrusted For TEEs that simply verify and load signed TA's from an untrusted
filesystem, classic application distribution protocols can be used filesystem, classic application distribution protocols can be used
without modification. The problems in the bullets above, on the without modification. The problems in the bullets above, on the
other hand, require a new protocol, i.e., the TEEP protocol, for TEEs other hand, require a new protocol, i.e., the TEEP protocol. The
that can install and enumerate TAs in a TEE-secured location and TEEP protocol is a solution for TEEs that can install and enumerate
where another domain-specific protocol standard (e.g., [GSMA], TAs in a TEE-secured location where another domain-specific protocol
[OTRP]) that meets the needs is not already in use. standard (e.g., [GSMA], [OTRP]) that meets the needs is not already
in use.
2. Terminology 2. Terminology
The following terms are used: The following terms are used:
* App Store: An online location from which Untrusted Applications
can be downloaded.
* Device: A physical piece of hardware that hosts one or more TEEs, * Device: A physical piece of hardware that hosts one or more TEEs,
often along with an REE. often along with an REE.
* Device Administrator: An entity that is responsible for * Device Administrator: An entity that is responsible for
administration of a device, which could be the Device Owner. A administration of a device, which could be the Device Owner. A
Device Administrator has privileges on the device to install and Device Administrator has privileges on the device to install and
remove Untrusted Applications and TAs, approve or reject Trust remove Untrusted Applications and TAs, approve or reject Trust
Anchors, and approve or reject TA developers, among possibly other Anchors, and approve or reject TA developers, among possibly other
privileges on the device. A Device Administrator can manage the privileges on the device. A Device Administrator can manage the
list of allowed TAMs by modifying the list of Trust Anchors on the list of allowed TAMs by modifying the list of Trust Anchors on the
skipping to change at page 7, line 11 skipping to change at page 7, line 4
and hypervisors; it is outside of the TEE(s) managed by the TEEP and hypervisors; it is outside of the TEE(s) managed by the TEEP
protocol. This environment and applications running on it are protocol. This environment and applications running on it are
considered untrusted (or more precisely, less trusted than a TEE). considered untrusted (or more precisely, less trusted than a TEE).
* Trust Anchor: As defined in [RFC6024] and * Trust Anchor: As defined in [RFC6024] and
[I-D.ietf-suit-architecture], "A trust anchor represents an [I-D.ietf-suit-architecture], "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. a certificate, a raw public key or other structure, as
appropriate. It can be a non-root certificate when it is a
certificate.
* Trust Anchor Store: As defined in [RFC6024], "A trust anchor store * Trust Anchor Store: As defined in [RFC6024], "A trust anchor store
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-architecture], a Trust Anchor Store must resist [I-D.ietf-suit-architecture], 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
skipping to change at page 8, line 41 skipping to change at page 8, line 38
3.2. Authentication 3.2. Authentication
For better security of authentication, a device may store its keys For better security of authentication, a device may store its keys
and cryptographic libraries inside a TEE limiting access to and cryptographic libraries inside a TEE limiting access to
cryptographic functions via a well-defined interface and thereby cryptographic functions via a well-defined interface and thereby
reducing access to keying material. reducing access to keying material.
3.3. Internet of Things 3.3. Internet of Things
Weak security in Internet of Things (IoT) devices has been posing Weak security in Internet of Things (IoT) devices has been posing
threats to critical infrastructure that relies upon such devices. It threats to critical infrastructure, i.e., assets that are essential
is desirable that IoT devices can prevent malware from manipulating for the functioning of a society and economy. It is desirable that
actuators (e.g., unlocking a door), or stealing or modifying IoT devices can prevent malware from manipulating actuators (e.g.,
sensitive data, such as authentication credentials in the device. A unlocking a door), or stealing or modifying sensitive data, such as
TEE can be the best way to implement such IoT security functions. authentication credentials in the device. A TEE can be the best way
to implement such IoT security functions.
3.4. Confidential Cloud Computing 3.4. Confidential Cloud Computing
A tenant can store sensitive data, such as customer details or credit A tenant can store sensitive data, such as customer details or credit
card numbers, in a TEE in a cloud computing server such that only the card numbers, in a TEE in a cloud computing server such that only the
tenant can access the data, preventing the cloud hosting provider tenant can access the data, preventing the cloud hosting provider
from accessing the data. A tenant can run TAs inside a server TEE from accessing the data. A tenant can run TAs inside a server TEE
for secure operation and enhanced data security. This provides for secure operation and enhanced data security. This provides
benefits not only to tenants with better data security but also to benefits not only to tenants with better data security but also to
cloud hosting providers for reduced liability and increased cloud cloud hosting providers for reduced liability and increased cloud
skipping to change at page 15, line 24 skipping to change at page 15, line 24
Untrusted Application in an REE and one or more TAs in a TEE, as Untrusted Application in an REE and one or more TAs in a TEE, as
shown in Figure 2. For most purposes, an Untrusted Application that shown in Figure 2. For most purposes, an Untrusted Application that
uses one or more TAs in a TEE appears no different from any other uses one or more TAs in a TEE appears no different from any other
Untrusted Application in the REE. However, the way the Untrusted Untrusted Application in the REE. However, the way the Untrusted
Application and its corresponding TAs are packaged, delivered, and Application and its corresponding TAs are packaged, delivered, and
installed on the device can vary. The variations depend on whether installed on the device can vary. The variations depend on whether
the Untrusted Application and TA are bundled together or are provided the Untrusted Application and TA are bundled together or are provided
separately, and this has implications to the management of the TAs in separately, and this has implications to the management of the TAs in
a TEE. In addition to the Untrusted Application and TA(s), the TA(s) a TEE. In addition to the Untrusted Application and TA(s), the TA(s)
and/or TEE may also require additional data to personalize the TA to and/or TEE may also require additional data to personalize the TA to
the device or a user. Implementations must support encryption of the device or a user. Implementations must support encryption to
such Personalization Data to preserve the confidentiality of preserve the confidentiality and integrity of such Personalized Data,
potentially sensitive data contained within it, and must support which may potentially contain sensitive data. Other than the
integrity protection of the Personalization Data. Other than the
requirement to support confidentiality and integrity protection, the requirement to support confidentiality and integrity protection, the
TEEP architecture places no limitations or requirements on the TEEP architecture places no limitations or requirements on the
Personalization Data. Personalization Data.
There are multiple possible cases for bundling of an Untrusted There are multiple possible cases for bundling of an Untrusted
Application, TA(s), and Personalization Data. Such cases include Application, TA(s), and Personalization Data. Such cases include
(possibly among others): (possibly among others):
1. The Untrusted Application, TA(s), and Personalization Data are 1. The Untrusted Application, TA(s), and Personalization Data are
all bundled together in a single package by a Trusted Component all bundled together in a single package by a Trusted Component
skipping to change at page 30, line 20 skipping to change at page 30, line 20
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 with billions already seen examples of attacks on the public Internet with 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.
The compromised REE may terminate the TEEP Broker such that TEEP The compromised REE may terminate the TEEP Broker such that TEEP
transactions cannot reach the TEE, or might drop or delay messages transactions cannot reach the TEE, or might drop, replay, or delay
between a TAM and a TEEP Agent. However, while a DoS attack cannot messages between a TAM and a TEEP Agent. However, while a DoS attack
be prevented, the REE cannot access anything in the TEE if the TEE is cannot be prevented, the REE cannot access anything in the TEE if the
implemented correctly. Some TEEs may have some watchdog scheme to TEE is implemented correctly. Some TEEs may have some watchdog
observe REE state and mitigate DoS attacks against it but most TEEs scheme to observe REE state and mitigate DoS attacks against it but
don't have such a capability. most TEEs don't have such a 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 Trusted Component. An installation or uninstallation uninstall a Trusted Component. An installation or uninstallation
request constructed by the TEEP Broker or REE will be rejected by the request constructed by the TEEP Broker or REE will be rejected by the
TEEP Agent because the request won't have the correct signature from TEEP Agent because the request won't have the correct signature from
a TAM to pass the request signature validation. a TAM to pass the request signature validation.
This can become a DoS attack by exhausting resources in a TEE with This can become a DoS attack by exhausting resources in a TEE with
repeated requests. In general, a DoS attack threat exists when the repeated requests. In general, a DoS attack threat exists when the
skipping to change at page 32, line 34 skipping to change at page 32, line 34
during which a malicious TA might be able to operate successfully, during which a malicious TA might be able to operate successfully,
which is the validity time of the previous attestation result. For which is the validity time of the previous attestation result. For
example, if the Verifier in Figure 6 is updated to treat a previously example, if the Verifier in Figure 6 is updated to treat a previously
valid TA as no longer trustworthy, any attestation result it valid TA as no longer trustworthy, any attestation result it
previously generated saying that the TA is valid will continue to be previously generated saying that the TA is valid will continue to be
used until the attestation result expires. As such, the TAM's used until the attestation result expires. As such, the TAM's
Verifier should take into account the acceptable time window when Verifier should take into account the acceptable time window when
generating attestation results. See [I-D.ietf-rats-architecture] for generating attestation results. See [I-D.ietf-rats-architecture] for
further discussion. further discussion.
9.7. Certificate Expiry and Renewal 9.7. TEE Certificate Expiry and 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 updates. On the other hand, that don't require device Trust Anchor updates. On the other hand,
it is imperative that OEMs or device providers plan for support of it is imperative that OEMs or device providers plan for support of
Trust Anchor update in their shipped devices. Trust Anchor update in their shipped devices.
skipping to change at page 35, line 40 skipping to change at page 35, line 40
Environment Provisioning: Agent Initiated Communication", Environment Provisioning: Agent Initiated Communication",
Work in Progress, Internet-Draft, draft-ietf-teep-otrp- Work in Progress, Internet-Draft, draft-ietf-teep-otrp-
over-http-13, 28 February 2022, over-http-13, 28 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-teep-otrp- <https://www.ietf.org/archive/id/draft-ietf-teep-otrp-
over-http-13.txt>. over-http-13.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", Work in Progress, Internet-Draft, draft- (TEEP) Protocol", Work in Progress, Internet-Draft, draft-
ietf-teep-protocol-07, 25 October 2021, ietf-teep-protocol-08, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-teep-protocol- <https://www.ietf.org/archive/id/draft-ietf-teep-protocol-
07.txt>. 08.txt>.
[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>.
 End of changes. 17 change blocks. 
38 lines changed or deleted 44 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/