<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.6 (Ruby 2.6.8) -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<?rfc rfcedstyle="yes"?>
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.6 (Ruby 2.6.8) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-teep-architecture-19" number="9397" submissionType="IETF" category="info" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.3 -->
  <front>
    <title abbrev="TEEP Architecture">Trusted Execution Environment Provisioning (TEEP) Architecture</title>
    <seriesInfo name="RFC" value="9397"/>
    <author initials="M." surname="Pei" fullname="Mingliang Pei">
      <organization>Broadcom</organization>
      <address>
        <email>mingliang.pei@broadcom.com</email>
      </address>
    </author>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Arm Limited</organization>
      <organization></organization>
      <address>
        <email>hannes.tschofenig@arm.com</email>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>
    <author initials="D." surname="Thaler" fullname="Dave Thaler">
      <organization>Microsoft</organization>
      <address>
        <email>dthaler@microsoft.com</email>
      </address>
    </author>
    <author initials="D." surname="Wheeler" fullname="David Wheeler">
      <organization>Amazon</organization>
      <address>
        <email>davewhee@amazon.com</email>
      </address>
    </author>
    <date year="2022" month="October" day="24"/>

    <area>Security</area>
    <workgroup>TEEP</workgroup>
    <keyword>Internet-Draft</keyword> year="2023" month="July"/>
    <area>sec</area>
    <workgroup>teep</workgroup>

    <abstract>

<t>A

<t>
A Trusted Execution Environment (TEE) is an environment that
enforces that the following: any code within that the environment cannot be tampered
with, and that any data used by such code cannot be read or tampered with by any
code outside that the environment.
This architecture document motivates discusses the design motivation for designing and standardization
of
standardizing a protocol for managing
the lifecycle of trusted applications Trusted Applications running inside such a TEE.</t> TEE.
</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>Applications executing in a device are exposed to many different attacks
intended to compromise the execution of the application or reveal the
data upon which those applications are operating. These attacks increase
with the number of other applications on the device, with such other
applications coming from potentially untrustworthy sources. The
potential for attacks further increases with the complexity of features
and applications on devices, devices and the unintended interactions among those
features and applications. The risk of attacks on a system increases
as the sensitivity of the applications or data on the device increases.
As an example, exposure of emails from a mail client is likely to be of
concern to its owner, but a compromise of a banking application raises
even greater concerns.</t>

<t>The
      <t>
The Trusted Execution Environment (TEE) concept is designed to let
applications execute in a protected environment that enforces that any code within that
environment cannot be tampered with, with and that any data used by such code
cannot be read or tampered with by any code outside that environment,
including by a commodity operating system (if present).  In a system with
multiple TEEs, this also means that code in one TEE cannot be read or tampered
with by code in another TEE.</t>
      <t>This separation reduces the possibility
of a successful attack on application components and the data contained inside the
TEE. Typically, application components are chosen to execute inside a TEE because
those application components perform security sensitive security-sensitive operations or operate on
sensitive data. An application component running inside a TEE is commonly referred to
(e.g., in <xref target="GPTEE"/>, target="GPTEE"/> and <xref target="OP-TEE"/>, etc.) target="OP-TEE"/>) as a
Trusted Application (TA), while an application running outside any TEE, i.e., in the
Rich Execution Environment (REE),
is referred to as an Untrusted Application (UA).
In the example of a banking application,
code that relates to the authentication protocol could reside in a TA while the
application logic including HTTP protocol parsing could be contained in the
Untrusted Application.  In addition, processing of credit card numbers or account balances could be done in a TA as it is sensitive data.
The precise code split is ultimately a decision of the
developer based on the assets the person wants to protect according to the threat model.</t>
      <t>TEEs are typically used in cases where software or data assets need to be protected from unauthorized access
where threat actors may have physical or administrative access to a device.
This situation arises arises, for example example, in gaming consoles where anti-cheat
protection is a concern, devices such as ATMs or IoT devices placed in
locations where attackers might have physical access, cell phones or other
devices used for mobile payments, and hosted cloud environments.  Such
environments can be thought of as hybrid devices where one user or
administrator controls the REE and a different (remote) user or administrator
controls a TEE in the same physical device.<br />
It device. In
some constrained devices, it may also be the case in some constrained devices that there is no REE (only a TEE) and there
may be no
local "user" per se, but only a remote TEE administrator.  For further discussion
of such confidential computing use cases and threat model, see <xref
target="CC-Overview"/> and <xref target="CC-Technical-Analysis"/>.</t>
      <t>TEEs use hardware enforcement combined with software protection to secure TAs and
their data. TEEs typically offer a more limited set of services to TAs than what is
normally available to Untrusted Applications.</t>

<t>Not
      <t>However, not all TEEs are the same, however, and different same. Different vendors may have different
implementations of TEEs with different security properties, different features, and different control mechanisms to operate on TAs.
Some
vendors may themselves market multiple different TEEs themselves, with different
properties attuned to different markets. A device vendor may integrate
one or more TEEs into their devices depending on market needs.</t>
      <t>To simplify the life of TA developers interacting
with TAs in a TEE, an interoperable protocol for managing TAs running in
different TEEs of various devices is needed. This software update protocol
needs to make sure that compatible trusted and untrusted components Untrusted Components (if any) of an
application are installed on the correct device. In this TEE ecosystem,
there
the need often arises a need for an external trusted party to verify the
identity, claims, and permissions of TA developers, devices, and their TEEs.
This external trusted party is the Trusted Application Manager (TAM).</t>
      <t>The Trusted Execution Environment Provisioning (TEEP) protocol addresses
the following problems:</t>

<t><list style="symbols">
  <t>An
      <ul spacing="normal">
        <li>An installer of an Untrusted Application that depends on a given TA
wants to request installation of that TA in the device's TEE
so that the installation of the Untrusted Application can complete, but the TEE
needs to verify whether such a TA is actually authorized to
run in the TEE and consume potentially scarce TEE resources.</t>
  <t>A resources.</li>
        <li>A TA developer providing a TA whose code itself is considered
confidential wants to determine
security-relevant information of a device before allowing their
TA to be provisioned to the TEE within the device. An example
is the verification of
the type of TEE included in a device and that it is capable its capability of
providing the security protections required.</t>
  <t>A required.</li>
        <li>A TEE in a device needs to determine whether an entity
that wants to manage a TA in the device is authorized to manage TAs
in the TEE, TEE and what TAs the entity is permitted to manage.</t>
  <t>A manage.</li>

<li>A Device Administrator wants to determine if a TA exists (is
installed) on a device (in
(i.e., is installed in the TEE), and TEE) and, if not, install the TA in the TEE.</t>
  <t>A TEE.
</li>
        <li>A Device Administrator wants to check whether a TA in a
device's TEE is the most up-to-date version, and if not, update the
TA in the TEE.</t>
  <t>A TEE.</li>
        <li>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
been revoked, or if the TA is not used for other reasons anymore (e.g., due to an
expired subscription).</t>
</list></t> subscription).</li>
      </ul>
      <t>For TEEs that simply verify and load signed TA's TAs from an untrusted
filesystem, classic application distribution protocols can be used
without modification.  The  On the other hand, the problems listed in the bullets above, on the other hand, above
require a new protocol, i.e., protocol -- the TEEP protocol. The TEEP protocol is
a solution for TEEs that can install and enumerate TAs in a TEE-secured
location where another domain-specific protocol standard (e.g., <xref target="GSMA"/>, target="GSMA"/> and <xref target="OTRP"/>) that meets the needs is not already in use.</t>
    </section>
    <section anchor="terminology"><name>Terminology</name> anchor="terminology">
      <name>Terminology</name>
      <t>The following terms are used:</t>

<t><list style="symbols">
  <t>App Store: An
<dl newline="false" spacing="normal">
        <dt>App Store:</dt><dd>An online location from which Untrusted Applications can be downloaded.</t>
  <t>Device: A downloaded.</dd>
        <dt>Device:</dt><dd>A physical piece of hardware that hosts one or more TEEs,
often along with
an REE.</t>
  <t>Device Administrator:  An REE.</dd>
        <dt>Device Administrator:</dt><dd>An entity that is responsible for administration
of a device, which could be the Device Owner. A Device Administrator
has privileges on the device to install and remove Untrusted Applications and TAs,
approve or reject Trust Anchors, and approve or reject TA developers,
among possibly other possible privileges on the device. A Device Administrator can
manage the list of allowed TAMs by modifying the list of Trust
Anchors on the device. Although a Device Administrator may have
privileges and device-specific controls to locally administer a
device, the Device Administrator may choose to remotely
administer a device through a TAM.</t>
  <t>Device Owner: A TAM.</dd>
        <dt>Device Owner:</dt><dd>A device is always owned by someone. In some cases, it is common for
the (primary) device user to also own the device, making the device
user/owner also the Device Administrator. In enterprise environments environments,
it is more common for the enterprise to own the device, device and for any device
user to have no or limited administration rights. In this case, the
enterprise appoints a Device Administrator that is not the device
owner.</t>
  <t>Device User: A Device
Owner.</dd>
        <dt>Device User:</dt><dd>A human being that uses a device. Many devices have
a single device user. Some devices have a primary device user with
other human beings as secondary device users (e.g., a parent allowing
children to use their tablet or laptop). Other devices are not used
by a human being and hence being; hence, they have no device user.</t>
  <t>Personalization Data: A user.</dd>
        <dt>Personalization Data:</dt><dd>A set of configuration data that is specific to
   the device or user. The Personalization Data may depend on the type of
   TEE, a particular TEE instance, the TA, and even the user of the device;
   an device.
   An example of Personalization Data might be a secret symmetric key used
   by a TA to communicate with some service.</t>
  <t>Raw service.</dd>
        <dt>Raw Public Key: A Key:</dt><dd>A raw public key consists of only the algorithm identifier
(type) of the key and the cryptographic public key material, such as the
SubjectPublicKeyInfo structure of a PKIX certificate <xref target="RFC5280"/>. Other
serialization formats that do not rely on ASN.1 may also be used.</t>
  <t>Rich used.</dd>
        <dt>Rich Execution Environment (REE): An (REE):</dt><dd>An environment that is provided
and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of the TEE(s) managed by the TEEP protocol. This environment and
applications running on it are considered untrusted (or more precisely,
less trusted than a TEE).</t>
  <t>Trust Anchor: As TEE).</dd>
        <dt>Trust Anchor:</dt><dd>As defined in <xref target="RFC6024"/> and <xref target="RFC9019"/>,
"A trust anchor represents
a Trust Anchor "represents an authoritative entity via a public
key and associated data.  The public key is used to verify digital
signatures, and the associated data is used to constrain the types
of information for which the trust anchor is authoritative."
The Trust Anchor may be a certificate, a raw public key key, or other structure,
as appropriate. It can be a non-root certificate when it is a certificate.</t>
  <t>Trust certificate.</dd>
        <dt>Trust Anchor Store: As Store:</dt><dd>As defined in <xref
        target="RFC6024"/>, "A trust a "trust anchor store 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 may be used by one or more
        applications."  As noted in <xref target="RFC9019"/>,
a Trust Anchor Store "a trust anchor
        store must resist modification against unauthorized insertion,
        deletion, and modification.</t>
  <t>Trusted modification."</dd>
	<dt>Trusted
        Application (TA): An (TA):</dt><dd>An application (or, in some implementations,
        an application component) that runs in a TEE.</t>
  <t>Trusted TEE.</dd>
        <dt>Trusted Application Manager (TAM): An (TAM):</dt><dd>An entity that manages Trusted Applications and other Trusted Components running in TEEs of various devices.</t>
  <t>Trusted Component: A devices.</dd>
        <dt>Trusted Component:</dt><dd>A set of code and/or data in a TEE managed as a unit
by a Trusted Application Manager.  Trusted Applications and
Personalization Data are thus managed by being included in
Trusted Components.  Trusted OS code or trusted firmware can also be
expressed as Trusted Components that a Trusted Component depends on.</t>
  <t>Trusted on.</dd>
        <dt>Trusted Component Developer: An Developer:</dt><dd>An entity that develops one or
more Trusted Components.</t>
  <t>Trusted Components.</dd>
        <dt>Trusted Component Signer: An Signer:</dt><dd>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, encrypted
if the code is considered confidential, for example, when a developer wants to
provide a TA without revealing its code to others.</t>
  <t>Trusted others.</dd>

<dt>Trusted Execution Environment (TEE): An (TEE):</dt><dd>An execution environment that enforces that
only authorized code can execute within the TEE, TEE and data used by that
code cannot be read or tampered with by code outside the TEE.
A TEE also generally has a device unique device  credential that cannot be cloned.
There are multiple technologies that can be used to implement
a TEE, and the level of security achieved varies accordingly.
In addition, TEEs typically use an isolation mechanism between Trusted Applications to ensure
that one TA cannot read, modify modify, or delete the data and code of another
TA.</t>
  <t>Untrusted
TA.</dd>
        <dt>Untrusted Application (UA): An (UA):</dt><dd>An application running in an REE. An Untrusted Application
might depend on one or more TAs.</t>
</list></t> TAs.</dd>
      </dl>
    </section>
    <section anchor="use-cases"><name>Use anchor="use-cases">
      <name>Use Cases</name>
      <section anchor="payment"><name>Payment</name> anchor="payment">
        <name>Payment</name>
        <t>A payment application in a mobile device requires high security and
trust in the hosting device. Payments initiated from a mobile
device can use a Trusted Application
to provide strong identification and proof of transaction.</t>
        <t>For a mobile payment application, some biometric identification
information could also be stored in a TEE. The mobile payment
application can use such information for unlocking the device and
for local identification of the user.</t>
        <t>A trusted user interface (UI) may be used in a mobile device or point-of-sale device to
prevent malicious software from stealing sensitive user input data.
Such an implementation often relies on a TEE for providing access
to peripherals, such as PIN input or a trusted display, so that
the REE cannot observe or tamper with the user input or output.</t>
      </section>
      <section anchor="authentication"><name>Authentication</name> anchor="authentication">
        <name>Authentication</name>
        <t>For better security of authentication, a device may store its
keys and cryptographic libraries inside a TEE TEE, limiting access to
cryptographic functions via a well-defined interface and thereby
reducing access to keying material.</t>
      </section>
      <section anchor="internet-of-things"><name>Internet anchor="internet-of-things">
        <name>Internet of Things</name>
        <t>Weak security in Internet of Things (IoT) devices has been posing threats to
critical infrastructure, i.e., assets that are essential for the functioning
of a society and economy. It is desirable that IoT devices can prevent malware
from manipulating actuators (e.g., unlocking a door), door) or
stealing or modifying sensitive data, such as authentication credentials
in the device. A TEE can be one of the best ways to implement such IoT
security functions. For example, <xref target="GPTEE"/> uses the term "trusted peripheral" to refer to such things being
accessible only from the TEE, and this concept is used, and this concept is used in some GlobalPlatform-compliant devices today.</t>
      </section>
      <section anchor="confidential-cloud-computing"><name>Confidential anchor="confidential-cloud-computing">
        <name>Confidential Cloud Computing</name>
        <t>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 tenant can access the data, preventing which prevents
the cloud hosting provider from accessing the data. A tenant can
run TAs inside a server TEE for secure operation and enhanced
data security. This provides benefits not only to tenants with
better data security but also to cloud hosting providers for reduced
liability and increased cloud adoption.</t>
      </section>
    </section>
    <section anchor="architecture"><name>Architecture</name> anchor="architecture">
      <name>Architecture</name>
      <section anchor="system-components"><name>System anchor="system-components">
        <name>System Components</name>
        <t><xref target="notionalarch"/> shows the main components in a typical device with an REE and a
TEE. Full descriptions of
components not previously defined are provided below. Interactions of
all components are further explained in the following paragraphs.</t>
        <figure title="Notional anchor="notionalarch">
          <name>Notional Architecture of TEEP" anchor="notionalarch"><artwork><![CDATA[ TEEP</name>
          <artwork><![CDATA[
+---------------------------------------------+
| Device                                      |     Trusted Component
|                          +--------+         |               Signer
|    +---------------+     |        |--------------+              |
|    | TEE-1         |     | TEEP   |-----------+  |              |
|    | +--------+    |  +--| Broker |         | |  |   +-------+  |
|    | | TEEP   |    |  |  |        |<-----+  | |  +-->|       |<-+
|    | | Agent  |<------+  |        |      |  | |    +-| TAM-1 |
|    | +--------+    |     |        |<---+ |  | +--->| |       |<-+
|    |               |     +--------+    | |  |      | +-------+  |
|    | +----+ +----+ |                   | |  |      | TAM-2 |    |
|  +-->|TA-1| |TA-2| |        +-------+  | |  |      +-------+    |
|  | | |    | |    |<---------| UA-2  |--+ |  |                   |
|  | | +----+ +----+ |  +-------+     |    |  |               Device
|  | +---------------+  | UA-1  |     |    |  |         Administrator
|  |                    |       |     |    |  |
|  +--------------------|       |-----+    |  |
|                       |       |----------+  |
|                       +-------+             |
+---------------------------------------------+
]]></artwork></figure>

<t><list style="symbols">
  <t>Trusted
]]></artwork>
        </figure>

<dl newline="false" spacing="normal">
	  <dt>Trusted Component Signer and Device Administrator:</dt><dd>Trusted Component Signers and Device Administrators utilize the services
of a TAM to manage TAs on devices. Trusted Component Signers do not directly interact
with devices. Device Administrators may elect to use a TAM for remote administration
of TAs instead of managing each device directly.</t>
  <t>Trusted directly.</dd>

            <dt>Trusted Application Manager (TAM):  A (TAM):</dt><dd><t>A TAM is responsible for
            performing lifecycle management activity on Trusted Components on
            behalf of Trusted Component Signers and Device Administrators.
            This includes installation and deletion of Trusted Components, Components and
            may include, for example, over-the-air updates to keep Trusted
            Components up-to-date and clean up when Trusted Components should
            be removed. TAMs may provide services that make it easier for
            Trusted Component Signers or Device Administrators to use the
            TAM's service to manage multiple devices, although that is not
            required of a TAM.  <vspace blankLines='1'/> TAM.</t>

<t>
The TAM performs its management of Trusted Components on the device through
interactions with a device's TEEP Broker, which relays
messages between a TAM and a TEEP Agent running inside the TEE.
TEEP authentication is performed between a TAM and a TEEP Agent.  <vspace blankLines='1'/> </t>
            <t>
When the TEEP Agent runs in a user or enterprise device, network and application firewalls
normally protect user and enterprise devices from arbitrary connections from external network
entities. In such a deployment, a TAM outside that network might not be able to directly
contact a TEEP Agent, Agent but needs to wait for the TEEP Broker to contact it.
The architecture in <xref target="notionalarch"/> accommodates this case as well as other less restrictive cases
by leaving such details to an appropriate TEEP transport protocol (e.g., <xref target="I-D.ietf-teep-otrp-over-http"/>,
though other transport protocols can be defined under the TEEP protocol for other cases).  <vspace blankLines='1'/>  </t>
            <t>
A TAM may be publicly available for use by many Trusted Component Signers, or a TAM
may be private, private and accessible by only one or a limited number of
Trusted Component Signers. It is expected that many enterprises, manufacturers, and network carriers
will run their own private TAM.  <vspace blankLines='1'/> TAM.</t>
            <t>
A Trusted Component Signer or Device Administrator chooses a particular TAM based on
whether the TAM is trusted by a device or set of devices. The
TAM is trusted by a device if the TAM's public key is, or chains up to,
an authorized Trust Anchor in the device, device and conforms with all constraints defined in
the Trust Anchor. A Trusted Component Signer or Device Administrator may run
their own TAM, but the devices they wish to manage must include
this TAM's public key or certificate, or a certificate it chains up to, in the
Trust Anchor Store.  <vspace blankLines='1'/> Store.</t>
            <t>
A Trusted Component Signer or Device Administrator is free to utilize multiple TAMs. This may
be required for managing Trusted Components on multiple different types of devices
from different manufacturers, manufacturers or mobile devices on
different network carriers, since
the Trust Anchor Store on these different devices may contain keys
for different
TAMs. A To overcome this limitation, Device Administrator may be able to add their own TAM's
public key or certificate, or a certificate it chains up to, to the Trust Anchor Store on all their devices,
overcoming this limitation.  <vspace blankLines='1'/> devices.</t>
            <t>
Any entity is free to operate a TAM. For a TAM to be successful, it must
have its public key or certificate installed in a device's Trust Anchor Store.
A TAM may set up a relationship with device manufacturers or network carriers
to have them install the TAM's keys in their device's Trust Anchor Store.
Alternatively, a TAM may publish its certificate and allow Device
Administrators to install the TAM's certificate in their devices as
an after-market action.</t>
  <t>TEEP Broker: A aftermarket action.</t></dd>
          <dt>TEEP Broker:</dt><dd>A TEEP Broker is an application component running
          in a Rich Execution Environment (REE) that enables the message
          protocol exchange between a TAM and a TEE in a device. A TEEP Broker
          does not process messages on behalf of a TEE, TEE but merely is merely
          responsible for relaying messages from the TAM to the TEE, TEE and for
          returning the TEE's responses to the TAM.  In devices with no REE
          (e.g., a microcontroller where all code runs in an environment that
          meets the definition of a Trusted Execution Environment in <xref
          target="terminology"/>), the TEEP Broker would be absent absent, and
instead
          the TEEP protocol transport would be implemented inside the TEE itself.</t>
  <t>TEEP Agent: The
          itself.</dd>
          <dt>TEEP Agent:</dt><dd>The TEEP Agent is a processing module running inside
a TEE that receives TAM requests (typically relayed via a TEEP 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, which is
up to a TEE provider's implementation.
A response message
corresponding to a TAM request is sent back to the TAM, again typically
relayed via a TEEP Broker.</t>
  <t>Certification Broker.</dd>
          <dt>Certification Authority (CA): A (CA):</dt><dd>A CA is an entity that issues digital
certificates (especially X.509 certificates) and vouches for the
binding between the data items in a certificate <xref target="RFC4949"/>.
Certificates are then used for authenticating a device, a TAM, or a
Trusted Component Signer, as discussed in <xref target="trustanchors"/>.  The CAs do not need to be the same;
different CAs can be chosen by each TAM, and different device CAs
can be used by different device manufacturers.</t>
</list></t> manufacturers.</dd>
        </dl>
      </section>
      <section anchor="multiple-tees-in-a-device"><name>Multiple anchor="multiple-tees-in-a-device">
        <name>Multiple TEEs in a Device</name>
        <t>Some devices might implement multiple TEEs.
In these cases, there might be one shared TEEP Broker
that interacts with all the TEEs in the device.
However, some TEEs (for example, SGX <xref target="SGX"/>) present themselves as separate containers
within memory without a controlling manager within the TEE. As such,
there might be multiple TEEP Brokers in the REE,
where each TEEP Broker communicates with one or more TEEs associated with it.</t>
        <t>It is up to the REE and the Untrusted Applications
how they select the correct TEEP Broker. Verification that the correct TA
has been reached then becomes a matter of properly verifying TA attestations,
which are unforgeable.</t>
        <t>The multiple TEEP Broker approach is shown in the diagram below.
For brevity, TEEP Broker 2 is shown interacting with only one TAM and TAM, Untrusted Application Application, and only one TEE, but no such limitations are intended to be implied in the architecture.</t>
        <figure title="Notional anchor="notionalarch2">
          <name>Notional Architecture of TEEP with multiple TEEs" anchor="notionalarch2"><artwork><![CDATA[ TEEs</name>
          <artwork><![CDATA[
+-------------------------------------------+
| Device                                    |     Trusted Component
|                                           |               Signer
|    +---------------+                      |                  |
|    | TEE-1         |                      |                  |
|    | +-------+     |     +--------+       |      +--------+  |
|    | | TEEP  |     |     | TEEP   |------------->|        |<-+
|    | | Agent |<----------| Broker |       |      |        | TA
|    | | 1     |     |     | 1      |---------+    |        |
|    | +-------+     |     |        |       | |    |        |
|    |               |     |        |<---+  | |    |        |
|    | +----+ +----+ |     |        |    |  | |  +-|  TAM-1 | Policy
|    | |TA-1| |TA-2| |     |        |<-+ |  | +->| |        |<-+
|  +-->|    | |    |<---+  +--------+  | |  |    | +--------+  |
|  | | +----+ +----+ |  |              | |  |    | TAM-2  |    |
|  | |               |  |   +-------+  | |  |    +--------+    |
|  | +---------------+  +---| UA-2  |--+ |  |       ^          |
|  |                    +-------+   |    |  |       |       Device
|  +--------------------| UA-1  |   |    |  |       |   Administrator
|                +------|       |   |    |  |       |
|    +-----------|---+  |       |---+    |  |       |
|    | TEE-2     |   |  |       |--------+  |       |
|    | +------+  |   |  |       |-------+   |       |
|    | | TEEP |  |   |  +-------+       |   |       |
|    | | Agent|<-------+                |   |       |
|    | | 2    |  |   | |                |   |       |
|    | +------+  |   | |                |   |       |
|    |           |   | |                |   |       |
|    | +----+    |   | |                |   |       |
|    | |TA-3|<---+   | |   +---------+  |   |       |
|    | |    |        | |   | TEEP    |<-+   |       |
|    | +----+        | +---| Broker  |      |       |
|    |               |     | 2       |--------------+
|    +---------------+     +---------+      |
|                                           |
+-------------------------------------------+
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In the diagram above, TEEP Broker 1 controls interactions with the TAs in TEE-1,
and TEEP Broker 2 controls interactions with the TAs in TEE-2.
This presents some challenges for a TAM in completely managing the device,
since a TAM may not interact with all the TEEP Brokers on a particular
platform. In addition, since TEEs may be physically separated, with wholly
different resources, there may be no need for TEEP Brokers to share
information on installed Trusted Components or resource usage.</t>
      </section>
      <section anchor="multiple-tams-and-relationship-to-tas"><name>Multiple anchor="multiple-tams-and-relationship-to-tas">
        <name>Multiple TAMs and Relationship to TAs</name>
        <t>As shown in <xref target="notionalarch2"/>, a TEEP Broker provides communication between
one or more TEEP Agents and one or more TAMs. The selection of which TAM to interact with might be
made with or without input from an Untrusted Application, Application but is ultimately
the decision of a TEEP Agent.</t>

<t>A
<t>For any given Trusted Component, a TEEP Agent is assumed to be able to determine, for any given Trusted Component, determine whether that Trusted Component is installed (or minimally, is running) in a TEE with
which the TEEP Agent is associated.</t>
        <t>Each Trusted Component is digitally signed, protecting its integrity, integrity and linking
the Trusted Component back to the Trusted Component Signer. The Trusted Component Signer is often the Trusted Component Developer, but Developer but, in
some cases cases, might be another party such as a Device Administrator
or other party
to whom the code has been licensed (in which case case, the same code might
be signed by multiple licensees and distributed as if it were different TAs).</t>
        <t>A Trusted Component Signer selects one or more TAMs and communicates the Trusted Component(s) to the TAM.
For example, the Trusted Component Signer might choose TAMs based upon the markets into which the TAM can provide access. There
may be TAMs that provide services to specific types of devices, or device
operating systems, or specific geographical regions regions, or network carriers. A Trusted Component Signer may be
motivated to utilize multiple TAMs in order to maximize market penetration
and availability on multiple types of devices. This means that the same Trusted Component
will often be available through multiple TAMs.</t>
        <t>When the developer of an Untrusted Application that depends on a Trusted Component publishes
the Untrusted Application to an app store or other app repository, the developer
optionally binds the Untrusted Application with a manifest that identifies
what TAMs can be contacted for
the Trusted Component. In some situations, a Trusted Component may only be available via a single TAM - TAM; this is likely the case
for enterprise applications or Trusted Component Signers serving a closed community. For broad public apps,
there will likely be multiple TAMs in the Untrusted Application's manifest - manifest, one servicing one brand of mobile
device and another servicing a different manufacturer, etc. Because different devices and different manufacturers trust different TAMs, the manifest can include multiple
TAMs that support the required Trusted Component.</t>
        <t>When a TEEP Broker receives a request (see the RequestTA API in <xref target="apis"/>) from an Untrusted Application to install a Trusted Component,
a list of TAM URIs may be provided for that Trusted Component, and the request is passed to the TEEP Agent.
If the TEEP Agent decides that the Trusted Component needs to be installed, the TEEP Agent selects a single TAM URI
that is consistent with the list of trusted TAMs provisioned in the TEEP Agent, invokes the
HTTP transport for TEEP to connect to the TAM URI, and begins a TEEP protocol exchange.  When the TEEP Agent
subsequently receives the Trusted Component to install and the Trusted Component's manifest indicates dependencies
on any other trusted components, Trusted Components, each dependency can include a list of TAM URIs for the
relevant dependency.  If such dependencies exist that are prerequisites to install the Trusted Component,
then the TEEP Agent recursively follows the same procedure for each dependency that needs to be installed
or updated, including selecting a TAM URI that is consistent with the list of trusted TAMs provisioned
on the device, device and beginning a TEEP exchange.  If multiple TAM URIs are considered trusted,
only one needs to be contacted contacted, and they can be attempted in some order until one responds.</t>
        <t>Separate from the Untrusted Application's manifest, this framework relies on the use of the manifest
format in <xref target="I-D.ietf-suit-manifest"/> for expressing how to install a Trusted Component, as well as any
dependencies on other TEE components and versions.
That is, dependencies from Trusted Components on other Trusted Components can be expressed in a SUIT Software Update for the Internet of Things (SUIT) manifest,
including dependencies on any other TAs, trusted OS code (if any), or trusted firmware.
Installation steps can also be expressed in a SUIT manifest.</t>
        <t>For example, TEEs compliant
with GlobalPlatform <xref target="GPTEE"/> may have a notion of a "security domain" (which is a grouping of
one or more TAs installed on a device, device that can share information within such a group)
that must be created and into which one or more TAs can then be installed. It is thus up
to the SUIT manifest to express a dependency on having such a security domain existing
or being created first, as appropriate.</t>
        <t>Updating a Trusted Component may cause compatibility issues with any Untrusted Applications or other
components that depend on the updated Trusted Component, just like updating the OS or a shared library
could impact an Untrusted Application.  Thus, an implementation needs to take into
account such issues.</t> issues into account.</t>
      </section>
      <section anchor="untrusted-apps-trusted-apps-and-personalization-data"><name>Untrusted anchor="untrusted-apps-trusted-apps-and-personalization-data">
        <name>Untrusted Apps, Trusted Apps, and Personalization Data</name>
        <t>In TEEP, there is an explicit relationship and dependence between an Untrusted Application
in an REE and one or more TAs in a TEE, as shown in <xref target="notionalarch2"/>.
For most purposes, an Untrusted Application that uses one or more TAs in a TEE
appears no different from any other Untrusted Application in the REE. However, the way
the Untrusted Application and its corresponding TAs are packaged, delivered, and installed on
the device can vary. The variations depend on whether the Untrusted Application and TA are bundled
together or are provided 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) and/or TEE may
also require additional data to personalize the TA to the device or a user.
Implementations of the TEEP protocol must support encryption to preserve the confidentiality of such Personalization Data,
which may potentially contain sensitive data. The encryption is used to ensure that no personalization data
is sent in the clear. Implementations must also support mechanisms for integrity protection of such Personalization Data.
Other than the requirement to support confidentiality and integrity protection,
the TEEP architecture places no limitations or requirements on the Personalization Data.</t>
        <t>There are multiple possible cases for bundling of an Untrusted Application, TA(s), and Personalization Data.
Such cases include (possibly among others):</t>

<t><list style="numbers">
  <t>The
        <ol spacing="normal" type="1"><li>The Untrusted Application, TA(s), and Personalization Data are all bundled together in a single
package by a Trusted Component Signer and either provided to the TEEP Broker through the TAM, TAM or provided separately (with encrypted Personalization Data), with
key material needed to decrypt and install the Personalization
Data and TA provided by a TAM.</t>
  <t>The TAM.</li>
          <li>The Untrusted Application and the TA(s) are bundled together in a single package, which a TAM or
a publicly accessible app store maintains, and the Personalization Data
is separately provided by the Personalization Data provider's TAM.</t>
  <t>All TAM.</li>
          <li>All components are independent packages. The Untrusted Application is installed through some
independent or device-specific mechanism, and one or more TAMs provide (directly or indirectly by reference)
the TA(s) and Personalization Data.</t>
  <t>The Data.</li>
          <li>The TA(s) and Personalization Data are bundled together into a package provided by a TAM,
while the Untrusted Application is installed through some independent
or device-specific mechanism mechanism, such as an app store.</t>
  <t>Encrypted store.</li>
          <li>Encrypted Personalization Data is bundled into a package distributed with the Untrusted
Application, while the TA(s) and key material needed to decrypt and install the Personalization Data
are in a separate package provided by a TAM. Personalization Data is encrypted with a key
unique to that specific TEE, as discussed in <xref target="trustanchors"/>.</t>
</list></t> target="trustanchors"/>.</li>
        </ol>
        <t>The TEEP protocol can treat each TA, any dependencies the TA has, and Personalization Data as
separate Trusted Components with separate installation steps that are expressed in SUIT manifests, and a SUIT manifest might contain or reference multiple binaries (see <xref target="I-D.ietf-suit-manifest"/>
for more details). The TEEP Agent is responsible for handling any installation steps
that need to be performed inside the TEE, such as decryption of private TA binaries or
Personalization Data.</t>
        <t>In order to better understand these cases, it is helpful to review actual implementations of TEEs and their application delivery mechanisms.</t>
        <section anchor="example-application-delivery-mechanisms-in-intel-sgx"><name>Example: anchor="example-application-delivery-mechanisms-in-intel-sgx">

	  <name>Example: Application Delivery Mechanisms in Intel SGX</name>
          <t>In Intel Software Guard Extensions (SGX), the Untrusted
          Application and TA are typically bundled into the same package (Case
          2). The TA exists in the package as a shared library (.so or
          .dll). The Untrusted Application loads the TA into an SGX enclave
          when the Untrusted Application needs the TA. This organization makes
          it easy to maintain compatibility between the Untrusted Application
          and the TA, since they are updated together. It is entirely possible
          to create an Untrusted Application that loads an external TA into an
          SGX enclave, enclave and use that TA (Cases 3-5).  In this case, the
          Untrusted Application would require a reference to an external file
          or download such a file dynamically, place the contents of the file
          into memory, and load that as a TA. Obviously, such file or
          downloaded content must be properly formatted and signed for it to
          be accepted by the SGX TEE.</t>
          <t>In SGX, any
Personalization Data is normally loaded into the SGX enclave (the TA) after the TA has
started.
Although it is possible with SGX to include the Untrusted Application in an encrypted
package along with Personalization Data (Cases 1 and 5), there are currently no known instances of this known to
be in use at this time, use, since such a construction would require a special installation
program and SGX TA (which might or might not be the TEEP Agent itself based on the implementation)
to receive the encrypted package, decrypt it, separate it into the
different elements, and then install each one. This installation is complex
because the Untrusted Application decrypted inside the TEE must be passed out of the TEE to an
installer in the REE which that would install the Untrusted Application.
Finally, the Personalization Data would need to be sent out of the
TEE (encrypted in an SGX enclave-to-enclave manner) to the REE's installation app, which
would pass this data to the installed Untrusted Application, which would in turn send this data
to the SGX enclave (TA). This complexity is due to the fact that each SGX enclave is separate
and does not have direct communication to other SGX enclaves.</t>
          <t>As long as signed files (TAs and/or Personalization Data) are installed into
an untrusted filesystem and trust is verified by the TEE at load time, classic
distribution mechanisms can be used.  Some  However, some uses of SGX, however, SGX allow a model
where a TA can be dynamically installed into an SGX enclave that
provides a runtime platform.  The TEEP protocol can be used in
such cases, where the runtime platform could include a TEEP Agent.</t>
        </section>
        <section anchor="example-application-delivery-mechanisms-in-arm-trustzone"><name>Example: anchor="example-application-delivery-mechanisms-in-arm-trustzone">
          <name>Example: Application Delivery Mechanisms in Arm TrustZone</name>
          <t>In Arm TrustZone <xref target="TrustZone"/> for A-class devices,
          the Untrusted Application and TA may or may not be bundled
          together.
This differs from SGX since in TrustZone TrustZone, the TA lifetime
          is not inherently tied to a specific Untrusted Application process
          lifetime as occurs in SGX.  A TA is loaded by a trusted OS running
          in the TEE TEE, such as a TEE compliant with GlobalPlatform <xref target="GPTEE"/> compliant TEE, target="GPTEE"/>,
          where the trusted OS is separate from the OS in the REE.
Thus  Thus,
          Cases 2-4 are equally applicable.

In addition, it is possible for
          TAs to communicate with each other without involving any Untrusted Application, and so
          Application; thus, the complexity of Cases 1 and 5 are lower than
          in the SGX example, though still more complex than Cases 2-4.</t>
          <t>A trusted OS running in the TEE (e.g., OP-TEE <xref target="OP-TEE"/>) that supports loading and verifying signed TAs from
an untrusted filesystem can, like SGX, use classic file distribution
mechanisms.  If secure TA storage is used (e.g., a Replay-Protected
Memory Block device) on the other hand, the TEEP protocol can be used
to manage such storage.</t>
        </section>
      </section>
      <section anchor="entity-relations"><name>Entity anchor="entity-relations">
        <name>Entity Relations</name>
        <t>This architecture leverages asymmetric cryptography to
authenticate a device to a TAM. Additionally, a TEEP Agent
in 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 Administrator may want to
have the capability to control what TAs are allowed.
A device manufacturer enables verification by one or more TAMs and by Trusted Component Signers;
it may embed a list of default Trust Anchors into the TEEP Agent
and TEE for TAM trust verification and TA signature verification.</t>
        <figure title="Example anchor="experience">
          <name>Example Developer Experience" anchor="experience"><artwork><![CDATA[ Experience</name>
          <artwork><![CDATA[
 (App Developers)   (App Store)   (TAM)      (Device with TEE)  (CAs)
        |                   |       |                |            |
        |                   |       |      (Embedded TEE cert) <--|
        |                   |       |                |            |
        | <--- Get an app cert -----------------------------------|
        |                   |       |                |            |
        |                   |       | <-- Get a TAM cert ---------|
        |                   |       |                |            |
1. Build two apps:          |       |                |            |
                            |       |                |            |
   (a) Untrusted            |       |                |            |
       App - 2a. Supply --> |       |                |            |
                            |       |                |            |
   (b) TA -- 2b. Supply ----------> |                |            |
                            |       |                |            |
                            | --- 3. Install ------> |            |
                            |       |                |            |
                            |       | 4. Messaging-->|            |
]]></artwork></figure>
]]></artwork>
        </figure>
        <t><xref target="experience"/> shows an example where the same developer builds and signs
two applications: (a) an Untrusted Application; Application and (b) a TA
that provides some security functions to be run inside
a TEE.  This example assumes that the developer, the TEE, and the TAM have
previously been provisioned with certificates.</t>

<t>At step 1, the developer authors the two applications.</t>
        <t>At step 2, the developer uploads the
Untrusted Application (2a) to an Application Store.
In this example, the developer is also the Trusted Component Signer, Signer and so thus generates
a signed TA.
The developer can then either bundle the signed TA
with the Untrusted Application, Application or the developer can provide a signed Trusted Component containing the TA
to a TAM that will be managing the TA in various devices.</t>
        <t>At step 3, a user
will go to an Application Store to download the Untrusted
Application (where the arrow indicates the direction of data transfer).</t>
        <t>At step 4, since the Untrusted Application depends on the TA, installing the Untrusted Application will trigger TA installation
via communication with a TAM. The TEEP Agent
will interact with the TAM via a TEEP Broker that facilitates communications between the TAM
and the TEEP Agent.</t>

<t>Some Trusted Component installation implementations that install Trusted Components might ask for a user's consent. In other
implementations,
a Device Administrator might choose what the Untrusted Applications and related Trusted Components to
be installed. A user consent flow is out of scope of the TEEP architecture.</t>
        <t>The main components of the TEEP protocol
consist of a set of standard messages created by
a TAM to deliver Trusted Component management commands to a device, device
and device attestation and response messages created by a TEE that
responds to a TAM's message.</t>
        <t>It should be noted that network communication capability is generally
not available in TAs in today's TEE-powered devices.  Consequently, Trusted
Applications generally rely on a broker Broker in the REE to provide access to
network functionality in the REE.  A broker Broker does not need to know the actual
content of messages to facilitate such access.</t>
        <t>Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent generally
relies on a TEEP Broker in the REE to provide network access, and relay
TAM requests to the TEEP Agent Agent, and relay the responses back to the TAM.</t>
      </section>
    </section>
    <section anchor="trustanchors"><name>Keys anchor="trustanchors">
      <name>Keys and Certificate Types</name>
      <t>This architecture leverages the following credentials, which allow
achieving end-to-end security between a TAM and a TEEP Agent.</t>
      <t><xref target="keys"/> summarizes the relationships between various keys and where
they are stored.  Each public/private key identifies a Trusted Component Signer, TAM, or TEE, TEE
and gets a certificate that chains up to some trust anchor. Trust Anchor.
A list of trusted
certificates is used to check a presented certificate against.</t>
      <t>Different CAs can be used for different
types of certificates.  TEEP 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 addition to the keys shown in <xref target="keys"/>,
there may be additional keys used for attestation or encryption.  Refer to the
RATS Architecture <xref target="I-D.ietf-rats-architecture"/> target="RFC9334"/> for more discussion.</t>

<figure title="Signature Keys" anchor="keys"><artwork><![CDATA[
                    Cardinality &                    Location of

<table anchor="keys">
  <name>Signature Keys</name>
  <thead>
    <tr>
      <th>Purpose</th>
      <th>Cardinality &amp; Location of Private Key</th>
      <th>Private Key Signs</th>
      <th>Location of Trust Anchor
Purpose              Private Key       Signs           Store
------------------   -----------   -------------    -------------
Authenticating        1 per TEE    TEEP responses       TAM Store</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Authenticating TEEP Agent

Authenticating TAM    1 Agent</td>
      <td>1 per TAM    TEEP requests     TEEP Agent

Code Signing          1 TEE</td>
      <td>TEEP responses</td>
      <td>TAM</td>
    </tr>
    <tr>
      <td>Authenticating TAM</td>
      <td>1 per TAM</td>
      <td>TEEP requests</td>
      <td>TEEP Agent</td>
    </tr>
    <tr>
      <td>Code Signing</td>
      <td>1 per Trusted  TA binary          TEE Component
                      Signer
]]></artwork></figure> Signer</td>
      <td>TA binary</td>
      <td>TEE</td>
    </tr>
  </tbody>
</table>
      <t>Note that Personalization Data is not included in the table above.
The use of Personalization Data is dependent on how TAs are used
and what their security requirements are.</t>
      <t>TEEP requests from a TAM to a TEEP Agent are signed with the TAM
private key (for authentication and integrity protection).
Personalization Data and TA binaries can be encrypted with a key
unique to that specific TEE,
established with a content-encryption key established with
the TEE public key (to provide confidentiality). TEE.
Conversely, TEEP responses from a TEEP Agent to a TAM can be signed with the
TEE private key.</t>

<t>The TEE key pair and certificate are thus used for authenticating the TEE
to a remote TAM, TAM and for sending private data to the TEE. Often,
the key pair is burned into the TEE by the
TEE manufacturer 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
<xref target="trust-anchors-in-tam"/> below. target="trust-anchors-in-tam"/>.  Typically,
the same key TEE key pair is used for both signing and encryption, though separate
key pairs might also be used in the future, as the joint security of
encryption and signature with a single key remains remains, to some extent extent, an open
question in academic cryptography.</t>
      <t>The TAM key pair and certificate are used for authenticating a TAM
to a remote TEE, TEE and for sending private data to the TAM (separate key
pairs for authentication vs. encryption could also be used in the future).  A TAM provider
is responsible for acquiring a
certificate from a CA that is trusted by the TEEs it manages. This
is discussed further in <xref target="trust-anchors-in-teep-agent"/> below.</t> target="trust-anchors-in-teep-agent"/>.</t>
      <t>The Trusted Component Signer key pair and certificate are used to sign Trusted Components that the TEE
will consider authorized to execute.  TEEs must be configured with
the certificates or keys that it considers authorized to sign TAs
that it will execute.  This is discussed further in
<xref target="trust-anchors-in-tee"/> below.</t> target="trust-anchors-in-tee"/>.</t>
      <section anchor="trust-anchors-in-teep-agent"><name>Trust anchor="trust-anchors-in-teep-agent">
        <name>Trust Anchors in a TEEP Agent</name>
        <t>A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, which are typically CA certificates that sign various TAM certificates.  The list
is typically usually preloaded at manufacturing time, time and
can be updated using the TEEP protocol if the TEE has some form of
"Trust Anchor Manager TA" that has Trust Anchors in its configuration data.
Thus, Trust Anchors can be updated similarly to the Personalization Data
for any other TA.</t>
        <t>When a Trust Anchor update is carried out, it is imperative that any update
must maintain integrity where only an authentic Trust Anchor list from
a device manufacturer or a Device Administrator is accepted. Details
are out of scope of the this architecture document and can be addressed in a protocol
document.</t>
        <t>Before a TAM can begin operation in the marketplace to support a
device with a particular TEE, it must be able to get its raw public
key, or its certificate, or a certificate it chains up to, to listed in
the Trust Anchor Store of the TEEP Agent.</t>
      </section>
      <section anchor="trust-anchors-in-tee"><name>Trust anchor="trust-anchors-in-tee">
        <name>Trust Anchors in a TEE</name>
        <t>The Trust Anchor Store in a TEE contains a list of Trust Anchors (raw public keys
or certificates) that are used to determine whether TA binaries are allowed to execute by
checking if their signatures can be verified.  The list
is typically preloaded at manufacturing time, time and
can be updated using the TEEP protocol if the TEE has some form of
"Trust Anchor Manager TA" that has Trust Anchors in its configuration data.
Thus, Trust Anchors can be updated similarly to the Personalization Data
for any other TA, as discussed in <xref target="trust-anchors-in-teep-agent"/>.</t>
      </section>
      <section anchor="trust-anchors-in-tam"><name>Trust anchor="trust-anchors-in-tam">
        <name>Trust Anchors in a TAM</name>
        <t>The Trust Anchor Store in a TAM consists of a list of Trust
        Anchors, which are certificates that sign various device TEE
        certificates.  A TAM will accept a device for Trusted Component
        management if the TEE in the device uses a TEE certificate that is
        chained to a certificate or raw public key that the TAM trusts, is
        contained in an allow list, is not found on a block list, and/or
        fulfills any other policy criteria.</t>
      </section>
      <section anchor="scalability"><name>Scalability</name> anchor="scalability">
        <name>Scalability</name>
        <t>This architecture uses a PKI (including self-signed
        certificates). Trust Anchors exist on the devices to enable the TEEP
        Agent to authenticate TAMs and the TEE to authenticate Trusted
        Component Signers, and TAMs use Trust Anchors to authenticate TEEP
        Agents.  When a PKI is used, many intermediate CA certificates can
        chain to a root certificate, each of which can issue many
        certificates.  This makes the protocol highly scalable.  New factories
        that produce TEEs can join the ecosystem.  In this case, such a
        factory can get an intermediate CA certificate from one of the
        existing roots without requiring that TAMs are updated with
        information about the new device factory.  Likewise, new TAMs can join
        the ecosystem, providing they are issued a TAM certificate that chains
        to an existing root whereby existing TAs in the TEE will be allowed to
        be personalized by the TAM without requiring changes to the TEE
        itself.  This enables the ecosystem to scale, scale and avoids the need for
        centralized databases of all TEEs produced or produced, all TAMs that exist exist, or
        all Trusted Component Signers that exist.</t> exist.
	</t>
      </section>
      <section anchor="message-security"><name>Message anchor="message-security">
        <name>Message Security</name>
        <t>Messages created by a TAM are used to deliver Trusted Component
management commands to a device, and device attestation and
messages are created by the device TEE to respond to TAM messages.</t>
        <t>These messages are signed end-to-end between a TEEP Agent and a TAM.
Confidentiality is provided by encrypting sensitive payloads (such as
Personalization Data and attestation evidence), rather than encrypting the
messages themselves.  Using encrypted payloads is important to ensure
that only the targeted device TEE or TAM is able to decrypt and view
the actual content.</t>
      </section>
    </section>
    <section anchor="broker"><name>TEEP anchor="broker">
      <name>TEEP Broker</name>
      <t>A TEE and TAs often do not have the capability to directly communicate
outside of the hosting device.  For example, GlobalPlatform
<xref target="GPTEE"/> specifies one such architecture.  This calls for a software
module in the REE world to handle network communication with a TAM.</t>
      <t>A TEEP Broker is an application component
running in the REE of the device or an SDK that facilitates
communication between a TAM and a TEE.  It also provides interfaces for
Untrusted Applications to query and trigger installation of Trusted Components that the
application needs to use.</t>

<t>An

      <t>
   An Untrusted Application might communicate with a TEEP Broker at
   runtime to trigger Trusted Component installation itself, or itself. Alternatively, an
   Untrusted Application might simply have a metadata file that
   describes the Trusted Components it depends on and the associated
   TAM(s) for each Trusted Component,
and an Component. An REE Application Installer
   can inspect this application metadata file and invoke the TEEP Broker
   to trigger Trusted Component installation on behalf of the Untrusted
   Application without requiring the Untrusted Application to run first.</t> first.
      </t>
      <section anchor="role-of-the-teep-broker"><name>Role anchor="role-of-the-teep-broker">
        <name>Role of the TEEP Broker</name>
        <t>A TEEP Broker interacts with a TEEP Agent inside a TEE,
relaying messages between the TEEP Agent and the TAM, and may also interact with
one or more Untrusted Applications (see <xref target="apis"/>).
The Broker cannot parse encrypted TEEP messages exchanged between a TAM and a TEEP agent Agent but merely relays them.</t>
        <t>When a device has more than one TEE, one TEEP Broker per TEE could
be present in the REE REE, or a common TEEP Broker could be used by multiple TEEs
where the transport protocol (e.g., <xref target="I-D.ietf-teep-otrp-over-http"/>) allows
the TEEP Broker to distinguish which TEE is relevant for each message from a TAM.</t>

<t>The Broker only needs to return a (transport) an error message to the TAM if the TEE is
not reachable for some reason.  Other errors are represented as
TEEP response messages returned from the TEE TEE, which will then be passed to
the TAM.</t>
      </section>
      <section anchor="teep-broker-implementation-consideration"><name>TEEP anchor="teep-broker-implementation-consideration">
        <name>TEEP Broker Implementation Consideration</name>
        <t>As depicted in <xref target="broker-models"/>, there are multiple ways in which a TEEP Broker
can be implemented, implemented with more or fewer layers being inside the TEE.
For example, in model A, the A (the model with the smallest TEE footprint, footprint), only the
TEEP implementation is inside the TEE, whereas the TEEP/HTTP implementation is
in the TEEP Broker outside the TEE.</t>
        <figure title="TEEP anchor="broker-models">
          <name>TEEP Broker Models" anchor="broker-models"><artwork><![CDATA[ Models</name>
          <artwork><![CDATA[
                   Model:    A      B      C

                            TEE    TEE    TEE
+----------------+           |      |      |
|      TEEP      |     Agent |      |      | Agent
| implementation |           |      |      |
+----------------+           v      |      |
         |                          |      |
+----------------+           ^      |      |
|    TEEP/HTTP   |    Broker |      |      |
| implementation |           |      |      |
+----------------+           |      v      |
         |                   |             |
+----------------+           |      ^      |
|     HTTP(S)    |           |      |      |
| implementation |           |      |      |
+----------------+           |      |      v
         |                   |      |
+----------------+           |      |      ^
|   TCP or QUIC  |           |      |      | Broker
| implementation |           |      |      |
+----------------+           |      |      |
                            REE    REE    REE
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In other models, additional layers are moved into the TEE, increasing the TEE footprint,
with the Broker either containing or calling the topmost protocol layer outside of the TEE.
An implementation is free to choose any of these models.</t>
        <t>TEEP Broker implementers should consider methods of distribution, scope scope, and
   concurrency on devices and runtime options.</t>
        <section anchor="apis"><name>TEEP anchor="apis">
          <name>TEEP Broker APIs</name>
          <t>The following conceptual APIs exist from a TEEP Broker to a TEEP Agent:</t>

<t><list style="numbers">
  <t>RequestTA:
          <ol spacing="normal">

	    <li>RequestTA: A notification from an REE application (e.g., an installer,
	    installer or an Untrusted Application) that it the application
	    depends on a given Trusted Component, which may or may not already
	    be installed in the TEE.</t>
  <t>UnrequestTA: TEE.
	  </li>
            <li>UnrequestTA: A notification from an REE application (e.g., an installer,
            installer or an Untrusted Application) that it the application no
            longer depends on a given Trusted Component, which may or may not
            already be installed in the TEE.  For example, if the Untrusted
            Application is uninstalled, the uninstaller might invoke this
            conceptual API.</t>
  <t>ProcessTeepMessage: API.</li>
<li>ProcessTeepMessage: A message arriving from the network, to be delivered
to the TEEP Agent for processing.</t>
  <t>RequestPolicyCheck: processing.</li>
            <li>RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP Agent
may wish to contact the TAM for any changes, changes without the device itself
needing any particular change.</t>
  <t>ProcessError: change.</li>
            <li>ProcessError: A notification that the TEEP Broker could not deliver an outbound
TEEP message to a TAM.</t>
</list></t> TAM.</li>
          </ol>
          <t>For comparison, similar APIs may exist on the TAM side, where a Broker may or may not
exist, depending on whether the TAM uses a TEE or not:</t>

<t><list style="numbers">
  <t>ProcessConnect:
          <ol spacing="normal">
<li>ProcessConnect: A notification that a new TEEP session is being requested by a TEEP Agent.</t>
  <t>ProcessTeepMessage: Agent.</li>
            <li>ProcessTeepMessage: A message arriving at an existing TEEP session, to be delivered
to the TAM for processing.</t>
</list></t> processing.</li>
          </ol>
          <t>For further discussion on these APIs, see <xref target="I-D.ietf-teep-otrp-over-http"/>.</t>
        </section>
        <section anchor="teep-broker-distribution"><name>TEEP anchor="teep-broker-distribution">
          <name>TEEP Broker Distribution</name>
          <t>The Broker installation is commonly carried out at device manufacturing time. A user
may also dynamically download and install a Broker on-demand.</t> on demand.</t>
        </section>
      </section>
    </section>
    <section anchor="attestation"><name>Attestation</name> anchor="attestation">
      <name>Attestation</name>
      <t>Attestation is the process through which one entity (an Attester) presents "evidence", "evidence" in the form
of a series of claims, claims to another entity (a Verifier), Verifier) and provides sufficient proof that the claims
are true. Different Verifiers may require different degrees of confidence in attestation proofs proofs,
and not all attestations are acceptable to every Verifier.  A third entity (a Relying Party)
can then use "attestation results", results" in the form of another series of claims, claims from a Verifier
to make authorization decisions.  (See <xref target="I-D.ietf-rats-architecture"/> target="RFC9334"/> for more discussion.)</t>
      <t>In TEEP, as depicted in <xref target="attestation-roles"/>,
the primary purpose of an attestation is to allow a device (the Attester) to prove to a TAM
(the Relying Party) that a TEE in the device has particular properties, was built by a particular
manufacturer, and/or is executing a particular TA. Other claims are possible; TEEP
does not limit the claims that may appear in evidence or attestation results,
but it defines a minimal set of attestation result claims
required for TEEP to operate properly. Extensions to these claims are possible.
Other standards or groups may define the format and semantics
of extended claims.</t>
      <figure title="TEEP anchor="attestation-roles">
        <name>TEEP Attestation Roles" anchor="attestation-roles"><artwork><![CDATA[ Roles</name>
        <artwork><![CDATA[
+----------------+
| Device         |            +----------+
| +------------+ |  Evidence  |   TAM    |   Evidence    +----------+
| |     TEE    |------------->| (Relying |-------------->| Verifier |
| | (Attester) | |            |  Party)  |<--------------|          |
| +------------+ |            +----------+  Attestation  +----------+
+----------------+                             Result
]]></artwork></figure>

<t>As of
]]></artwork>
      </figure>
      <t>At the writing time of writing this specification, device and TEE attestations have not been standardized
across the market. Different devices, manufacturers, and TEEs support different attestation
protocols. In order for TEEP to be inclusive, it is agnostic to the format of evidence,
allowing proprietary or standardized formats to be used between a TEE and a Verifier (which may or may not
be colocated in the TAM), as long as the format supports encryption of
any information that is considered sensitive.</t>
      <t>However, it should be recognized
that not all Verifiers may be able to process all proprietary forms of attestation evidence.
Similarly, the TEEP protocol is agnostic as to the format of attestation results, results and the protocol
(if any) used between the TAM and a Verifier, as long as they convey at least the required set of claims
in some format. Note that the respective attestation algorithms are not defined in the TEEP protocol itself;
see <xref target="I-D.ietf-rats-architecture"/> target="RFC9334"/> and <xref target="I-D.ietf-teep-protocol"/> for more discussion.</t>

<t>There are a number of considerations that need to be considered

      <t>Considerations when appraising evidence provided by a TEE, including:</t>

<t><list style="symbols">
  <t>What TEE include the following:
      </t>
      <ul spacing="normal">
        <li>What security measures a manufacturer takes when provisioning keys into devices/TEEs;</t>
  <t>What devices/TEEs;</li>
        <li>What hardware and software components have access to the attestation keys of the TEE;</t>
  <t>The TEE;</li>
        <li>The source or local verification of claims within an attestation prior to a TEE signing a set of claims;</t>
  <t>The claims;</li>
        <li>The level of protection afforded to attestation keys against exfiltration, modification, and side channel attacks;</t>
  <t>The attacks;</li>
        <li>The limitations of use applied to TEE attestation keys;</t>
  <t>The keys;</li>
        <li>The processes in place to discover or detect TEE breaches; and</t>
  <t>The and</li>
        <li>The revocation and recovery process of TEE attestation keys.</t>
</list></t> keys.</li>
      </ul>
      <t>Some TAMs may require additional claims in order to properly authorize a device or TEE.  The specific
format for these additional claims are outside the scope of this specification, but the TEEP protocol
allows these additional claims to be included in the attestation messages.</t>
      <t>For more discussion of the attestation and appraisal process, see
the RATS Architecture <xref target="I-D.ietf-rats-architecture"/>.</t> target="RFC9334"/>.</t>
      <t>The following information is required for TEEP attestation:</t>

<t><list style="symbols">
  <t>Device
      <ul spacing="normal">
        <li>Device Identifying Information: Attestation information may need to uniquely identify a device to the TAM.
Unique device identification allows the TAM to provide services to the device, such as managing installed
TAs, and providing subscriptions to services, and locating device-specific keying material to
communicate with or authenticate the device. In some use cases cases, it may be sufficient to identify
only the model or class of the device, for example, a DAA Issuer's group public key ID when the
attestation uses DAA, DAA; see <xref target="I-D.ietf-rats-daa"/>. Another example of models is the hwmodel (Hardware Model) as
defined in <xref target="I-D.ietf-rats-eat"/>. The security and privacy requirements regarding device identification
will vary with the type of TA provisioned to the TEE.</t>
  <t>TEE TEE.</li>
        <li>TEE Identifying Information: The type of TEE that generated this attestation must be identified.
This includes version identification information for hardware, firmware, and software version of the TEE, as applicable by the
TEE type. TEE manufacturer information for the TEE is
required in order to disambiguate the same TEE type created by different manufacturers and
address considerations around manufacturer provisioning, keying keying, and support for the TEE.</t>
  <t>Freshness TEE.</li>
        <li>Freshness Proof: A claim that includes freshness information must be included, such as a nonce
or timestamp.</t>
</list></t> timestamp.</li>
      </ul>
    </section>
    <section anchor="algorithm-and-attestation-agility"><name>Algorithm anchor="algorithm-and-attestation-agility">
      <name>Algorithm and Attestation Agility</name>
      <t><xref target="RFC7696"/> outlines the requirements to migrate from one
mandatory-to-implement cryptographic algorithm suite to another over time.
This feature is also known as crypto agility. "crypto agility". Protocol evolution
is greatly simplified when crypto agility is considered
during the design of the protocol. In the case of the TEEP
protocol
protocol, the diverse range of use cases, from cases (from trusted app
updates for smartphones and tablets to updates of code on
higher-end IoT devices, devices) creates the need for different
mandatory-to-implement algorithms already from the start.</t>
      <t>Crypto agility in TEEP concerns the use of symmetric as well as asymmetric
algorithms. In the context of TEEP, symmetric algorithms are used for
encryption and integrity protection of TA binaries and Personalization Data Data,
whereas the asymmetric algorithms are used for signing messages and managing
symmetric keys.</t>
      <t>In addition to the use of cryptographic algorithms in TEEP, there
is also the need to make use of different attestation technologies.
A device must provide techniques to inform a TAM about the
attestation technology it supports. For many deployment cases cases, it
is more likely for the TAM to support one or more attestation
techniques
techniques, whereas the device may only support one.</t>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <section anchor="broker-trust-model"><name>Broker anchor="broker-trust-model">
        <name>Broker Trust Model</name>
        <t>The architecture enables the TAM to communicate, via a TEEP Broker, with the device's TEE to manage Trusted Components.  Since

However, since the TEEP Broker runs in a potentially vulnerable REE,
the TEEP Broker could, however, could be (or malware or be infected by) by malware.
As such, all TAM messages are signed and sensitive
data is encrypted such that the TEEP Broker cannot modify or capture
sensitive data, but the TEEP Broker can still conduct DoS attacks
as discussed in <xref target="compromised-ree"/>.</t>
        <t>A TEEP Agent in a TEE is responsible for protecting against potential 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 launch a DoS attack by sending a flood
of TEEP protocol requests, or simply drop or delay notifications to a TEE. The TEEP Agent
validates the signature of each TEEP protocol request
and checks the signing certificate against its Trust Anchors. To mitigate
DoS attacks, it might also add some protection
scheme such as a threshold on repeated requests or the number of TAs that can be installed.</t>

<t>Some implementations might rely on (due
        <t>Due to the lack of any available alternative) alternative, some implementations might rely on the use of
an untrusted timer or other event to call the RequestPolicyCheck API (<xref target="apis"/>), which
means that a compromised REE can cause a TEE to not receive policy changes and thus be out of date
with respect to policy.  The same can potentially be done by any other manipulator-in-the-middle
simply by blocking communication with a TAM.  Ultimately  Ultimately, such outdated compliance
could be addressed by using attestation in secure communication, where the attestation
evidence reveals what state the TEE is in, so that communication (other than remediation
such as via TEEP) from an out-of-compliance TEE can be rejected.</t>
        <t>Similarly, in most implementations implementations, the REE is involved in the mechanics of installing new TAs.
However, the authority for what TAs are running in a given TEE is between the TEEP Agent and the TAM.
While a TEEP Broker can can, in effect effect, make suggestions as discussed in Section <xref target="apis"/>, it cannot decide or enforce what runs where.
The TEEP Broker can also control which TEE a given installation request is directed at, but a TEEP
Agent will only accept TAs that are actually applicable to it and where installation instructions
are received by a TAM that it trusts.</t>
        <t>The authorization model for the UnrequestTA operation is, however, weaker in that it
expresses the removal of a dependency from an application that was untrusted to begin with.
This means that a compromised REE could remove a valid dependency from an Untrusted Application
on a TA.  Normal REE security mechanisms should be used to protect the REE and Untrusted Applications.</t>
      </section>
      <section anchor="data-protection"><name>Data anchor="data-protection">
        <name>Data Protection</name>
        <t>It is the responsibility of the TAM to protect data on its servers.
Similarly, it is the responsibility of the TEE implementation to provide protection of
data against integrity and confidentiality attacks from outside the TEE.
TEEs that provide isolation among TAs within the TEE are likewise
responsible for protecting TA data against the REE and other TAs.
For example, this can be used to protect the data of one user's user or tenant's data tenant
from compromise by another user or tenant, even if the attacker has TAs.</t>
        <t>The protocol between TEEP Agents and TAMs similarly is similarly responsible for
securely providing integrity and confidentiality protection against
adversaries between them. It is a design choice at what
   The layers at which to best provide protection against network adversaries.
   adversaries is a design choice.
   As discussed in <xref target="broker"/>,
the transport protocol and any security mechanism associated with it (e.g., the Transport Layer Security protocol) under
the TEEP protocol may terminate outside a TEE. If it does, the TEEP protocol
itself must provide integrity protection and 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 <xref target="I-D.ietf-teep-protocol"/> for how a specific
solution addresses the design question of how to provide integrity and
confidentiality protection.</t>
      </section>
      <section anchor="compromised-ree"><name>Compromised anchor="compromised-ree">
        <name>Compromised REE</name>
        <t>It is possible that the REE of a device is compromised.
We have already seen examples of attacks on the public Internet with a large number
of compromised devices being used to mount DDoS attacks.  A compromised
REE can be used for such an attack attack, but it cannot tamper with the TEE's
code or data in doing so.  A compromised REE can, however, launch DoS attacks
against the TEE.</t>
        <t>The compromised REE
may terminate the TEEP Broker such that TEEP transactions cannot reach the TEE, TEE
or might drop, replay, or delay messages between a TAM and a TEEP Agent.
However, while a DoS attack cannot be prevented, the REE cannot access
anything in the TEE if the TEE is implemented correctly.
Some TEEs may have some watchdog scheme to observe REE state and mitigate DoS
attacks against it it, but most TEEs don't have such a capability.</t>
        <t>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
uninstall a Trusted Component.  An installation or uninstallation 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 a TAM to pass the request
signature validation.</t>
        <t>This can become a DoS attack by exhausting resources in a TEE with
repeated requests. In general, a DoS attack threat exists when the REE
is compromised, compromised and a DoS attack can happen to other resources. The TEEP
architecture doesn't change this.</t>
        <t>A compromised REE might also request initiating the full flow of
installation of Trusted Components that are not necessary.
It may also repeat a prior legitimate Trusted Component installation
request. A TEEP Agent implementation is responsible for ensuring that it
can recognize and decline such repeated requests. It is also responsible
for protecting the resource usage allocated for Trusted Component management.</t>
      </section>
      <section anchor="trust-anchor-compromise"><name>CA anchor="trust-anchor-compromise">
        <name>CA Compromise or Expiry of CA Certificate</name>
        <t>A root CA for TAM certificates might get compromised, or its certificate might
expire, or a Trust Anchor other than a root CA certificate may also expire or
be compromised.
TEEs are responsible for validating the entire TAM certificate certification path,
including the TAM certificate and any intermediate certificates up to
the root certificate.  See Section 6 of <xref target="RFC5280"/> target="RFC5280" sectionFormat="of" section="6"/> for details.
Such validation generally includes checking for certificate
revocation, but certificate status check protocols may
not scale down to constrained devices that use TEEP.</t>
        <t>To address the above issues, a certificate certification path update mechanism
is expected from TAM operators, so that the TAM can get
a new certificate certification path that can be validated by a TEEP Agent.
In addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store
may need to be updated.
To address this, some a TEE Trust Anchor update
mechanism is expected from device OEMs, equipment manufacturers (OEMs), such as using the TEEP protocol
to distribute new Trust Anchors.</t>
        <t>Similarly, a root CA for TEE certificates might get compromised, or its certificate might
expire, or a Trust Anchor other than a root CA certificate may also expire or
be compromised.
TAMs are responsible for validating the entire TEE certificate certification path,
including the TEE certificate and any intermediate certificates up to
the root certificate.  Such validation includes checking for certificate
revocation.</t>
        <t>If a TEE certificate certification path validation fails, the TEE
might be rejected by a TAM, subject to the TAM's policy.
To address this, some certificate a certification path update mechanism
is expected from device OEMs, so that the TEE can get
a new certificate certification path that can be validated by a TAM.
In addition, the Trust Anchor in the TAM's Trust Anchor Store
may need to be updated.</t>
      </section>
      <section anchor="compromised-tam"><name>Compromised anchor="compromised-tam">
        <name>Compromised TAM</name>

        <t>Device TEEs are responsible for validating the supplied TAM
        certificates.  A compromised TAM may bring multiple threats and damage
        to user devices that it can manage and thus to the Device Owners.
        Information on devices that the TAM manages may be leaked to a bad
        actor.  A compromised TAM can also install many TAs to launch a DoS
        attack on devices, for example, by filling up a device's TEE resources
        reserved for TAs such that other TAs may not get resources to be
        installed or properly function. It may also install malicious TAs to
        potentially many devices under the condition that it also has a
        Trusted Component signer key that is trusted by the TEEs.  This makes
        TAMs high value high-value targets. A TAM could be compromised without impacting
        its certificate or raising concern from the TAM's operator.</t>
        <t>To mitigate this threat, TEEP Agents and Device Owners have several options,
including but potentially not limited to those listed below, options for detecting and mitigating a compromised TAM:</t>

<t><list style="numbers">
  <t>Apply TAM,
including but potentially not limited to the following:</t>
        <ol spacing="normal" type="1"><li>Apply an ACL to the TAM key, limiting which Trusted Components the TAM is permitted to install or update.</t>
  <t>Use update.</li>

        <li>Use a transparency log to expose a TAM compromise: compromise.  TAMs publish
        an out-of-band record of Trusted Component releases, allowing a TEE to
        cross-check the Trusted Components delivered against the Trusted Component installs
        Components installed in order to detect a TAM compromise.</t>
  <t>Use compromise.
	</li>
          <li>Use remote attestation of the TAM to prove trustworthiness.</t>
</list></t> trustworthiness.</li>
        </ol>
      </section>
      <section anchor="malicious-ta-removal"><name>Malicious anchor="malicious-ta-removal">
        <name>Malicious TA Removal</name>
        <t>It is possible that a rogue developer distributes a malicious Untrusted
Application and intends to get have a malicious TA installed. Such a TA
might be able to escape from malware detection by the REE, REE or access trusted
resources within the TEE (but could not access other TEEs, TEEs or access other
TA's
TAs if the TEE provides isolation between TAs).</t>
        <t>It is the responsibility
of the TAM to not install malicious TAs in the first place. The TEEP
architecture allows a TEEP Agent to decide which TAMs it trusts via Trust Anchors, Anchors
and delegates delegate the TA authenticity check to the TAMs it trusts.</t>

<t>It may happen that a
        <t>A TA that was previously considered trustworthy but is may later be
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 (and potentially notify the REE or Device Owner to remove any Untrusted
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 would occur
the next time connectivity does exist.
That is, to recover, the TEEP Agent
must be able to reach out to the TAM, for example example, whenever the
RequestPolicyCheck API (<xref target="apis"/>) is invoked by a timer or other event.</t>
        <t>Furthermore, the policy in the Verifier in an attestation process can be
updated so that any evidence that includes the malicious TA would 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 <xref target="attestation-roles"/> 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 <xref target="I-D.ietf-rats-architecture"/> target="RFC9334"/> for further discussion.</t>
      </section>
      <section anchor="tee-certificate-expiry-and-renewal"><name>TEE anchor="tee-certificate-expiry-and-renewal">
        <name>TEE Certificate Expiry and Renewal</name>
        <t>TEE device certificates are expected to be long-lived, longer
than the lifetime of a device.  A TAM certificate usually has a
moderate lifetime of 1 to 5 years.  A TAM should get renewed or
rekeyed certificates.  The root CA certificates for a TAM, which are
embedded into the Trust Anchor Store in a device, should have long
lifetimes that don't require device Trust Anchor updates.  On the
other hand, it is imperative that OEMs or device providers plan for
support of a Trust Anchor update in their shipped devices.</t>
        <t>For those cases where TEE devices are given certificates for which no good
expiration date can be assigned assigned, the recommendations in Section 4.1.2.5 of <xref target="RFC5280"/> target="RFC5280" sectionFormat="of" section="4.1.2.5"/> are applicable.</t>
      </section>
      <section anchor="keeping-secrets-from-the-tam"><name>Keeping anchor="keeping-secrets-from-the-tam">
        <name>Keeping Secrets from the TAM</name>
        <t>In some scenarios, it is desirable to protect the TA binary or Personalization Data
from being disclosed to the TAM that distributes them.  In such a scenario,
the files can be encrypted end-to-end between a Trusted Component Signer and a TEE.  However, there
must be some means of provisioning the decryption key into the TEE and/or some
means of the Trusted Component Signer securely learning a public key of the TEE that it can use to
encrypt. The Trusted Component Signer cannot necessarily even trust the
TAM to report the correct public key of a TEE for use with encryption, since the TAM might instead
provide the public key of a TEE that it controls.</t>
        <t>One way to solve this is for the Trusted Component Signer to run
        its own TAM that is only used to distribute the decryption key via the
        TEEP protocol, protocol and the key file can be a dependency in the manifest of
        the encrypted TA.  Thus, the TEEP Agent would look at the Trusted
        Component manifest, manifest to determine if there is a dependency with a TAM
        URI of the Trusted Component Signer's TAM.  The Agent would then
        install the dependency, dependency and then continue with the Trusted Component
        installation steps, including decrypting the TA binary with the
        relevant key.</t>
      </section>
      <section anchor="ree-privacy"><name>REE anchor="ree-privacy">
        <name>REE Privacy</name>
        <t>The TEEP architecture is applicable to cases where devices have a TEE that protects data
and code from the REE administrator.  In such cases, the TAM administrator, not the REE administrator,
controls the TEE in the devices.  As some examples:</t>

<t><list style="symbols">
  <t>a  Examples include:</t>
        <ul spacing="normal">
          <li>A cloud hoster may be the REE administrator where a customer administrator controls the TEE hosted in the cloud.</t>
  <t>a cloud.</li>
          <li>A device manufacturer might control the TEE in a device purchased by a customer</t>
</list></t> customer.</li>
        </ul>
	<t>The privacy risk is that data in the REE might be susceptible to
	disclosure to the TEE administrator.  This risk is not introduced by
	the TEEP architecture, but it is inherent in most uses of TEEs.  This
	risk can be mitigated by making sure the REE administrator is aware of and explicitly
	chooses to have a TEE that is managed by another party.  In the cloud
	hoster example, this choice is made by explicitly offering a service
	to customers to provide TEEs for them to administer.  In the device
	manufacturer example, this choice is made by the customer choosing to
	buy a device made by a given manufacturer.</t>
      </section>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document does not require actions by IANA.</t>

</section>
<section anchor="contributors"><name>Contributors</name>

<t><list style="symbols">
  <t>Andrew Atyeo, Intercede (andrew.atyeo@intercede.com)</t>
  <t>Liu Dapeng, Alibaba Group (maxpassion@gmail.com)</t>
</list></t>

</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned Smith, Russ Housley, Jeremy O'Donoghue, Anders Rundgren, and Brendan Moran for their feedback.</t> has no IANA actions.</t>
    </section>
  </middle>
  <back>

    <references title='Informative References'>

<reference anchor='RFC6024' target='https://www.rfc-editor.org/info/rfc6024'>
<front>
<title>Trust Anchor Management Requirements</title>
<author fullname='R. Reddy' initials='R.' surname='Reddy'><organization/></author>
<author fullname='C. Wallace' initials='C.' surname='Wallace'><organization/></author>
<date month='October' year='2010'/>
<abstract><t>A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative.  A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor.  This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.  This  document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6024'/>
<seriesInfo name='DOI' value='10.17487/RFC6024'/>
</reference>

<reference anchor='I-D.ietf-rats-architecture'>
   <front>
      <title>Remote Attestation Procedures Architecture</title>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Dave Thaler' initials='D.' surname='Thaler'>
         <organization>Microsoft</organization>
      </author>
      <author fullname='Michael Richardson' initials='M.' surname='Richardson'>
         <organization>Sandelman Software Works</organization>
      </author>
      <author fullname='Ned Smith' initials='N.' surname='Smith'>
         <organization>Intel Corporation</organization>
      </author>
      <author fullname='Wei Pan' initials='W.' surname='Pan'>
         <organization>Huawei Technologies</organization>
      </author>
      <date day='28' month='September' year='2022'/>
      <abstract>
	 <t>   In network protocol exchanges it is often useful for one end of a
   communication to know whether the other end is in an intended
   operating state.  This document provides an architectural overview of
   the entities involved that make such tests possible through the
   process of generating, conveying, and evaluating evidentiary claims.
   An attempt is made to provide for a model that is neutral toward
   processor architectures, the content of claims, and protocols.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-rats-architecture-22'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.txt' type='TXT'/>
</reference>

<reference anchor='I-D.ietf-rats-daa'>
   <front>
      <title>Direct Anonymous Attestation for the Remote Attestation Procedures Architecture</title>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Christopher Newton' initials='C.' surname='Newton'>
         <organization>University of Surrey</organization>
      </author>
      <author fullname='Liqun Chen' initials='L.' surname='Chen'>
         <organization>University of Surrey</organization>
      </author>
      <author fullname='Dave Thaler' initials='D.' surname='Thaler'>
         <organization>Microsoft</organization>
      </author>
      <date day='7' month='September' year='2022'/>
      <abstract>
	 <t>   This document maps the concept of Direct Anonymous Attestation (DAA)
   to the Remote Attestation Procedures (RATS) Architecture.  The role
   DAA Issuer is introduced and its interactions with existing RATS
   roles is specified.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-rats-daa-02'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-rats-daa-02.txt' type='TXT'/>
</reference>

<reference anchor='I-D.ietf-rats-eat'>
   <front>
      <title>The Entity Attestation Token (EAT)</title>
      <author fullname='Laurence Lundblade' initials='L.' surname='Lundblade'>
         <organization>Security Theory LLC</organization>
      </author>
      <author fullname='Giridhar Mandyam' initials='G.' surname='Mandyam'>
         <organization>Qualcomm Technologies Inc.</organization>
      </author>
      <author fullname='Jeremy O&#39;Donoghue' initials='J.' surname='O&#39;Donoghue'>
         <organization>Qualcomm Technologies Inc.</organization>
      </author>
      <author fullname='Carl Wallace' initials='C.' surname='Wallace'>
         <organization>Red Hound Software, Inc.</organization>
      </author>
      <date day='22' month='October' year='2022'/>
      <abstract>
	 <t>   An Entity Attestation Token (EAT) provides an attested claims set
   that describes

<displayreference target="I-D.ietf-rats-daa" to="RATS-DAA"/>
<displayreference target="I-D.ietf-rats-eat" to="EAT"/>
<displayreference target="I-D.ietf-suit-manifest" to="SUIT-MANIFEST"/>
<displayreference target="I-D.ietf-teep-otrp-over-http" to="TEEP-HTTP"/>
<displayreference target="I-D.ietf-teep-protocol" to="TEEP"/>
    <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6024.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/>

<!-- [I-D.ietf-rats-daa] IESG state and characteristics of an entity, a device like
   a smartphone, IoT device, network equipment or such.  This claims set
   is used by a relying party, server or service to determine how much
   it wishes to trust the entity.

   An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-rats-eat-17'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-rats-eat-17.txt' type='TXT'/>
</reference>

<reference anchor='RFC9019' target='https://www.rfc-editor.org/info/rfc9019'>
<front>
<title>A Firmware Update Architecture for Internet of Things</title>
<author fullname='B. Moran' initials='B.' surname='Moran'><organization/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organization/></author>
<author fullname='D. Brown' initials='D.' surname='Brown'><organization/></author>
<author fullname='M. Meriac' initials='M.' surname='Meriac'><organization/></author>
<date month='April' year='2021'/>
<abstract><t>Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.</t><t>In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.</t></abstract>
</front>
<seriesInfo name='RFC' value='9019'/>
<seriesInfo name='DOI' value='10.17487/RFC9019'/>
</reference>

<reference anchor='I-D.ietf-suit-manifest'>
   <front>
      <title>A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest</title>
      <author fullname='Brendan Moran' initials='B.' surname='Moran'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         <organization>Arm Limited</organization>
      </author>
      <author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Koen Zandberg' initials='K.' surname='Zandberg'>
         <organization>Inria</organization>
      </author>
      <author fullname='Øyvind Rønningstad' initials='O.' surname='Rønningstad'>
         <organization>Nordic Semiconductor</organization>
      </author>
      <date day='7' month='October' year='2022'/>
      <abstract>
	 <t>   This specification describes the format of a manifest.  A manifest is
   a bundle of metadata about code/data obtained by a recipient (chiefly
   the firmware for an IoT device), where to find the that code/data,
   the devices to which it applies, and cryptographic information
   protecting the manifest.  Software updates and Trusted Invocation
   both tend to use sequences of common operations, so the manifest
   encodes those sequences of operations, rather than declaring the
   metadata.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-suit-manifest-20'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-suit-manifest-20.txt' type='TXT'/>
</reference>

<reference anchor='I-D.ietf-teep-otrp-over-http'>
   <front>
      <title>HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication</title>
      <author fullname='Dave Thaler' initials='D.' surname='Thaler'>
         <organization>Microsoft</organization>
      </author>
      <date day='14' month='October' year='2022'/>
      <abstract>
	 <t>   The Trusted Execution Environment Provisioning (TEEP) Protocol is
   used to manage code and configuration data in a Trusted Execution
   Environment (TEE).  This document specifies the HTTP transport for
   TEEP communication where a Trusted Application Manager (TAM) service
   is used to manage code and data in TEEs on devices that can initiate
   communication to the TAM.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-teep-otrp-over-http-14'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-teep-otrp-over-http-14.txt' type='TXT'/>
</reference>

<reference anchor='I-D.ietf-teep-protocol'>
   <front>
      <title>Trusted Execution Environment Provisioning (TEEP) Protocol</title>
      <author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
         <organization>Arm Ltd.</organization>
      </author>
      <author fullname='Mingliang Pei' initials='M.' surname='Pei'>
         <organization>Broadcom</organization>
      </author>
      <author fullname='Dave Wheeler' initials='D. M.' surname='Wheeler'>
         <organization>Amazon</organization>
      </author>
      <author fullname='Dave Thaler' initials='D.' surname='Thaler'>
         <organization>Microsoft</organization>
      </author>
      <author fullname='Akira Tsukamoto' initials='A.' surname='Tsukamoto'>
         <organization>AIST</organization>
      </author>
      <date day='28' month='July' year='2022'/>
      <abstract>
	 <t>   This document specifies a protocol that installs, updates, and
   deletes Trusted Components in a device with a Trusted Execution
   Environment (TEE).  This specification defines an interoperable
   protocol for managing the lifecycle of Trusted Components.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-teep-protocol-10'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-teep-protocol-10.txt' type='TXT'/>
</reference>

<reference anchor='RFC7696' target='https://www.rfc-editor.org/info/rfc7696'>
<front>
<title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms</title>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></author>
<date month='November' year='2015'/>
<abstract><t>Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature.  Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly.  This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.</t></abstract>
</front>
<seriesInfo name='BCP' value='201'/>
<seriesInfo name='RFC' value='7696'/>
<seriesInfo name='DOI' value='10.17487/RFC7696'/>
</reference>

<reference anchor='RFC5280' target='https://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname='D. Cooper' initials='D.' surname='Cooper'><organization/></author>
<author fullname='S. Santesson' initials='S.' surname='Santesson'><organization/></author>
<author fullname='S. Farrell' initials='S.' surname='Farrell'><organization/></author>
<author fullname='S. Boeyen' initials='S.' surname='Boeyen'><organization/></author>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></author>
<author fullname='W. Polk' initials='W.' surname='Polk'><organization/></author>
<date month='May' year='2008'/>
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm I-D Exists -->

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rats-daa.xml"/>

<!-- [I-D.ietf-rats-eat] IESG state I-D Exists -->

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rats-eat.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9019.xml"/>

<!-- [I-D.ietf-suit-manifest] IESG state I-D Exists -->

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-suit-manifest.xml"/>

<!-- [I-D.ietf-teep-otrp-over-http] IESG state Waiting for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference> Writeup -->

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teep-otrp-over-http.xml"/>

<!-- [I-D.ietf-teep-protocol] IESG state I-D Exists  -->

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teep-protocol.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>

      <reference anchor="CC-Overview" target="https://confidentialcomputing.io/wp-content/uploads/sites/85/2021/03/confidentialcomputing_outreach_whitepaper-8-5x11-1.pdf">
        <front>
          <title>Confidential Computing: Hardware-Based Trusted Execution for Applications and Data</title>
    <author >
          <author>
            <organization>Confidential Computing Consortium</organization>
          </author>
          <date year="2021" month="January"/> year="2022" month="November"/>
        </front>
      </reference>

<reference anchor="CC-Technical-Analysis" target="https://confidentialcomputing.io/wp-content/uploads/sites/85/2022/01/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.2.pdf"> target="https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf">
        <front>
          <title>A Technical Analysis of Confidential Computing, v1.2</title>
    <author > Computing</title>
          <author>
            <organization>Confidential Computing Consortium</organization>
          </author>
          <date year="2021" month="October"/> year="2022" month="November"/>
        </front>
	<refcontent>v1.3</refcontent>
      </reference>

      <reference anchor="GPTEE" target="https://globalplatform.org/specs-library/tee-system-architecture/">
        <front>
    <title>GlobalPlatform Device Technology: TEE
          <title>TEE System Architecture, Architecture v1.3</title>
    <author >
          <author>
            <organization>GlobalPlatform</organization>
          </author>
          <date year="2022" month="May"/>
        </front>
        <seriesInfo name="GlobalPlatform" value="GPD_SPE_009"/>
      </reference>

      <reference anchor="GSMA" target="https://www.gsma.com/esim/wp-content/uploads/2020/06/SGP.22-v2.2.2.pdf">
        <front>
    <title>GP.22
          <title>SGP.22 RSP Technical Specification, Version 2.2.2</title>
    <author > Specification</title>
          <author>
            <organization>GSM Association</organization>
          </author>
          <date year="2020" month="June"/>
        </front>
	<refcontent>Version 2.2.2</refcontent>
      </reference>
      <reference anchor="OP-TEE" target="https://optee.readthedocs.io/en/latest/">
        <front>
          <title>OP-TEE Documentation</title>
    <author >
          <author>
            <organization>TrustedFirmware.org</organization>
          </author>
    <date year="2022"/>
        </front>
      </reference>

      <reference anchor="OTRP" target="https://globalplatform.org/specs-library/tee-management-framework-open-trust-protocol/">
        <front>
    <title>Open
          <title>TEE Management Framework: Open Trust Protocol (OTrP) Profile
          v1.1</title>
    <author >
          <author>
            <organization>GlobalPlatform</organization>
          </author>
          <date year="2020" month="July"/>
        </front>
        <seriesInfo name="GlobalPlatform" value="GPD_SPE_123"/>
      </reference>

      <reference anchor="SGX" target="https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html">
        <front>
          <title>Intel(R) Software Guard Extensions (Intel (R) SGX)</title>
    <author >
          <author>
            <organization>Intel</organization>
          </author>
    <date year="n.d."/>
        </front>
      </reference>

	   <reference anchor="TrustZone" target="https://developer.arm.com/ip-products/security-ip/trustzone"> target="https://www.arm.com/technologies/trustzone-for-cortex-a">
        <front>
    <title>Arm TrustZone Technology</title>
    <author >
          <title>TrustZone for Cortex-A</title>
          <author>
            <organization>Arm</organization>
          </author>
    <date year="n.d."/>
        </front>
      </reference>

<reference anchor='RFC4949' target='https://www.rfc-editor.org/info/rfc4949'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author fullname='R. Shirey' initials='R.' surname='Shirey'><organization/></author>
<date month='August' year='2007'/>
<abstract><t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
    </references>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgments</name>
      <t>We would like to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information thank <contact fullname="Nick Cook"/>, <contact
      fullname="Minho Yoo"/>, <contact fullname="Brian Witten"/>, <contact
      fullname="Tyler Kim"/>, <contact fullname="Alin Mutu"/>, <contact
      fullname="Juergen Schoenwaelder"/>, <contact fullname="Nicolae
      Paladi"/>, <contact fullname="Sorin Faibish"/>, <contact fullname="Ned
      Smith"/>, <contact fullname="Russ Housley"/>, <contact fullname="Jeremy
      O'Donoghue"/>, <contact fullname="Anders Rundgren"/>, and <contact
      fullname="Brendan Moran"/> for the Internet community.</t></abstract>
</front>
<seriesInfo name='FYI' value='36'/>
<seriesInfo name='RFC' value='4949'/>
<seriesInfo name='DOI' value='10.17487/RFC4949'/>
</reference>

    </references> their feedback.</t>
    </section>
    <section anchor="contributors" numbered="false">
      <name>Contributors</name>
<contact fullname="Andrew Atyeo">
<organization>Intercede</organization>
<address>
<email>andrew.atyeo@intercede.com</email>
</address>
</contact>

<contact fullname="Liu Dapeng">
<organization>Alibaba Group</organization>
<address>
<email>maxpassion@gmail.com</email>
</address>
</contact>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAB/SVmMAA+29W5cbx7Em+p6/oha11qh7CIAibXlvU3s8hkhJ5ti0esjW
yGcetlcBKDTKBKqwqwrdhEnOb5+4Z2RdmqS2j9d5OP1AdgNVeY2MjMsXEfP5
PHRlty+eZtfNqe2KTfbd22J96sq6yr6rbsumrg5F1WVXTX1btvBpWd1kF9ff
fXd1mS2b9a7sinV3aoqQr1ZNcQvNwFfpN5t6XeUH6GHT5NtuXhbddt4VxXGe
u6fmj38b1nlX3NTN+WlWVts6hPLYPM06HNaTr7767VdPQt4U+dPsNYyvKbtz
uKubNzdNfTpyr+FNcYaPNk+zF1VXNFXRzZ9jjyG0XV5t/prv6wpGcS7acCyf
hixrtuti03bnvXyaZV29dr+W1Qamrh+0ddM1xba1v8+H5M+uKdf28Lo+4LLZ
t2W1L6vYTfG2m+/LtptDI6t6D4/N6//6EL6BtTrkxyMsMj+bn7pd3cBg5/Al
/ZQVPP1ykV0VpX7Eq/sSXtqXOWyP+6pubvKq/HuO+/k0+7ap8w0MTb8tDnm5
f5od9M3FsSh/v5KHFvhgv+M/LLLrdr2rt0VV3qT9/yGvqqId+Todw7I5ZH8q
D7Dvm94wdtTAorMGfp8346N4DqPY5fuiSUfwPL8tel+kfb8s103d1kASac+b
jl76/UG/n+r1511RjHVbbvpf9SZ9yP9eV/1eYbh38Nbvc/qW+0TKbw7w2m2B
JPrq+2e/+erJr/HXF/PnCzo7Td61ydkZfrvJ8+GHRd5Jk7/96vFvk+/bU9nN
DzDgbdF2yTd0UOuugX9ui2a+67rj8PtjU8NxqffS/L/85re/kV+/fvKvXz3N
4Pdnz+Y/QgO3ZXH3lNbBKFuX62n2rK62JR65Mt/DH4cjsCEgZ/gYz155YroV
dvVg/Gmkw2ZzB5xi/m3eAjsbsjVY4Gx5PO7LNe1OmwFzgE3s8gfU/ga40NPs
yVdPHs+/esw95s1NAUcbJ98+ffRo7Xpea8eLsn50d5zDdx188+h03MMxah+1
sEnto3/9+hE2+OirX42//Nf6BLwlX+/+eoe7esyPsNb/Ov/67ePH88eL42bL
K3hdrHcVDHs/X1b5/tyW7T9oLZeZNZ1p01m9nWhllt0+XjwZrNbjr/6hq/Xk
0VePHz2DWS9H5j2vt3M/uLkNbo5jkyX74Qruhckl+mFfr/L91T7v8Mgl65F+
lT0vbst1wWtU7+ubM1042eszUNYhuexoaX7VW5on86++Hl2aG+rmKN0sYFSP
2mOxbuFuWDV5c34EpwuuCOwlOfCPqLW2aMqiRYah00qHDTO8ev7X11ff/RVu
T1yN1y+X04vx+mW2bFu49OhQpKtxtXjyJHv1+spRyWsYZ7mVIzTL/lfRoHCQ
PYG171PGV/OvfjM6/bu7u8VNe8iR8z2CmRzGSAIbePTVbx69plHMb6kH2d8f
r+b3bbAc/e/L5oAMAdc3mRe/nj2v1ye8rGkq/a0bHXh9hI1ZwIGFi6OAK7tF
ci6qR7DwwD9xd368fnX1Swjvx2NR8bhR4iKmml38eN2AtAV/b8t9gQT2eLjC
//LLCQz4fn5T4ArMtw3caChWzWsYyJxkL+Pun0t1j5/8Cp54/cNfJhcC5bR9
Mn/65OLVZfYabmHctOyHE/Bz4N5AFC1x6wt6JqOHfvjL5YNJ0irxOaItpSn4
9NGpxZ1KRE/g/3CP6dl+1ErX8xvsel5Y14tdd8Dh0v78bxQmpya27G0rCj32
luMj44PfFLfFHjagWYgA9KikO3ZzWnfAI0X8nZfHR7RBIDsUIczn8yxfgRSa
r0HiXX5EnEcJ/jIr8e7LCvc5CEJdKFAGWYMsh3/BE2cQZzdFdld2u7LiD/07
a5Db6i5bFTCRA4waOsVHZwHvVWsCiDXPTngjr85Ze1rvuNH4Mh4nWL20kQAP
2wDgkmyB4Q9GsAjXO5yK21MUpOlQZ4caZCk8l/AafAyke1PRjU9KAWywCGkB
rrs8U1onIYEOBt6a+OYeZKP1eQ0HEB7sZHFzJ0aE5lSRdgTCIo6S5pjjRbHg
3TmUm80edip8kSHl835iz4kwUvB+UTvw+oavHjwJxdtjjevX1TgyWNFyu4WF
gjnmXZev37QBKR50FnoEr9qmPpRtQcMvjAxw+PCBGzquOuhuBbB1+CbwTh3h
cxBGYA5A3W3yfEvDQQLN6S4HmbvAJ3gUMO417GVbBNxA6qs6HVZFgz3X8GeT
tlVXsjM40RntOq8dPRuSZ2FSuDJbmFh2rDu++/fn7FTRjgDn6nZAXfUJyZfG
Fewx2lId4/bU0Eh0rG1mg8WF2xdv4YThgLcgNQM9tUTM/XHzmNtZxpRewDhs
C/AXPIu8XoeayAgWMmiLWb9FGm/WlO0b7FhHWiMVsAwQRxtyJucWORPQtwy2
t68tbiztZrLGsZlFWDIHeJvjnGdMYnh8oDHSUlpe6zzDP7L1vkRyg7O2L98U
sO5AZyt8OACHXYPKjR+UHfR7VxXNLFudgDY9JdIZW+XVG9xFT4FNXuK0gAir
7AYGB2uXSZswyoAL8ykMjV450gj5pPNZ2BddSkd8Ggo+YnjmgWvAo31OmE1w
wvC5rDD7JF4YPsIMs09hhtAX7O/+tMElxhfIFlFviET0yCpBXZRbmD4c3qq7
XIQXjtSov8Np35VAGMjEgMo74rL7FvhPkVeyKDQYWAu62ECa+pRJ6Dt5xfyA
eSQx8RaUn0ZoogAGKXwbyLItV+UezT5ERLBq8F27Pe3lpNBBcRSFVAdjqrrW
TictO8oCeVnRCZUFLAIOILs+H1G03Z9nkw3ByVjjISZCj0RE7RCrh2mvc9jZ
MGCavh1YDdIr9Cq3c2xcVQ4v/wWfViE+gtNYgJo23nrWu4Z4WGXLZFDBoW0K
uDYaOhnholjcLGa4F+/ekbb04cMMfmXJGH8vuvXiMgN2kwc9gO66gmO3vJzh
PQFEkqcj0nEooSLlQqPQ2aLgLnHlX+ENM3GkX8GRngUYuhsxDaXKfqq6sdH8
tLxcwN0qNx4xtUmeAweF6JCouCn2LCPUzERBpMNbQ9o1qWBdn/YbeJgmRMzj
eimzx9c8k8lAvivXWTyLf7i+vootAZW3+Cm3uCoSuuTGRue4QNkhyzdwnmkO
0CCeA1robQZ8Hb4ANgQiM1+6REb5GrqBFQUxPa/wSFmvGzy2OhFY2pJ4Z4/W
iP0Cm1gjC6c1a2E89CQyiAOs3P5MssqaTMR6FQUTZKFn5HZyDeVtW3RyrmGE
KGjkeCxg8YUX04gbWjbZkW6HtwJIcxuQ6bOAJ5bPY6enlhkqzGXN9zkwFhio
qhF6E0rfVcHUtCoc+6er7lSxPF/+HeU7YjKB25IhwJ1ew7Ie8nO2Q4PjcXdu
SSXGhd6AfFKiEE6rx68T1crdC9uHbC7A8p6YTPIGbz4STpRiYQ43+YGpo2rr
vc0GVqmcr3c4Chk1toBMWS/LWRCZRMTPNltevyQaeFFfq7ySgUK45rXa13ol
Sg/ES5FsDuXNrktnGHg+s2xd7IGCdzXae5FLERPXxmkbSHyuV3gwjvmZTOEs
JQFbxKVe7+tTct+C9JO9xiH7z/Auoct0V59wNHiU22x3XjXlxvrjgSMdQ89N
bxdqEiNA1t4zvQFLYbkrROn5oilASSguP/a+cFKm4RYU5bj1trnhRUeUQbfk
irkC0iO+1tYHOubYMB10nQFxoI6mAXtZ1TTKC+LV1Oel3mBNEbBxaBcewq3b
Zw9w0A/wHMGpnWXyEs+IxptMZhG+hxmp8Lsp2/Wp1RMrcogz+Jm1DldGjhWP
JJ7FGXRbhHfvnH33wwd6ij4bWu4+fFjI6cVGd2KsVUmLpaj6sKIFYl1Aj7Aj
eThRdHfCFEmC3cB9W5SNXI3UeuQLNW40irB1g2ocuR7gdSKnFoe8ZsaPTcFW
0IEKFVrh8e38FiTffIUcvh6/dlBA/TNIPPB4FtmS0MgMKP4O2GDD5B+pDiTd
TcJH7KtQIhcwixQZYqldWo7YgkkPsDCw/12JmkhsRfWMfsdCzyDDrWGyZXug
yUdJA9dhkb0GYg1+jDChQ1vsbwv8s3kDy2fSYWx7ZJghjg65y0lE8vgOtwZd
LlU/4W6pV9SibnBgAQ84MZWGxVH8iq6GMrKeTXGEV+kurHSUyOlJhQCSwYUt
t2fT52llqVu+ptqotVU3rL4iUfD9iKILEgc+QauFNDFuL8CXohgWeusDnd4C
169PrQ285Bup2CwyloKV5k9HNPLFbgJNh00Ab9DG0BQqhh+OQC5Ep2qcgG0/
GcE68ROlfpDGLomfVqnUgp2C5NgBMccLG+7iBm9lZXMkYcEwkb8U65pVhllg
FgZDL+xay/mmJdUb9Uz0y6KZQQYFUlBHWiQcENmYwOynAyl8vc/Lg9AvLDho
kK2dB79rs4EiXpJO0YphaKLbkq+EMbH2JZlEGxRvX15+kv455h+3XQNxDQ4i
KrjY4bbe7+s7fA4egA07tE9DyLI5ivS69I3szbicSzvOxC4GgpsSNefrJdkT
TZpqiv84FW2nrebR/gPvwxKW3izwJe0n23hru5MG746PCC9qNpx0Bev9tLTS
nhGtbDNc2XQBqYlsSTLMGkQi4rhR/gINBd+Hs6RjvZYLHO/RE17BzgrUgty7
5kdgucUIJEubUAwu/G1JjEIk+Fol27IDJrdlfYkUqEb81MnNaCu8gfkCYQJv
EuO42GZBnyhuc7SVqD+XV88Meqtii5wsV1IgoqU2YDwmmDJJMcfU2ZvtobDz
uDQTDg9DKJtW22x8W/6OhOnzsZBbRRQUlgajuVGtFSzlr/MjcTttIy4fG6Hi
PSQXdEukV8LaxfVn2cm6MJqIS6hkQTZpZAEyYBiHLTg7K4RoUqtWm1KOPgrM
mBfFCIjZxB0fAl4q7g/bIEbTdb4Jm4P4AZeJfDhCC8hfcYDFW3gK+a2OQPjq
JR9aGfhFHNklDw3er+pupi/wtzhf20G2mHzKqEBdWL+JSyvrlrMDyR18JZoD
COhw7cy7ek5Xzy179tKBybWE7FpINs7hE8eFIuqtbKTYGNPhbONk/dFlCXlf
V8ifDyBIo9bMpEj7idaIotL3djkv/aoo0KB0W78pNjOUI6iZLiorrMOgWZQR
AWcSNMQ8sjmR9Id3JTZWvD0iaQP7WrXrpjwixeMtgbI1y544FJI2zsrycPXQ
oZmJVfJ6+aXaVqt4Swf08Ml1itcfXHjrxKiywYUsV6fELNFmoifhbEhsqU8k
ntvpJ7WzsPtGd2t1AmpEu9YKtmKmtz0vBciGm1mQY0z3+J11qDYc2fFo1mAT
dvIRSdM5XCn7iL6Ii7TO7c6jJSoqYOokiHrBa87C/iaoumr6sKieNRLCvBWf
dOxbfTy6ke/eoRP8w4cZaCzoov3w4ZLHcSjUIsF8Scgj36MNE8VQXNsFuW6u
6ZCT+y5790UX//rAckK83vE71gZwY/SSPx6z13ASiqfItmvChZkazhTBbpdx
XUO3elPfVUhPxmH5tEGjUSs9lsWamLZpWTRXVMHbrC9Pz4i0RXjD48X+N3Jw
VqiRJv2kp/ppRlcQ81C+N/AGaI94heLFse3ZRgRg4C7EmczaLFO4F9LXj+hN
WExwFGoIjjlsenkLp+em6LmUyCfhSEwYz8Ty4hNAerwacPIafJb8Y39DCZhd
88tqDfeMiJsjDyXCKbdEDiC2YqNKSmQ7NeKpqeLeU2tys7Ea07JdBImO+MrL
Fk3sdPrP0XnJT9HwqQmZwqDjPdtaYF9GR6DaqogBNn5SMemFeAqj4UWMFSjb
SWt4FbkraOa3e9gjDBUFNLk10NrIi+oas83eNTJ+WImUZImMnkY1k5wZd/mZ
3VXsiwGtFw4GaThsrkGjx0zFILKgIzHb1XQBawCKJuhS0ijZkPCuQAMQtJv4
NkFn0x3hj6gdfOURecz4ramloFEVqH4eUblKLWUkX9Ao6UTHoap4o291w2Hh
5rGGdu6PCx8n6wTcufCEWk/Ss5w1aCtso16IqzYz6cB1DmelLsmTMr7ZyjuQ
9/ZWiRYo3dCfWt7P3elATNGkgBOrnkrUL+PE2ki9cCch7rXwO8d2j+RZchDS
HidbbMxRbss4hBZtlHBh1XjzJC+1eg3lqIGS416uCtYwduUe9ESybp3YbV+i
8wwYaEeLnx+7+ni5yH5M7K3I11WUYVkHLYB+TcjuWlTrwrbST5mX9IoM8fle
0BCEh8S1FTsZaT83J9lvsqTrXtl5Z2XNMV4YMy8qXotjHdDhZj1WGZGoJtgS
S+qkrJfr0z5vRIfAS11ZBsp7JDfciszHNtytG8Y3ga8w5w8aHwsZvFe44bB7
Dcy7PR8OBcK6szfF2daXlpeVNDxlJzRvdoXaKg+F2hRlYV/ld9nVaQU3TPbH
4oxL2sAnR/4E2yU9k27kLZtvyUWyvwFFptsdMtY5t6VAiy9wgS51hvi+ejfX
zRno46bJjzsUgWIH6J9pQGudmU9AT+br0wovLB4ejO4FKKsIZD8xhoau56s/
vvhLtkYD3pYn+u6d4Ho/fBBSNFxYXFFWekXI29REoA16ieC75es/Lx4nVnJc
WnTq0Hp9xCH4lEWNnqMeFTdSSuUM4KLcIGJZGHuu9uDsx9d6Cv9UVqe3s+zn
sgJhCpj8sto0dQnqQfnj60u+tr11AT1LdfW3U8UmaNrvWswYwNYaMpT3Peyt
jWYH+wZ00cKl+41wavWMymYCdV+0l3K506hH5Ws0aLnpo/FbZJUoxZjvtcKu
yG1t1gxnE7xQAVCce/szT3tPXit5iEzi7IcQkvZCEGwHmjG36rkk6kDIunkB
BG+OQje2/WDJLcO3+D5QhQAQyK8rGnzH/jORKG/LHPkAUSm1oWSfC2AVfSlk
+WctJ5J+Ke6oaHralDfQOoMOURXzNnLxTfomfQvmujFG1aoU6608eJMqcKpI
5xpNFDzBBeP/zLooa5qJkyf35w5ZYY9zmNpqR1aEzZaFUri34EW4ljvVGkCN
q6t5U8Np9EeaNGamyaTPkf023WVq12f9Healxre4fblRvP7hH2/52cQetVgs
WGjVm8WcJvw6Uii2lyw2NTPLEFWP/dGWiPR8VqaDh8wPJIFjPchwlsC53Bw9
JecjC5Md8BMECLSpBp7lNzleXYl/Wa1CuOJoYtkUcNWbsSVR4N1OjEAwnvbh
IHCyZ+Zz7PmTZn2khrkGRBkG7hF173t6TqzkT/sqIPOxVt/kDeyrWoL/kcaf
RR9FdJ9MOU16A7N3E6mFcCebR+r910kZk8Wjgqi9LkpO98x0kY192xoPHpUr
WO8+tZ6xs1zmTK/MBwbL4DqEe4txX41x5q0A2+l0y12qBiryN9D8RhaXgWjD
b5xPYWp1UfZmzXaw4aLzqmmBzxqZF4bzmmr9NVrHhk0jp25HRxyNFMQSdWZk
J9+Lx4cFUDK8NSLm1fqLwvVEIiK3vvScp/6hkSVYZN9H2MZsdHzUi5gg1fZ3
QdfenP+6ZKobVYdKEwxoNnzbkIhIjGdaUVxOjcRELlAHUF4sNszLpCd2gXjf
R+L3mHmYihhac2ebNeOu8xKIiVetkowzJurvWu4PNVJkAy0z+YQy7gF7MpHY
9/djN+PSOR+BAtANyedcK+YmSLCa1tSnYNcN6RihmmIg57uMXFm4HTcFECbJ
mLs86q3Ilv7jVBCmS9xOajKVXtcY0LpZqAzRMEzc3PIW0lAWztqqNx9axfRe
0OtM50wmI9xVhkiIewcu0hI+3BAjRsVTMVr7M48hAab1QBio0BK0ohZXosEP
YETdXaFhL33WijjLCt3c0RdESNOlrgMu/UzMXYTywjuU15oBX5VsNDlUa9NX
rpfChKahhINb1V1KYhPFJ8YbYPZHZy5quInRddmSQfknWJlnBOoOX3yRXTFa
CiM4BDiVjIAuMAFWCZmIib7NdtCZ2y0ExRCbEIpGsy8OXq0i0hPe9LBluQHg
tH1BkhHR0O6NbVBgzB6dc+A+aORUhVXlHnTeg8S55biJvGoZFC/+krwHE0sR
miS+rMpa1PC06eClbrYbK3fzIiRje8mz5TtKUA86R1KQ+8L8qdrX657hjqYV
8FuGYfUmLRqd2FeWdmOTdYIQJNscPX8/vbhMxNGR7YUuyGaGEY9tvndW7XBE
ZkoIGpgIiUaGG6GdhC6Z1UY8pwzgCJyYoZ2EucODmciI4gcAjb0sBGGA3Arn
61znjG4kEgDl6rhDJtZGK8PViz9LV7TPugabsj3u8/NMUQZBcXlyoOsVGlCK
yE5jaIYbPeo+pw5+W9CxWSaAXSYt4CsdweLkRCADSB6bRV6LmyA6StdiIgEW
T1ObCgfN4Yok2GoyiroFwfsvfXErRoNWVNm7Yr+fR/VJycFQfnBxBEK/p63C
sPADteegxQSmrskOyL6/QwNkCD8X+Zs4caCq4UPZxYv6+tKZOlt2kh7rlkkd
MX46mbIj2wmcjCaPyqZ4AQ3Om7OpASXPGHFDiBeZP1o6Gb0POnbBTAoBRFV9
OJOaKnEbjK2iBj1sFU+po3kk9ECEjpHrx9M+l11AaG0dra3x/MJ213VziQ7g
YIeD+LE6S1Lkc6TlHiA83skYdNVz3VwzLVNkTGXWnRUCccjb4G9e7gAmGWy3
jFh60qUB9Nm8TcaFojlkDwzVZIfwAbtKtmy/py463nRSPATHS545koloEROp
h834MZoGudP0N6ZppqGgc0IElXnV2RZ29SYHaYEINw0uJ0CwRXET0yyqnGNq
5GhObc4a5g+9493fUcwSusoICR88En4W1T/6hTHIBnINxHYaXS4SNMQa60ai
p3GngxCCxAZIgqZG9a6Vq7GRm3WtUH19HcklNo4RhOL3FvYiQ1LeK5hXixER
l/kO7eEbjttTMhJLoQwAN74CftOxa4UnVkvXrURaMrtMWuEILnJK1RNTY+g6
x+psAuw2R+kwXEQCzRTvnW/qo9z9X6Q5YpAeJJw+aokhvHsHwy1RpcbgTiD9
dlffCU4lL5OYGtpSNfIKV6eLgyU1QX2TMPD9aY+PGHaj5Qg2awqXCLcVr9T9
2excgkEmIzOs576+WzBf1Sg/aAWdzL2AIUVbg1K+TwI8HA4wb3K6K1Ai/D/w
g8Ljw/nn/GDymOy9qoOf9PM+GzU6BPtq9MeG9bDXUPxhJd7a6U/kYfrS+7Fv
Y9vWzHtCgjzu9fqeDeRpMw8HY/LNpDN4TwN8j7lx3sAuvXftv+dXHrpWXTOx
Z2nmvZ/Uv8WBcA+/ex+/epg0s7zBi0BfSQb/3v57r2v5Hh3bsAz3zijrD+Uh
t4EP/u59NjGU3pJlWdbf7vduku+nFuYhfyb/jZFS2gzO54m8HGxHfvf+ejl/
DE/Cf0/ikJNOXTMPk2GGuGi2zHFX8Od99hO0S2TzMNk5P0zXzGBSSYeeBpKf
5+bAfu9XLCFUGMjjZNeSdgZgl4nBxk1NG4orOvyxVxLieX8fB0hfGW7/yE+6
UtbQL+FxxBvfPc2+8NcCZ1n4bw/+LJ8lN4vAXK8efLjf5ChZgEasaSDidHCl
/V1iOiRgJOKXgHxTtKmLDF/c0594RTclQuv3Zws9oJY5hkIbGR8W6izFHgFH
AhjgsfB1TPE/45ArkTA6slltY9QCeUrk5tRRfbr1nyDWL8eAXxLtil1YEgUH
Y2Ktf61R7NWYwbpGaXqX77cGYhpbUvO1jq6XSERidG9TYLta8NUDM9qPuAk5
LoVa6RlEKUUWUMk8Fyw342RFeSuOY1NzUFvSOPcF2iKObFwdPs9W6p2i5BjM
hmEjiPvCkZk1xiKb2BnzBlVb2OO2RHFUzPPT1AnTGqe6CE7BPr9stSN3BmJg
kIRl8MYotMyDfBQmbkeJCE5cokBOQjstWYsdvYxuTx/3x1AwcbI5OY3FwgRu
fCX3v8IQMR74zIt9AJmdHFlqp+RjRvKkZDu8GYm7VmMvGwLpuZ4SWVogOMmT
9zUuq/KzIZuTbkX41fBFh7dShBdo/pjVp59yAj1IxR0cAp6pxbxpFC61yDpG
r0nFLjerssNEQqgRVor9p68s6Eb6VihYiZFgDLDj6I9NcdzXZ05dwLNPUhvo
0BN3jcbjKZsSm3zV5esuWTiORbFYg7sczoBaJdy2i3ufXi87s6inKWXIB9zT
R9AGjtkVJMGMYN9QKUUbD/7PHk5CVABjpCSRqMESsFCdjnDmb8n6cCIOzEos
A86dI58HTCZUhJtElLOBm+/L2qdeazmEPKxhYxFgLFrPqUL9dYBEcaB5msql
kCjfAmLTZKxCEkS5ZVAYQVQpI8AUB5qx1RBa8057hJwyGKLS6Gy6Z8iPvzdn
fm5IRUs9cz+/U+sTKGkcC64u7LOj/RYRnNVpmxM9KP5XCXSdN02ptxA5H1Gd
ZxAfIi5l6I7JjXnpeDxT7FeQsG0PFgcrrgH23LtEewiTptAO6Wl1jkZPsigQ
L43iikV0TL6lTkli/gnWhrZsvUOcA95gXS2Mv/JOtwQzUQ6BqOhvJI7PXJr0
acHddAnmxDC4vsVx1+dHFhVpC/ZKG5T9ggnGSLYYqg0zvSvbXXLdkZOFBAJp
A2Mj++uDa+PhPESmHoWDiRv84mmKDCPcBGnyy2moRA5dEP9UyTYmegExQgQl
WBX1W9stnUa5jl7AI1HBBJVyZEbN0iXho4CTgxXTB+jKC2nHN/rnboZ43nUx
ShYCzmH5oPVj0+YJZs4pOHC3ZIzoT7RAZjkX7SQ8X2Fbcjnlm01KTl9yq/8p
mtBAwNHJSaxYjIiWoA64AyRzFpEm8cYIK8JggLOLgFPi0JBwlsuy75UfS3hi
zMBD+PiDRhYQLgvFtcl5ugBjB/L6sh2l8vRSQX4FK5FzwhaUNnbl0WtLKSFh
x6P8WWHtsFqHXpgdHltyAJVVspj3jW9Psg5e7JQ9yIZLSwDMgrAObgHo9kLr
nzMQjAjaw4Glq5hudpa3xm+3MKC5RMCbv5U0uSj0PGVfhclAnA3wY0mFYHav
FEl3D0xXMRh4GMRgy3J0lCCKt4gAuClU9lUUgpd/ExRgb7ybulBbLeXAMUld
wB5OZRRsA3LzQ0E45BE9lWR+crCpxI88KvITpvzETcKvAa1VatWHr760pmNC
Ibr0saUXZhtgqtVsHxoYQCmoJXIGw8Al0I2uQRCJUdoXhWYsdaOLY6Obsoxx
xwNEDe+ga4DkWx/P9uHShfjJot+p5pmvWg8/VoOCXViJsBjlTHvfXGDFpqcy
SQy2J1iS5Z/G4EJWfQhO6hIggRx+2hc9RSxiWwTcWKyLErNY4H5KgHxLsHpB
qhAZIMqFXLVu7hGBYjoXuRYujTBlWDFSnXhA3rRF7Ek0b6CcO/RN2eeKghpO
yCegYO1U4onpSpC5qTsGiC915ePglByVskVdavhzTbOU+yWRNFCYM2r9xlHx
jIGsEdlDbU2umWziM2NbSI9LwUCfs4tnhLLJni0tF6mPIWxPmNSDEdss7zn+
h/5dij2hXfvL4uuvfpt8zVlzbmvQqSS/Ek6BRZqSJ61Kt4GFyk6iY/NeyMN/
f/X9s1//9te/xZgHauKZH4gkfKliOLFX9dnxrCIuLyLdpfeqJOhX1ww9CkAm
cVxg0jgSOhDPlmZLdFmtOsk/801PasKnRcOTTHYg25Pljzc3SRUjV+oziaD3
8LHVefhccvUyLuOlzyDICys3XkgirVi7j27xJPMgLPkLldwkII9gEjFkB9W+
dpejiOqZVWA6EtuPUynkfLapArIIf9BcPeTNpicuEgvf6x/+AvsA/2LksAQu
kBAhqXFyy2AYM7qByCHAwkNxqJuzYSFzDZHcM6yD7akpCHGBGHS0C2h6FZuz
XyKdsU0I2NJM0pbx5rpVcVFLsiSD3DouCoIeQJtIYA2ZmY5idhQtOB5NG3Yg
4ZDK1Iqh2iWT8VwC84dH/mC5R+zRZTB8CqXJJwUdabeAyZA6fMjJe11vJRuS
Rd5zPh5MPQRcTQDwgdkoRWajtnlToJhCaeV24wvLdpiceC85oS0hyaZE1+1B
HMIMPELfMSaw8Q088W9akiFdfzFdqOwzDikkwLw9KgJNqAThEaX6VrL4xGTA
ct+W0fnsLVu/0Omc+HM+1/38y5zPE83EH1F944hG5tTzME81lX3c+fy5bYz4
DIf+9J5Dc8rt7L28o05w53Ke8jk7f+jQA/4++Y8dtVnSyONkCPyvLFEcyMO0
kY+sRt/zHR24Iw30FrrXwL/No5P4vhH0PNXpCNTzjn53dbxnVzUcybNfihFX
dbL26v11vne/JwYP8H7qhz0aMMfv+1HaGHVS91EQrg32uqdu9/f9F/T5Uad7
Dxpwn5P74Xza4/7vrrf7/NueXPpucv0/cbdPuLyju32slTF3++g4/EuDhkZ5
z3tdQHnIHY7hi8xwnvguBq73h+MvPky+HXnRVrD3orCR9/Zi33P/fvJF4ifG
TgYcdvrFJ24FhuQ3+WJ/jp/8Yv+Jz+vx4S94EbnCr/REy4uRLB7e82Iy4vfy
nHB6ZisfG2r829i7vnH/4sS/ZYuybADU+sgF+7D39/0gkbGfz4aITABEnnwS
QmQk5TmCRl6kYp6kSvKS3eOY6WToZma1uZU4xvljroqRCoaf/voTg3VKyDTq
KWG9Q2NqdSNqLuvxZUzItz+npSxUFyV7ubNWwpoFHcJAV4oqBoUDOPeTlZdJ
A4DYGk/qhDrvJDERpuoTJWkjBR/udjV+HFVKS+Bnup4mvg2WUTIZFQKddyz3
uox7lbM1j/krGusI1FpO9ZZorYiqwA175c3NnCs2YPEEUwVSz/ATjINODCER
iRvVr5JslGyC6Oc3FWMSx5amYUMvpVIE61Ri4GONRmyU6SaqxhgOuVRxwcZU
CeVwCs1ENqp4sOE0yfYdmI5ivu8eWiE1iJFCeTqYLmLue82YN7P8M5LIsr9V
pMyKTzPvRowmZet2mvIawDV+4Gz+pYUTX0YIOGGeY5z+YLii/8JcviMFeqxH
MU0hPVMs58xSIEp8I6evJV2QEsCVlIU+jIeVJpa2CavQIiYLGHP5UdW2TkEi
04GrsqNViEmOXP4TyarGWVItAmI8+5ahAOhpjAWCo3yIwaSmtwMxFRVajjDd
oeT6yttoqOLHOVw2hsoiTEAPo7Sg2aY0Ex5HOZdbdELdIadw6XaXhEu4x0fK
Z6iXDU0PfWIoGV1RzNfhLfxJwMZ9+yirLYmtOGkXefCp7g7j2yktMqc5dnQK
J5zjYCS4lpxwC47/1Ozg1B4dlCEarHYJe3p+2RnHT5IIPUhkQl/aqzeFBjfB
bdoUN6UUrOg72+71x/Nog1Zo2kx6pPHU1s2GcTqH/G15oEfYvXUsoFNBOJLf
iLEmHIXgHdL96aqfO9YyMVoc2iUI0MFnC49ITAou+cZSD3oIBtWK0dGfl9F3
uGriTJQswhPtKGhIQmbseOJHTYHBXfD5eZYOLXBYBnEytI230zY9Bc9psVAx
1WuSIqyVQGk4X0YzM+Oq+M4eZ30x35rVRWgnwulzAfokm8BuB0nnhSdkzo5u
V6hox2yOQjaLJCFZUi1pGhBJJ4hM+es9leES7oChNmz0w+ye4vOGZls12BLl
yDBWI4Q9udRftnGV52ziplPMiX0K6JEMgttevC6dAWHh8YV8AmvBFV6yb7ls
zRAYEVKPQOpd5/hiz29fsrwWB84JPgkbY1MPkT9J6iR6x1AmQ/qQ85RKVObJ
y81pddEWfKO84g+ul9ny6gXLZ/kRiw9c3i/qJMkix8SQPOZSBDr76dWLKN1q
aNC2npJSYnS987Id81bi8VM5ZBFebPuiCUpcG1cxYoReDeu4cjiLWb8hvfeS
UwOzCQrOlaxkmmKD3teZ67rRNvos1WUfnYoYJsy5yynHqAJOdAWbCM/gy0qQ
7HrLwWh4vVZwvVStbv4APrAYxcUGTM6Li1x15NMVUhlfs16G0NGH/GlE9yFL
Bcyyi2qNrI9M9GeDVvbz7s8UYS+vnJPDMUJY4rMMlkw8voplgLaKF41D4IzT
mYXigp5Ip4rq6g4QJUPq7sYAxhgL2BK0RULW2nhRkrN6g1o0Mdbe/ATAO0KQ
KDcyOB7zrVmNJFFpJC87LUP2n6HIUA8BhkROlfSB03SEBGvq+TNvQy99mvQ1
C+aK8TOMt51Q0tlyb3UgRh07Fy3LIs0Jbs49tSPueBQfXqsT0UJzP3ZFSHk2
q+Dqgvc7Dp3XSGQj48CKMrPH8VrgHz5IhAMlFMJFI5fe/UzSw5/hQISEQlFd
7KToW79Im+Qap7oNtOmzlLppMcZhh5OJpGT1Y0ok0gBf//TiOi6dq5jXH2s8
0JgV2AhNszFpKY3ZWF4mrKjnYkzgu2PrczXdOyjJj2HaBBlSLKCai5P0ylTH
CHHLj4YJ3yIG6IHF9XLG7AfZhQJK4NsbkGSPXEisZ3HwurXLXD/LLKvM0PQi
bmwB+VPbl3y7EF52RYltcj0oTsvpd43Ni7M3DkPx2pRY63QMcm8kK8g1+miF
OcxA2RKMbucA9y7cmZeFuSglK2gkVZeOFba2ZQL3GfZC+Al5mfCUUaGVxSut
0sLKiQBcJEr5PJWSWmV4H6Ls9AU74cxOx87j33DFUQTlh9QOCERM5kJBTkhN
6MCpVEoYKQZTTAhKBD45cS65Xu4QY4cdBR3BzgYtQMf5VWjabGlL2obWrpO/
kDLGcqqRVRZ5txoHBTz0FodXdik4lFNTy+Yb2HByYsFwXeJv7x8ES5R0n/WP
TQFUS+F4arBuLy/VPdofZXWY6g6z1RR5Q7UPorwtoqxyqPHGIyJkkRm+BT+5
y8/3aJJ0KilFl4eJUbktFCzy9RtMZkc5C0E2aDQ9hGcUIV69dIpvgbrYgIUZ
pIS6IxH7qIXpMSGWo8HSBdUG5YiuvuG3kJJ9gL5amPdnl7cCrVEEhHDppeRK
jJFlwRndJX2QM2zrK/eN8KJV5CT+qhkIFRAYiP1bZQVpF7MWUFrlWooi5hZz
ysmG3WLSqeXkQi+GtcJMfjNRmTiuqlqS+U2mQp6E5lYq1bmMHJIxh07s2BlU
EA1BHF2aXAXR9+uV4ra7rl1eVc7vJcKin71LNh0UjijUjGGSmBC9N3uaKC2v
ztZVOdvWTTTI+mpy901zEX5Us3PltdSD6A3aT3/p5FIbdDYLtj1JcBmVZOTS
Jg7HQ/4J68+EufGBhuthDjipOKA2XlwCOjlSL3Ta4i9EPMWBJXEUt6oqzIXV
N+ByB5zV75IKXzxmCvhlvdGcUNqUU5/ZqacjyiosQRSVMaWpPAeWR4ppLBVu
ywzDK+AaFSjGPcO+1s0YgwEpCq9wS6k4OofLWcxVmaTllspv7A+hFjwjHdtv
buO5ZrcD9hDTkpxdGO2Te9Y8KrrMoiJLHV1cXVdFIEugJmOZLTkz7nyMyYtW
SC3T4/Isj17r1FgsAl3sz8nMpt7z4Ged+6+wlsUgFwso7iIJdDqj9r5FSrxK
Sg3kc+WhuubMdB4LYBjvmY2IEi8tOU92YTkAiEPZXyup1YxyyyX3mFwqU3wg
y34tfqJ7n5zadIKC6zkaUBaHFLmix5+5cn7RuKn7Vi66n5xVm6b49SL77t4D
h0PQ2fUm5X1HZkuwefCoEv4UZxuX9D93hh3BM2GSGiJK/+TiLyZnGpmPGOhh
eNy8pBHtpKafrbEKsfdjzKX2YSJOkEZGJWAFOD6T0iFOdRa5BQSu+9h6G2zO
I6o7l1TQB8qhLh1TznlFOlECWwZc9JRrdb+JrELXrBy0eHeuyoqz/ZFVedpC
ErZ6qiV0+3IxEqnSjzbC+lp7rs5xHplbMNuZVgO0VAFptExMgyaUJxJNDDeO
EwF+PcEyXjgHmyQCo8BvKqCVQu85T/yu2B+3pz0nmsOqv1K/sZ9s3IrXxsqc
ST0z1h7OTk4jxfCL7Ds2fDxNuMpzffxlFOsku+Eesfk0EflLU2H+cMI4m+/e
diiQ4ogu4EGRzz+qZsSwoISVoFWW7Z9yUi8wg2v2RHd+mQWp/Sfyqj5HjvRU
384uFi0V11ls9vvL+24jrPdlJ4v16ooiEoBu92jtscp34++LYk7vi/Ozbm5g
GYUWMElIK1lCzuxq5Xs7pHYLHzbzMeFCUUZkCY0VbeOFI5acgKIzReaZyIpu
ATK7fERx5mXx5WVlebJ0eYgRBU5ewvVPadfa7Ffzry9HihdNOUDJPBIL40XO
wT3qKKiWH11uUqpNrU30+eZc5QcmrRkL/6qBdSzpsx5Hz9JcOHaE50CtMfMj
vwjs5o8rSVcn/KDfOXkiqG2zv1mgBBvt8ObDfRPkBWlLnQJ21pjuMUphuKpc
G+AFLTFdAKO8hRO9SF4RGYgeoYR2L5heLjl21d0fAXhQg0icWJyMWZARCt0T
2BbZpVkXuUcykchJuS+DHU0rejd+WQmxPCbi/vpSTU9cfinTskSyczC8NxXV
2aoD2S05QVPHX3XlweB3QhSc5OC0HiUxCXNLrgmsq82IRBgO7cdSrbmTKe6T
K4kL3WreCPo65d2XgZg7ec7o6yhjmDag0k7ZzdxN3UUuGY1VBTcddYBY+ZFr
dGDdNUnR5G7DUqzexVtYSLaiTu+tDGdwSUaaZ2crAt+ipYQPboi1l6PJTNQd
3hAvzo0bRcP3ZcVHelJX4abcxU5mjTggRExmF3GpmVzdScF0UXpoQAgBddYw
SK8o+DhNbHU8is4WuGdcAaZCNTfRzpusPqGhp+uQYcgzjnwTmwpjhxoOtGyq
bKLkGNioRAosLl9rxn4kA/+6UwUZh6AR3+TbYD2ph6e0MFrXDooUy5ZqxpLV
VhgcllrFEbZqoBtV23sV0fXajUWUYslWJmzOud5K9eXCF3LK5LYSBiAFXkNS
1NUZrFy85SLjynRsJN4yz92pNZdTCWDmcJCnJOwvlxz5lMsnXja9qfRoi/Yh
GFQ1R9wkjtVhfEcqvPq4UMQUmmVoJuHrZDfrtSQZ26P7O8GPfq4EuGzEMfi/
gY3QrZR8AtK7/S4uzeWclj9i3z4qDxL2qFGkNCLX+sqzkDrzPHFX4uoypy8r
NyC53zAhHi2L5EMrqx1xS4QslWTeVvaPKtv48DT9gbWFWafW6LQnbeiHvyw4
gwbBofgGXp1D7n2ZLr2DkmrEfU56GWN6Z4lN1712LWP133bgzMYvolsioCeJ
ayBkT+a/Zo3uP6QYPE+UwjNTfHlPCCA0ybLtleVjPynfL8QWIuz5tt7fqv41
wfRIHKpFMDP2BccvEQUCjherr4qVWGZGxypiQdkA0iEYDHXFIA3yKzb3pFrA
+MZIqogfr+b417t3/ItVMhaDNG+1Vn+MobBWflqyW0yxMjjTM3YZEqsh56XU
o2b51fGs4JQ3xqVwnmogObTXoHCl5n7Lc/GqwCIA8ys2jAOlv+TY6G8xV7sc
ysuRitQj3g1f/DpmZSL6le7Z1/gd5xYwKD+aNtBx6M3wWPWkodwfeaz+6JL5
o1oUXHB/EfNiaQYFkFPNpSPZYCIqyaUz8TkCilbfBe4aDMAiVnqfdobzwvmy
Baui5xEk5/1JFHa9ZWvmT/dkLsLiPTg7zYsDrx8VRivp8RpYbcF3tmqTx6rD
i+Aqs0WAoKV/ufXR3b2Sa4a2Xt2TDO6bLJTsRy8OK4QMGPJnU2zz075XmDlq
GG7pJe5GGMVLuaiToQmjt7qAybcYHs5h0hdYw9uw9O1llvFHlBGI/sKUqBzD
dPHcpSK/xsQ4mPSiFXPuREBUP6xx8EUMj/rUNi6+w4VD3k+4m6LpLrN/m88/
q41PGAeGuWU/FJ3aa7Gj7BMit/7R47ivjX/TITKYPhnhP2YcjxfZt6cSpJvu
riYs8NNfPpexn89o4wIk2Hi7/bI28Afpe549yRfZa7hg4GKez3/3T5/L6hKP
J2zfk5Ubh/787p81jnvaQPL/FdqSWFMcHdg/Yxz6/68XIChjzh+4SnxCAG7D
oiUx7WVTshGLQyVF+I5sDsRxfQbDIt+9i+9YXQZXZTkKg2QnjVEQKzwYzPGp
ql+QM2KYjKdEs1Mmv2+ICvDoBh/g0mrp5X4RFVGyMRWn5IMSSIdU0pXhcnya
A1ZvYqiUGdqjVfMllxF3RSK4do7DQhPD9/mIoEsQ7joy72ePexEYkiFTyrr0
VmQR33vSf+90NKtwmKhk9iS/FNOk/5jT10lmnbgS/fZRQNKi9PekKmJBmQvZ
dRg1EAXNBXmQYouG5xMHPCtRTCr6Thh65VLJXLI5pa3GgoPa0GDA4vGxbG3L
YImvaOspWGNVpPGyZE4eKT+qm/KrmcBxOEropp5abvIPqjU49TkmOxYPT940
oNlHvDlNmuwe4uZhIw5i6kECvHSD+rWzvE9ayyzeSIz1agPTmU+FAFFlzfLm
hmCxqVkSY3FSk4w4JFW89TIZtZRGq+oBG6QS4w0C2RJFUlqMpJs2cUtg2mA7
rt6wQFaUkWDOxOTYRxVx5cz2jYRX41Z/yYB0DV5igGa/0G6YqOuZBP+RQD0B
/cQpEJhxjJhbMy4bKHbJKbtlZNkWzUJcaJxATms4KglCrJcF6Ho3rKszBigL
gsVnVLHkECZXIbraLH2igmbJ2iChyeLwG0XJGgYPNzavNomuw35cVZ1iNidZ
ozTBne/bJf8LirA3Ze1LyxrJCa5iZn2u+5ykIE/J2qlHsMRWwzOgGSeGppVa
0YlLX3G2+fkRrQXFxnhJhsWwLFzFYLAhIYZYJpT8ZATEXknqzmiwdgUZrXJc
0BnotcgYNY8MBdJZ9dJqqo0aHRnMjMjDG9SPhJFnutzwWDyZYjviyFQ4cuUB
FqMh15RxpGEG+1hRbxCtFBe3V5Ew5i4dXQBLe09DmdlxOock+eNAV4wPCuRP
s3n2kiFSHas/arFAlxIwu6ZY03dfJGiK+w0OZAu3klCuwpxhrvC7wFVYqV5H
tWFfwMbV6/pYGYF37zC3LUpsJzhjmJK7lTlGyHRkpXrnWUFEupmCOXO5ziZQ
D8XIMwjskSIPKCm4BYbeA8ebGbgON5/O+U3R9WrR81H0yZBZ5GM1Ppfs39my
HxMUkpSRDna63hWwmbnm0kAHqc/Qy+XaYcWej+VOtESPMT20hRf3hD5afjso
bDWhOoCaM8CJylw4i7Op0yeaNLeG27as8PLApOJxgSP6gyvWSRWNwGlA6GCP
YJdpOx14nUnCMgxKGusITKbnY25Lx3wpmlZhJ9DZKy06iN2EV8vr12muFYei
gauwnfuzIIZ5RtIwKIl8apacbvDzLMf6w8zM/svYA3+qhVlL/v/7HsA/r2Rl
4UzT196qFK4YyJ820H+DU9C17gmS/MLQ5AFfTf5Ff6cfhGWaUlR+HiMwiC64
TEgtciv+QXJwIle/HeQTsR3+Q9oR9mifSAPPMPAJZ+mGYQ2ooUFhR+f4BIYx
jG5Cmv5v5EcKypm6SvQoiuprM9YhI0bV9M+1cotpQIIl7Leg1Y6ua0rvA1oR
SkISMjfViIN+VhQVp0ZROiiBuSVrk6WrQpvgufOGs04m6y1VmEVgypN7qTEl
yQvLwbPci37+WQ3mGEGjX0Lv48g8toQackyj6EZQhlm4D2EYkFVw3gJ7SQSI
uQsHwHYGTypU3meSv3DXew9zD5MBKQpjCCnoI/ROgy5rXE1T/WR2g5WFrv3S
RjAkDeWYl4wkT+4NYuWndjIVsDTMeqfU6bLUu1zkk0NttGPvpmeOnv2IeShm
vD42EoK7NpXH1+BI2fscOPjE2eZVO0pmMshTjzZwWNyYu8EKpJi3MSoIC83U
b2VPU9wjASVp027gLJhy/XI0s37chmTYyW0Oz2JuYoOB6tWOG6nbZHW/PNJV
a3KWVRDE61yEtHlZzbv8AHeRVPhEUU5wWsHMWbhoRJiy8LbZqxohq8IbuXKS
0nh0AiqkQZfeNEwJC9WSuiQRnrjUcs7ywN+wFLgvaR3cIVKbGrNDOWyC38e+
gNpIelLRCZFqJOxiqYcqEPtRhNQ63xSHnu9L6R92+F76n86CjbwqIXyfSP9e
woc+L8yPTFyHV26E2d3ClrtVSSvDD9f2ckC2YQSum6+RbdMsvESpXOXZMtM4
dVXkI+yDMJWs3go1hglqzMaoEWs55ciwjChlH6aiWz6+OXZGRmwKlloCmBTZ
ZzT23VfxodBaLCRQsITbxqheOd/CSLkocu/Q8v1N69VZ822vfR6gHu9SbHOu
18891UXhFvCLLwYuw/RyEN1tYifSDGfjDExsja1P7eC7VFxWijMGSkqWi69U
XAtVxtRr5XWMHedCQLqKTYFmI3iP3GduIc5LACTEkqpCI7DcU+suKedkLyNa
DoMoiX8QHARY0INk8loX8nr5gAePzw/WmkNLmVRinB9DQWa9x3tDbNWeoMxh
NLRCE8pp8L7mkEnGyk0SxpASVhEyUKEl5YFzYAksilrjFwIRu6KjnWTFqhwl
hpCqV8SX0k6JGBh8Meo1J91tqnKTInGxKCgFGxD5jBn4EjMDcQLJQ7HZ+KQD
ZtPb1OvTgY0E3xbbuikS4eimrFzd8dLnKBP0coyFzDUVkVxBvlQZMvwyYpA1
EyDo+0QSTX4n0l4g7ZZAyO3nFknCFWYsmrkterWS+pl17uMIE6zgg+PCaev2
4sc4QHYR58tVp9JCSa1gejzftpyJFi/t5XQHynA8Gu+iQPYOwhJtVSdRWcGO
mGIW/3+W8iksZTJ8aur6nqYyOGdjVAaC6EeoDA8oG+Nbtv589Kr5yO0iR1dR
Iu6SYSGJbmHmQvGgb0dTpzmLvtvrpOQGA1rzfncxDRWea6bl9MxjyFZydpzg
ouCediZ5g7pciwZS8hX0iuAyzSisHI0B2/pUSWqTFQHQ+GvBBW9P+y3MunWb
f6QU8CAdlxQAyBv7Gs6IuATGTL0y1as/vsAcmC7l0XYummdy9Bc9QuHUTklC
I7LtM8iqb8HGBfMwNYNZ6Tb0HgiT2KuZGANekpozAKOlaDiXuVbzcvGMRUma
cU1Ncvkdig2VNX22TG20eDZp33nXmxo2KLkAGM65tSyiFacUCdT0QDKiUoaS
giwynx1oXJi3lbaMwKV/Lu4CcrO6KfVgwNOb01pkeOwH1S9qp1jXDJRkA2sM
HAoa5EMtcfKnG8ZD9SadDdQIgsVxEIBmoKHZt4ZaZeMRs1NNs+iDqkji9ll4
8lUtFSyr4k7PnIwNhv6n8k1xV7ZUIfjOsjaG4TRnohwJJ2frP636xuGovKk+
yJWsQVFuPiwmYd0h/VRdZEKb6oWPN1ngCEhNixG1K+JI/cXhfF7esROkppjC
PlxdOpsjiTBAD1pd9rYuJVxOM04DnVYgivEI8HJZ5YLHR7APUYmQzIakFPzQ
Uh3K+W0CfTyZZzI+K7moxQPwWnT+EF6O+zjR35PICROO1vAxR2s27WgNiR/D
9e84ujAXcbVysuyX5gBh3dV7ap1N03m0nCMrdctJeoNnvXwbZZtES6v+TwxW
E5Ec8zODZS7EaTJt+/TzLrBVDMGfwZXTWTIQ1wWe2OgKtWpQQG0/teypi4FT
MgTWL0BaZtStJEHhe4/0B7ZJN8A7zE9MSyvoVbxcLIt2jDjHSNwQfbVqaiVH
pfeXvvuCvb2qyAqP1/TRUk9sAgpsCQo80F6Ldotovav5ZGvpxixJZpaGFIQY
UiC2Y8mExNvkMQpyflEY1WT3rQT6Bin/54O36ma/4VqfhDEad+Q7fIqp9R8v
iRl60HzsT+busvRU2evnfxwgV8J4Dvie0xavFjEKGsqN7pAtpYpBfjQBG4EZ
/8cJg2Q4IImBOgnERQXEcdtPyIdRwzVyFlygqVhcDak3krCF9WW0Og0EonAx
xRB9BI9DvHsmC3pf7y0icM5BUt8dQEMmI+KWszdQyrQWZLbVVCZQstT5NMwi
MLl6aLBFmAHC0l2O5YilDLxEEX6ILyy+kPN+Iq1zQGiy3umo2XODOVSjhBdr
1n/aAoba10Kdxp2NSRn3JJpGTCXlw+OL6lW9TxVrqZrZP1K9anxJTKoHgYRh
PdYE4ZVeCyIM8OWFHmw6Nwm0LElqOHFyJNWD5Apm6KKWzcsrKjZL5TwjR0/d
+5P4C9IAgytAS7Pj2yKmNxbOgeotjZIuGqv2Jr/EkhKWRfO035CEJAUJPUsi
YwkcyrpK3l0rzkmrOSaFT4KP5dJ8vSY7SxCP8+WTklt3DfwDMsd813VHDEgi
+a0NI4S7YcHvhMWRpXQFqoZod5dct3bAFAIR3aJi/5bW6LY0JsXVeOG5Cxv4
ZVY0De67NORcCl4tbQm5ReUFc7X6k00CPmoJ3MCZwKgxFluaIoJHQJpIHI6R
JnhIKEFq+Nt1DCwuOZ64csHJIO06fFF6b6cJzwg1hrZzPuYY5ArMq1x3ao3g
S35OcaGI8Mi6YYowwqJYTYaEXaslx9XqlXotB0kuvy0w7A2LvzatpMpMI6/7
N39ZBRpNtpRE4fSH+fpaTBSACVo4UqfujsCHulkUiWh0vYSTpcLHlNIEUyM+
M3zlEeWeHntvwFZVkNEJ3IM/wZ+XOAGK71jyB98KpiHcC9FXRET6H78yKHnk
62ml5ZskDuC9tXflv5Yqf70XGcYhf/SWpF8ga9DTvWO7HXuj397Yz2f08e+T
84/7LB+kBQ37b/xDZ/4+XYBPmHn62Wf08e/JG/whzvri9WW/3X/izHUBPn3m
n9/4v8cpXz+7QvbzP3968ezeKfvS3f/vzvz+iBz6ecXnPP4XEU0Jo1Zok+dK
xGa0IBnbIPnhmQfqCSMm/g43cQoFoUTryBWdOd7x2BhzIV1KfIYLmUDvhIsO
6OojZ7hVwYC6z3qaIPHQ5SBLMOUqLzjLDwPhybpK77RyL7SU6S0VH+0qalpF
a5uDGkTnXb3hGi8uPnkmjjGpVQ+Pr09No6mg1ZRKmF9JUsD1UDQVle9/efUC
cb0kILIY4jC70HBxJL2bHmOLj8cdRQHIy71PA0YMWskKLIiO6YQtLFUrVlBO
Yh8nIsHUschZQ9n57tGTLs3tnhSbmaq6lcUcrzHzAXaR74GQNuckJ7e7TGHh
nixgBM0/d06YPbWuUCEazo4I6dMm+NHZURncVKzZ3qMroe276tXiiB8Qc5L6
56rosdvCERMs6K8W2RVnergGaVuMgLiuKteiB5uA4SZnir1jJkFwlqoZexyC
3rec3XTNif6hx18bUXLF22foQcQedwhCkp2yBEI5eQCbywRBchWlDYoxR3lf
gsnzdXTXqGdNDLczU0WdOYWtANgSCvuaucH5lqWKQwhf20p9h7L6gPbSASYK
Ee6+Wk5R9Tp1K3QNGRdyOoSqIt8TqO0AAylbrntIvkRmARSy7h03OFtkVgr7
zrX/3hmjl7T8AVf8SRJkYzvOd4alt2phJDL3Z1xSZXz2ORv8cUptQThrwg+S
AC+H1gXPRCf5k08mQgJMOAu/6+peehRqSAjxe3LCMbgnIsNlSeGywKXG/FPF
R3XSEY7+3Gey8IrlSBqqA+khDiuS5d0Qw6HecI3HCmaP8Il4LBDQZwrNo1Y7
3xRomyfT7TKao4P7XaMENAOM5lmNhRQKznlxgdGI9B4eUKse+kBN2w9mholD
e6yEdXHOyC0m/iixABy5clj2sHaz/8WQgUbSN8d43NMWSK6kTLtNTfe6nDpu
jmFPzQlWKUZYaGN8cDQBmi9KddMUMihxAHBiHW+vp+64cBUz873/WjAS5MBW
C3pBGYW0c3J1Aw9uNm6ar4o92aKusMzhZbAgVnSJPvC9w9qCZt2mK8q5tq0m
V29dRULQ/jmJyZvC8HCW26zk6ihZdvG6+EWxFJeuckLeNxa4WcybGrRwCQlB
QOYBkfxSyUASh+c9OqwtDZUcCMroF6lOgNuRdwZ6IF1Y5U5DoADaxHzRWUpe
2JV0WWCNyVO575hhxadCWulM3PkU7Iy4GMakenQSJlJkoZe2hisKSIahb2jd
goXHUZ52R9A8dDrqVKsBx6/nK+uFzQiRzMgguCm2ZUWcXGqWakTl8A09O1Yq
zdfQYnhWzOu48ElPmb22xdjMNMe9RnASRpMqtvA55AEaMedscW2RPcHKtcgu
CEpMSSapeWc0GapQXAZaAG49ZSrrq11JKXF+82GqkMGb3+kys27IQSz4a/wi
bZQb4j7F+pJWt/7d++xCKbNX9xq+0pOqJa3h4UjnvdLg8IeQdmb10eXHPfd+
ampTi+JvgcHU7lVbR/RSoq2ojA4YQaKQ+p7R5g9Kqe1PWFrA8F1TdpK/iORZ
jQqRAH5XrJDcj55Bk/uGU6wVlVElOt1Dvm7qtnXgQ397WCq3pErhTDtpDaAY
LxTXb1A1tuWIbkqH7M8XaQPr/QlroSlGNL+p0NG5tmSGfD7wRAjpzUKu+iEX
DCo65KV1k0xMXtR0FWyU9y5w8SUY5V2MamaEv95jTJtTWJYvL4nba/5DN05L
Fubw8vU2MEQnokiSEmxcBc286nDUrapM6QOom2Jd31S0a1Lag+/i9I53GFCV
YvAhv1Q4jrbPD3V5Fz68eARj6LYob4e7NMaUzZ9k0Fit8pXui4qr6c70l5oq
otwiYgaujCJve7UuhdULX9fKcDzARRZD2fglchkilCHBZexvQErodsLVWYXZ
lv2CjHFNSJH6JrQflyFwan2RWtuZEDEyX4cE1IzTYcW1b9feVyG3pUuD6miL
0lhjfa28RAUg2C3ay4cvJi0G0lGVkXn2MwEaNT7mAAtO+NY8hVh3BAijfpJk
axSYQDYz4SWPkG9845rewYGltOKc8kRyjLt8Cex71sh79h67zaIeomVMmkat
Q8rQI0C8xqrKSWYyIxGtq5b3Zd6yjnalGIGU0pfrDePO95wn3urg5Nstcj1G
W/bHLAHRcNNvQdJqhI0f6o1j6hyAhJF5O0xMS3J3vn6T9Our22w5KzKaSrjX
3lVAPbuXhUMQDiIz2DkSH6p4XEgCJ8OBb+TKK9pvyO5nbTTFrcb8cpQ/vXs2
7sP56gejsNQhiOfyyomzvsoO+WLVlmPbYluifMxXi0Ct9XrUmoxS+7Md60AQ
/+alcrD/4UW7OnVDHsB3UjvZg7vtXIisXxOH5/p+yAUsBqGXp0MOdb7X5Sat
nZSMz40VX/Str/7CIkdyX0R2g3maMUGIEPqCsxSQtPciNvM0kXV8+3TfCu/i
6Ne95To4JykhzZOL8tFPHCirBi3JjaDUGEurSujvWPH2qBHF0H9LVhTLq5Jg
u2y9Ts71DleIfzkaTEib5gdJcoiorViPBU4AATG03ElXUw8DsE8ajFe40cYS
35qZUqLiSARwxgLM4a4LSZ2Y65ddxXXDiUhTsNVMypSKOTbPni+X2QvEp2LC
BNJlPFb8xfNYK4E68YRKZjV4f2BRIirc5DkQX7ZUQ4gkEKMy3OS8EZvM7o7H
e/EHvTHIhXOJG0Zduju630eRY7AA8wW9yngjy9t83Yshb4obSoNwM0FX1Bnh
DLD+XnS1Y74KLjec5C3zkcbCNYEdTp6Qa9+SpNmxPGCSHTzhGxL4Y4lBNnw0
JPE7MZxWC8H2p+KPINdQ4aWdWcnVWXovazvxwtXanZJUWMOjVRHEqSyyQbB0
v2MHGsE3jdd41g/cMD+sypuTHgSKHNZOPHh2qry6+Ks0YqsvQeUNRS0kA/XS
zEyPLS2JqD5u9Ave3u+h7V2F7V+h4QyNuXQLiNSvW7K1xxJGqNspV8XM5Y2u
0IPBR7gheyjQwOHI9kwVWWlsnssubyR+4t27V98/+5ff/PY3IGfCZbcnE4kT
nQ+SAQtdJ42H0KPRZ4PhcmfEEpu/0EcyozJgI8BqPoW3bZIsQfZbDuLYFhxQ
ranwuLBD3kqLIBnRkMkyLqXJb+s925MxMxRuNIYaUOFJyghPvCd9O1WvwiYG
yMPiY3yOkLDe4FKvRJL8OtidqbH8ckn5ELIGXSMqcEludnYTib8KjkTgKALG
1bagXnfHXV2JZ5Rspbzg+hjJ9OjnrQJGUxQNAbdf1NdREWciT0H0LmXOxE55
hUY8cebSomIgQEPPeqsn6DbymjUV9ygJPGIiZ1+XOn4aYn9xVRE3/bYTrnY1
842k6pYFu/cj8adKTSbhelOVsYIHMOUf71wF/oiqZ87AckGIDYgsO5IUSFZr
4pi0usSCIQs+MaSKQmS1lnZGbSwZrMOuqvf1TYmiY8wafWotlSc/g4KSVKwn
A7oAKjWcJYw2eiYLhNg0FuShPUhlsn19Zi4gkgeOn4RWzHHONXC86KXs0kNG
va3IjdHvlEvLTWKLa4b4ngZxpMC9lmB+4vjh+CqSFVjCTWLIfOCKDNUJYbNh
1sRZvPB5cJyBziVKH4KgsdhEmqhNxiaZ2tBo7iq+3p72eN3jbfoKcbujnlVX
rQKuiwtMlUH1wjmZyOp8CcPZc9H0ZUuXyEzjZ0ZDRdgCLTaosBlUwaNraNzR
yzhe0lzPDGk54tqGtGJtT3OKL0sSf+AQmxOoms/r16rmhmE4KBoGgHWV8MG8
KVht8ZkDYqzwSM4J5Rt4hYv2betufYrzyHUkmW/UkQjbVt+cCl3fJOvfUr7z
mE9B0iMvx9rPJ1rOXhIaGT1B8vf5qSLgaFwJFGo0m0eOWSjrTRBOGs1Qmu+I
GmHgfrYBdZnV+D1bNE32a824MUgiSglq7JqJCVDQCJszsnjYLbkHKSQ6vkYY
nmEOOAosTsIeYQgod3TlDUa+OArg2PaYzAV4LCs98QoILfR6KJyc1O1QtKr3
hKJoiiPLhZYOCl37ZkSjCheUCE+QuZb7U+wT47lLNWHkhdTd2eMmkRvv7HJV
5nuqXIZH4NJfCWmRCEJ5WFF69J2y1rbW0khDzAg66LMLg9VrNPKhyNUQmBIw
goIoCpTKPeUaUsb4bK5HpQG4EunHJtsTQhg0GcLGyn+I3ZRUanpNbS4okFPi
YMfNEJeAXB9NjBbui8Uej6c9yioUl70r5odys9kD02DChacpcJhhYFPZb7Of
9rB6XNiW9h+GyoGbWkpljYVBxIAeEzVA6xxEn/hcK62zkXTo8wn6G8uMqA3s
GBAnJydrO9VOhAeViGCRRF7pRC7qzmLfUPzecAX3oISMVw8etUvDdsHs5vV2
HufG0QpMuU3xN+L9aYJQmBRBCvtkLByLR4iVW6JVSoqPrEkgdfmLOaIVpIyk
6L3Y4Tq+8ZNiFi6gyxBx3OXH404W4WcqEZsPbgv0Am/xmmPpqD3d3HCapXaQ
PeC1CIl6UIibyHWF3v9NwfkWYeRryRtMNzJt+CIWanW9ExeKpTs00ELnl0Bc
hONwTp2GL+a843uQ5xV43mRM4CQnnAfAuBJDK7p+6R6S47qYQLQHrYmV7xgV
ImfcBbYqwI/D+sX0l8Ij2NqiYpyDHvq0Ja0TQ+6K3DLHUutBq8iqnnmo4Wrh
rApW2/Zs1O1Ri5w7PG89m6wlawoyANEk72d4UvQPgbvwNaddG+l3FGMYOCPu
EuPYqdoiNen8IFYsKzroNFJY7iY7Y7hN4+FRHI9CCspVvNDCi06NXibBsFam
aqmZM6kfkiU4rI/sj6D/JF688mPN4aFMwcTOWJooWywY2j1uGhld/r0IYrnC
xY7QDwIh/7GvOABjrLXGHlW7x0MgzhkdZS76BYbYh3ukOyDSZKB+JzTZCKxR
gjiVlAPV2E5KASA0feJ5AKWBclRRlT6aXqQ9vue4E8odbi/M6GpXZCuvDlVh
ank04dqZI4xFRvbYxrwRMb3KUMoNfIlZqXfmwPdtlPdY8YKFfINUxDq1Y9YH
KS5LB5isKCC+cVg7s0/By9NZhXUPI0Ske2K5pGNXID8PBH4Jq/4g2RlHouc4
OvQ8cjh9mCmJDaWhbImirK0/Ec7elElt+pJrNmdRA7NOUSPlvEGUPEWoW+Tp
F1sChNdaBS99VVInpDr6qHHjI5sFqyybzdQeo/0XKZj6njbI0GJB9OI98G7h
Eyhn5d/ToPu+xSXWfs3H/TuL7PUIlrTn+N4R1s1cJKEVm5/JbWoSIMKz5IrA
xPBNx7FSag/Ts2f2+6x3b7z7oq9kKkeOlZRVD5YgdXNQSV1OeXmRhZ8LcWCL
3a3FkyQboxgM4pICZxafCpbcbuCEqLS7x8QForYEshPGMWu8BYONlXUdarg6
s+dOlyIYpnsxvIrCY7R7kfBZmd556pzMhOZmKfmndP0lxt6zHMU2A8x1QJ6x
ut+faiFOZBBVN1H5HcsWn8n1rui3E9Lz17cqRGMFY43woOdSv0bmQs5sc2IE
KyKBGvMMtUZgZbOoOn88IFkQ3SYc34n86rR46ZoDi28l/FPJSL5kpAMihvDm
SwoVJsG1PoaU7AqUQWIhTnVKIAnDJtojhfku79a7TQ0bw+oy4htXJC2wZNNx
XfCNqeE48KDUGTV3IglSKagTUO2+lLwWWnjZUluwWZR6F6TuukCuUQtb7NMG
QT3bN72QWTWDDhX5fjJnM/10teG/4T60yJCxjPlIpD2xHdMYVqOCvNWUhsOz
Og+oDl585ZLtqEKW+Ud5pFJ4Oaj7BRu/iyvJi0Nb6swvaRprKTts7wdXZI/t
N8zgrqNYs8ad6JuVirc7GAqnEioYMuMy9VGY/2DlyaovNSRmaYtoe9F8O230
CeORTXmj5ATqHQ+Y//FYuKrDNqZopQqJARdvWVw4NlyQFEcmwQFxRSOS6WUV
kHpMIr09wb5RhReQcz81uYcCxKoCj23eANG/6GK+BF46ygqJeKI9KDBssPhY
hgkZI1oUPYUPQv76QjClvbF8VqCDrcm6IMhByUS0Rucfn9exve3MM9fPNe1E
bFEnGGN14lCVvSIlP5a+Ti7epbt78fR89/ZYNlwPdplU/0hT+c3j3lK6HUqB
BW9oIcok+RnvO2YMS4hvmAeTn0SdtWw0KWaSJdCZa3LrM2lAd53bQN6zSric
aD2skqf7pmdWVhalFa7lmfRwzLsd1pTSXHeqDCZGVhGHk+xoyZJQUk/mPb1U
cOioKAqzm/wGt4L8xl8/+devREzbcJpUuGmQfiKvceV0zMdtKTK3aR7OEEFj
bA7xE8Cr6CTvmtRM1xkllKCMYhTsI4FvmMyVgB+Www9Jn1LrwclBFlibx580
LyxJwLnWEKYzWGBNYmtqRKAAB0nTTlwY15ytIJQLUu17th2coy5wUNigfW9v
Vlv7SGxYUpyZ9RVHjWXfejaaMzl4YFXMz4n2Wr8oJU1C0BRjCX1jReJssBgi
+v743cs2ohUmcpQGSVVC8WGcQy91BCTGyzw92r0Mmv9fO9qaO/ATj3Y6m/Gj
3XvmP3u0ewf2c44pynLbYV5RJmjX5hZ5g2m94vvqCUM5JxZqT6u/iRdBDg6W
4mF/Qhgnz19wVFPq9AdVtJ9feFDRRP1pJ3SiHsPU0RzopBjZFZ5bwrpPIjL0
kxMGeJDbvCcakTsYtX4SGiyHDYtxLVdd2eQHCdElg1bCZlk5VNe3eY1kT2XU
P95hJkaqjRmRTi5TQMI8Ja+/2iL2aFWWfLUrDO7EVJtjszDrvEr7hFSQCvZj
PtU4gFlIwI6wwZielrTpo+n27Od3QjIGfTa3Ku2Ik53nEszIaCHwyKbiu4oH
1lj4WgPw9rHUKklieOv1ZgUHRNLWt+yBi742AWfwqrLtSsA3Ck2h0ZUiCO/y
8SpibSx7cE8RBrXBE/SfuB+ilpAST5ppsV1IkmPzwfld05h0kGpzFir7fBuN
UxK0oEgkl/SJDpZew3zPm/JK1lym4tnAhpqQpSivVDZur4kqMJOxsWIUUPwq
W7CiojsxhlNSpFM5hJkKSgo2iGo1e/B7tMth5ksqv4yBxc/+5KO3KW879Ycv
i89pTB0pNJHlEQ0jnQwvasLCYhaUSoL8wGxNzTl1x76+4RTnFJOay77pQJ/y
FpN9qiUTURB35Eph/81mVFOiFGSMkLPILdPTKfxszrKecdBkYsGi2hNz/qT+
lMYLSPxCfzYLzP6AayB1U5ISbH0ny60UxburG7TJcBFGzCTrjmL2ir1b46bC
XGAhsbxuFII4lkZbin6iJJOg4t8ktSwlQE5YgQMu8D2PM47XrwVmg/R8FFOC
4leETjGn4VmVdRaSJOhGMhtG7tXzylyQBG/pHuQ1YYHAKHxjXNf1egkn15mz
YjpO8wGZ/2PZXi6mXWIh3S0uRDbGKTV4HPMrcqjLlEVB4gYS0xJnhUXjspw/
PAvmP2VXfZofXqqrgsZvSBrYJQPzoyFaqN5Oept4ZMWMoAYRCeNeklfU1cl2
YV6RSM9suG0zrHTbBM7GznfO6nRzwygtL7wmKbcTPUaMJEXfhSsTWgmq6Bzx
8iA1UN5A8rvKYxeEtnc81IznTcKNs/gmXmUTp0Eyj6InN6YBwbJDLyIxWFg5
pyZCwDAb4tEfUEUPSs8yV8eskarMpNk+7ojO6zU0Gxiq+bYjCE+m7d7i3lL3
nHUasTF0ic54dhQf1S/JGvoFPNg+TehMI5AkKIOMa8WtXPHhoyAhhXq8URF2
DHeE0UecFwQRmjxIQQbJAbKA2bGYOY74Yok5WC0IEbpxQw00k2LhCXbiudmd
+O4pjnrYE2oZmr2Y4A8eh8AzAyZVbeq7TIDfUq4h7WXAHjXiHzYeZ4IWwbOm
NGL2w+A4ytvsarXpeRwJfx3ka9yG/jKOZoqgJEeygpSYVu2IevJ5JMRUWpeo
yTGBGcPRhkkPys63E4NLWk4P68RxHAX3o5WrQAhhyJt6jTDD1z700FHaE6vL
5HpSEGoU3WwNGEIRMIiUg0XhsiD3FbXqMou4fSXTsgy9h+QKEng88DpOZfUY
psKxRKGJGVLsk8jLXkHPd8AJqdakKpmJKo5Xq6mivF64RXMUZjYz2a5ANgec
pi//pxzIaoR4mfjUMhqIhHfK/Ukk699/jP19nZ2LvIl1RgSnwnoIDJ60Dlgq
EC+LzbDKQzFmB9EU4cSLJL8paLLFYVVsNkl2vInyKsZZeTDEkXElgg5flEF2
K1m+GlF+h4YpHOuPtICicmFi8ql6U2gDYI8eNafV6VoUByqGTii8fDtqBWMW
iIV+diXcyq7cOAdtsibAiHjGZUXiYIJglNhgRXkp4RDfILKXDo3kqCELj9SZ
agWqzTcxggmLaiN4Pod2+/Xi8eLJ4msCmnrjLWHJDEK2wOwSX2C17eKI5wfe
bgotlipnNPrvnOeO1xa98I1LNGCAp1inFuY1XvUHe2BnNR64fd26KDnFpnn5
mIEnFO/IF7KOhqHxmNZ7pKDqeO2DqRJ/Pkm8xzc2hd3MtBCMOOMw7xjmzriE
pPhqUjNUEuVgC8FaGNdiZDwG4gHVqZHQcxdv6ZBb3gyDRm+qYENDEQF3qgtx
OKvnqtyfGaDEBcDxSIlQ3RR0KLxXMh1KLpkvCfHE8ABfptMVqUf7jmTmg0Hl
GwMIOexD0qgraoiQSxSMf6woxzJFlSBwlSXXso0hJ1MzlhzraGVA90EEQraM
vhTsRHAW6pGdRWF/YNiOSS7wEco0r8c2OMyh1XmrgN9JWfVdkv18Sdz31PYF
RBaJwr6u32T5lAqs7c5cVbNOJKQUdBlR1NlPr15olZyplfuyZbw10pMbDb5j
znNZKu3BFqSKUoPVr/xIfQL47ti6VBS2A+byUh5jUBRLc85lhTF9PlDPFcf3
hgjlTTS9su1haj3rVrYttQ+MGIXZCfqPIVqbIvJNwhn6KoOOdUmgoB6F5LEZ
aSujLcyCkr+d+iSXl8pXXIOWsUVPQ/ivaGna16cNFQ+RlIirYrwPS58IElBX
o2aQfj0YAbVpoHHqZ0FdjpVg1FoWjJt2k7DHjyfYmbxV5URHoahIidMu2zcs
iOed4Y10OibNt6cWRcZSy7nwJYMb7llyskVsytTm2YrQaeUhj9/w9DNTLbus
dhyZp2j7k1QxcmZSaltYglopuU5A/oYzCTRTO4NkSpYaCjDZoFSJSgwVjKFM
vy0q3H06LSWPgayoQFIxOdtZa2wVKXn0oLCM7KRmNkUgqIj1W2MsoiZEaTQ3
g25a69F45LIQ1kwloXRyRRPHwUSQpJe7dzi6J0astBDEH0DSPp09GfLTmrXW
d0EhhNmL5Z+Xg/hB2jOt4BmNCZakRMBk0DC+Tg09Q+rGW6NuoIE5yI6bprjL
lt25qGeM6ANqKsgWAl8scvzi96V+vgCB7hJe+1N5AjkJ2OjNLFvuy1W+yrMf
KN/CxSF/i7Af6Pn3NwdQgfkVDP9eYwz1vtgwvAK6/7kQFo1waab7vHqT/blc
v4GB1m9m2Uug2jr7f2oY27dNCYT5M5qM4bq+PmNJlT+WB+q/yl6eutMs+x+n
ogHOn72GlS6qu7zYb1BEggbrfV5kV/k+35Sz7HUNZJF9n5ersgVl789Afa+B
3OHXV6BZgWgFKifas/8HHJjDOfvxy+d1Vd/sTrDNy4qE8VenanPTFJL95tsG
ZVwYRN3kliqgxDoJxWaVr9/Ays/n8wx/Df8XAcvekHw3AQA=

-->
</rfc>