<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- [CS] updated by Chris 10/10/22 -->

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.4 (Ruby 2.6.6) -->

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

  <!-- xml2rfc v2v3 conversion 3.15.0 -->
  <front>

<title abbrev="RATS Arch &amp; Terms">Remote Attestation Procedures ATtestation procedureS (RATS) Architecture</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-rats-architecture-22"/> name="RFC" value="9334"/>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="D." surname="Thaler" fullname="Dave Thaler">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>dthaler@microsoft.com</email>
      </address>
    </author>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
         <country>Canada</country>
        </postal>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="N." surname="Smith" fullname="Ned Smith">
      <organization abbrev="Intel">Intel Corporation</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>ned.smith@intel.com</email>
      </address>
    </author>
    <author initials="W." surname="Pan" fullname="Wei Pan">
      <organization>Huawei
      <organization abbrev="Huawei">Huawei Technologies</organization>
      <address>
        <email>william.panwei@huawei.com</email>
      </address>
    </author>
    <date year="2022" month="September" day="28"/>
    <area>Security</area>
    <workgroup>RATS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2023" month="January"/>

    <area>sec</area>
    <workgroup>rats</workgroup>

    <abstract>
      <t>In network protocol exchanges 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 Claims.  It provides a model that is neutral toward
     processor architectures, the content of claims, Claims, and protocols.</t>
    </abstract>
    <note>
      <name>Note to Readers</name>
      <t>Discussion of this document takes place on the
  RATS Working Group mailing list (rats@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/rats/">https://mailarchive.ietf.org/arch/browse/rats/</eref>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/ietf-rats-wg/architecture">https://github.com/ietf-rats-wg/architecture</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>The question of how one system can know that another system can be trusted has found new interest and relevance in a world where trusted computing elements are maturing in processor architectures.</t>
      <t>Systems that have been attested and verified to be in a good state
(for some value of "good") can improve overall system posture.
Conversely, systems that cannot be attested and verified to be in a
good state can be given reduced access or privileges, taken out of
service, or otherwise flagged for repair.</t>
      <t>For example:</t>
      <ul spacing="normal">
        <li>A bank backend system might refuse to transact with another system
that is not known to be in a good state.</li>
        <li>A healthcare system might refuse to transmit electronic healthcare
records to a system that is not known to be in a good state.</li>
      </ul>
      <t>In Remote Attestation Procedures ATtestation procedureS (RATS), one peer (the "Attester")
produces believable information about itself - Evidence - ("Evidence") to enable
a remote peer (the "Relying Party") to decide whether or not to consider that
Attester a trustworthy peer or not.
RATS peer.
Remote attestation procedures are facilitated by an additional vital party, the Verifier.</t> party (the "Verifier").</t>
      <t>The Verifier appraises Evidence via appraisal policies and creates
the Attestation Results to support Relying Parties in their decision
process.
This document defines a flexible architecture consisting of attestation roles
and their interactions via conceptual messages.  Additionally, this document defines a universal set of terms that can be mapped to various existing and emerging Remote Attestation Procedures. remote attestation procedures.
Common topological patterns and the sequence of data flows associated with them, such as
the "Passport Model" and the "Background-Check Model", are illustrated.
The purpose is to define useful terminology for remote attestation and enable readers to map
their solution architecture to the canonical attestation architecture provided here.
Having a common terminology that provides well-understood meanings for common themes themes,
such as roles, device composition, topological patterns, and appraisal procedures procedures, is vital for
semantic interoperability across solutions and platforms involving multiple vendors and providers.</t>
      <t>Amongst other things, this document is about trust and trustworthiness.
Trust is a choice one makes about another system.  Trustworthiness is a
quality about the other system that can be used in making one's decision to
trust it or not.  This is a subtle difference and difference; being familiar with the
difference is crucial for using this document.  Additionally, the concepts of freshness and trust relationships with
respect to RATS are elaborated on specified to enable implementers to choose appropriate solutions
to compose their Remote Attestation Procedures.</t> remote attestation procedures.</t>
    </section>
    <section anchor="referenceusecases">
      <name>Reference Use Cases</name>
      <t>This section covers a number of representative and generic use cases
      for remote attestation, independent of specific solutions.  The
      purpose is to provide motivation for various aspects of the architecture
      presented in this document.  Many other use cases exist, and exist; this document
      does not intend to have contain a complete list, list.  It only to illustrate
      illustrates a set of use cases that collectively cover all the
      functionality required in the architecture.</t>
      <t>Each use case includes a description followed by an additional summary of the
Attester and Relying Party roles derived from the use case.</t>
      <section anchor="network-endpoint-assessment">
        <name>Network Endpoint Assessment</name>
        <t>Network operators want trustworthy reports that include identity
and version information about the hardware and software on the
machines attached to their network.
Examples of reports include
purposes, such purposes (such as inventory summaries, summaries), audit
results, and anomaly
notifications, notifications (which typically including include the maintenance of log
records or trend reports. reports).
The network operator may also want a policy by which full access is only
granted to devices that meet some definition of hygiene, and so wants to get
Claims about such information and verify its validity.  Remote attestation is
desired to prevent vulnerable or compromised devices from getting access to
the network and potentially harming others.</t>
        <t>Typically, a solution starts with a specific component (sometimes referred to as a root "root of trust) trust") that often
provides a trustworthy device identity, identity and performs a series of operations that enables trustworthiness appraisals for other components.
Such components perform operations that help determine the trustworthiness of yet other components, components
by collecting, protecting protecting, or signing measurements.
Measurements that have been signed by such components are comprised of Evidence that when evaluated either supports or refutes a claim of trustworthiness. trustworthiness when evaluated.
Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc.</t> etc., and how they are hardened.</t>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>A
          <dd>A device desiring access to a network.</t> network.
          </dd>
          <dt>Relying Party:</dt>
          <dd>
            <t>Network
          <dd>Network equipment such (such as a router, switch, or access point, point) that is
responsible for admission of the device into the network.</t> network.
          </dd>
        </dl>
      </section>
      <section anchor="confidential-machine-learning-model-protection">
        <name>Confidential Machine Learning Model Protection</name>
        <t>A device manufacturer wants to protect its intellectual property.
The intellectual property's scope primarily encompasses the machine learning (ML) model that is deployed in the devices purchased by its customers.
The protection goals include preventing attackers, potentially
the customer themselves, from seeing the details of the model.</t>
        <t>This typically
        <t>Typically, this works by having some protected environment
in the device go through a remote attestation with some manufacturer service
that can assess its trustworthiness.  If remote attestation succeeds,
then the manufacturer service releases either the model, model or a key to decrypt
a model already deployed on the Attester in encrypted form, form to the requester.</t>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>A
            A device desiring to run an ML model.</t> model.
          </dd>
          <dt>Relying Party:</dt>
          <dd>
            <t>A
            A server or service holding ML models it desires to protect.</t> protect.
          </dd>
        </dl>
      </section>
      <section anchor="confidential-data-protection">
        <name>Confidential Data Protection</name>
        <t>This is a generalization of the ML model use case above, above where
the data can be any highly confidential data, such as health data
about customers, payroll data about employees, future business plans, etc.
As part of the attestation procedure, an assessment is made against a set
of policies to evaluate the state of the system that is requesting
the confidential data.  Attestation is desired to prevent leaking data via
compromised devices.</t>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>An
           An entity desiring to retrieve confidential data.</t> data.
          </dd>
          <dt>Relying Party:</dt>
          <dd>
            <t>An
            An entity that holds confidential data for release to authorized entities.</t> entities.
          </dd>
        </dl>
      </section>
      <section anchor="critical-infrastructure-control">
        <name>Critical Infrastructure Control</name>
        <t>Potentially harmful physical equipment (e.g., power grid, traffic
        control, hazardous chemical processing, etc.) is connected to a
        network in support of critical infrastructure.  The organization
        managing such infrastructure needs to ensure that only authorized code
        and users can control corresponding critical processes, and that these
        processes are protected from unauthorized manipulation or other
        threats.
When a protocol operation can affect a critical system component of the
infrastructure, devices attached to that critical component require some
assurances depending on the security context, including that: assurances that a requesting
device or application has not been compromised, compromised and the requesters and actors
act on applicable policies.  As such, remote attestation can be used to only
accept commands from requesters that are within policy.</t>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>A device or application wishing to control physical equipment.</t>
          </dd>
          <dt>Relying Party:</dt>
          <dd>
            <t>A device or application connected to potentially dangerous physical
equipment (hazardous chemical processing, traffic control, power grid,
etc.).</t>
          </dd>
        </dl>
      </section>
      <section anchor="trusted-execution-environment-provisioning">
        <name>Trusted Execution Environment Provisioning</name>
        <t>A Trusted Application Manager (TAM) server is responsible
for managing the applications running in a Trusted Execution Environment (TEE) of a client device, as described in <xref target="I-D.ietf-teep-architecture"/>.
To achieve its purpose, the TAM needs to assess the state of a TEE, TEE or of applications
in the TEE, TEE of a client device.  The TEE conducts Remote Attestation
Procedures remote attestation
procedures with the TAM, which can
then decide whether the TEE is already in compliance with the TAM's latest
policy.  If not, the TAM has to uninstall, update, or install approved
applications in the TEE to bring it back into compliance with the TAM's policy.</t>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>A device with a TEE capable of
running trusted applications that can be updated.</t>
          </dd>
          <dt>Relying Party:</dt>
          <dd>
            <t>A TAM.</t>
          </dd>
        </dl>
      </section>
      <section anchor="hardware-watchdog">
        <name>Hardware Watchdog</name>
        <t>There is a class of malware that holds a device hostage and does
not allow it to reboot to prevent updates from being applied.
This can be a significant problem, problem because it allows a fleet of devices to be held hostage for ransom.</t>
        <t>A solution to this problem is a watchdog timer implemented in a protected
environment
environment, such as a Trusted Platform Module (TPM),
as described in Section 43.3 of <xref target="TCGarch"/> section 43.3. target="TCGarch"/>.
If the watchdog does not receive regular, regular and fresh, fresh Attestation Results as
to regarding the system's health, then it forces a reboot.</t>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>The device that should be protected from being held hostage for
a long period of time.</t>
          </dd>
          <dt>Relying Party:</dt>
          <dd>
            <t>A watchdog capable of triggering a procedure that resets a device into
a known, good operational state.</t>
          </dd>
        </dl>
      </section>
      <section anchor="fido-biometric-authentication">
        <name>FIDO Biometric Authentication</name>

     <t>In the Fast IDentity Online (FIDO) protocol <xref target="WebAuthN"/>, target="WebAuthN"/>
     <xref target="CTAP"/>, the device in the user's hand authenticates the
     human user, whether by biometrics (such as fingerprints), fingerprints) or by PIN and
     password.  FIDO authentication puts a large amount of trust in the device
     compared to typical password authentication because it is the device that
     verifies the biometric, PIN PIN, and password inputs from the user, not the
     server.  For the Relying Party to know that the authentication is
     trustworthy, the Relying Party needs to know that the Authenticator part
     of the device is trustworthy.  The FIDO protocol employs remote
     attestation for this.</t>
        <t>The FIDO protocol supports several remote attestation protocols and a mechanism by which new ones can be registered and added. Remote added; thus, remote attestation defined by the RATS architecture is thus a candidate for use in the FIDO protocol.</t>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>FIDO Authenticator.</t>
          </dd>
          <dt>Relying Party:</dt>
          <dd>
            <t>Any web site, website, mobile application backend, or service that relies on authentication data based on biometric information.</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="architectural-overview">
      <name>Architectural Overview</name>
      <t><xref target="dataflow"/> depicts the data that flows between different roles, independent of protocol or use case.</t>
      <figure anchor="dataflow">
        <name>Conceptual Data Flow</name>
        <artset>
<!-- [rfced] Regarding the SVG in this document, please see the warning below
     when generating HTML output. This warning occurs with each artwork
     element throughout the document (14 total). May the attributes be updated
     so that the figures can scale?

Warning: Found SVG with width or height specified, which will make the artwork
not scale.  Specify a viewBox only to let the artwork scale.-->
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="416" width="560" viewBox="0 0 560 416" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,352 L 8,384" fill="none" stroke="black"/>
              <path d="M 32,64 L 32,160" fill="none" stroke="black"/>
              <path d="M 56,256 L 56,352" fill="none" stroke="black"/>
              <path d="M 96,352 L 96,384" fill="none" stroke="black"/>
              <path d="M 128,48 L 128,80" fill="none" stroke="black"/>
              <path d="M 128,224 L 128,256" fill="none" stroke="black"/>
              <path d="M 144,192 L 144,216" fill="none" stroke="black"/>
              <path d="M 184,96 L 184,216" fill="none" stroke="black"/>
              <path d="M 224,48 L 224,80" fill="none" stroke="black"/>
              <path d="M 272,48 L 272,64" fill="none" stroke="black"/>
              <path d="M 312,80 L 312,216" fill="none" stroke="black"/>
              <path d="M 336,224 L 336,256" fill="none" stroke="black"/>
              <path d="M 360,48 L 360,64" fill="none" stroke="black"/>
              <path d="M 360,352 L 360,384" fill="none" stroke="black"/>
              <path d="M 392,256 L 392,344" fill="none" stroke="black"/>
              <path d="M 408,48 L 408,64" fill="none" stroke="black"/>
              <path d="M 456,80 L 456,344" fill="none" stroke="black"/>
              <path d="M 488,352 L 488,384" fill="none" stroke="black"/>
              <path d="M 536,48 L 536,64" fill="none" stroke="black"/>
              <path d="M 24,32 L 80,32" fill="none" stroke="black"/>
              <path d="M 144,32 L 208,32" fill="none" stroke="black"/>
              <path d="M 288,32 L 344,32" fill="none" stroke="black"/>
              <path d="M 424,32 L 520,32" fill="none" stroke="black"/>
              <path d="M 24,64 L 80,64" fill="none" stroke="black"/>
              <path d="M 288,80 L 344,80" fill="none" stroke="black"/>
              <path d="M 424,80 L 520,80" fill="none" stroke="black"/>
              <path d="M 144,96 L 208,96" fill="none" stroke="black"/>
              <path d="M 48,176 L 128,176" fill="none" stroke="black"/>
              <path d="M 128,224 L 336,224" fill="none" stroke="black"/>
              <path d="M 72,240 L 120,240" fill="none" stroke="black"/>
              <path d="M 336,240 L 376,240" fill="none" stroke="black"/>
              <path d="M 128,256 L 336,256" fill="none" stroke="black"/>
              <path d="M 8,352 L 96,352" fill="none" stroke="black"/>
              <path d="M 360,352 L 488,352" fill="none" stroke="black"/>
              <path d="M 8,384 L 96,384" fill="none" stroke="black"/>
              <path d="M 360,384 L 488,384" fill="none" stroke="black"/>
              <path d="M 24,32 C 15.16936,32 8,39.16936 8,48" fill="none" stroke="black"/>
              <path d="M 80,32 C 88.83064,32 96,39.16936 96,48" fill="none" stroke="black"/>
              <path d="M 144,32 C 135.16936,32 128,39.16936 128,48" fill="none" stroke="black"/>
              <path d="M 208,32 C 216.83064,32 224,39.16936 224,48" fill="none" stroke="black"/>
              <path d="M 288,32 C 279.16936,32 272,39.16936 272,48" fill="none" stroke="black"/>
              <path d="M 344,32 C 352.83064,32 360,39.16936 360,48" fill="none" stroke="black"/>
              <path d="M 424,32 C 415.16936,32 408,39.16936 408,48" fill="none" stroke="black"/>
              <path d="M 520,32 C 528.83064,32 536,39.16936 536,48" fill="none" stroke="black"/>
              <path d="M 24,64 C 15.16936,64 8,56.83064 8,48" fill="none" stroke="black"/>
              <path d="M 80,64 C 88.83064,64 96,56.83064 96,48" fill="none" stroke="black"/>
              <path d="M 288,80 C 279.16936,80 272,72.83064 272,64" fill="none" stroke="black"/>
              <path d="M 344,80 C 352.83064,80 360,72.83064 360,64" fill="none" stroke="black"/>
              <path d="M 424,80 C 415.16936,80 408,72.83064 408,64" fill="none" stroke="black"/>
              <path d="M 520,80 C 528.83064,80 536,72.83064 536,64" fill="none" stroke="black"/>
              <path d="M 144,96 C 135.16936,96 128,88.83064 128,80" fill="none" stroke="black"/>
              <path d="M 208,96 C 216.83064,96 224,88.83064 224,80" fill="none" stroke="black"/>
              <path d="M 48,176 C 39.16936,176 32,168.83064 32,160" fill="none" stroke="black"/>
              <path d="M 128,176 C 136.83064,176 144,183.16936 144,192" fill="none" stroke="black"/>
              <path d="M 72,240 C 63.16936,240 56,247.16936 56,256" fill="none" stroke="black"/>
              <path d="M 376,240 C 384.83064,240 392,247.16936 392,256" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="464,344 452,338.4 452,349.6 " fill="black" transform="rotate(90,456,344)"/>
              <polygon class="arrowhead" points="400,344 388,338.4 388,349.6 " fill="black" transform="rotate(90,392,344)"/>
              <polygon class="arrowhead" points="320,216 308,210.4 308,221.6 " fill="black" transform="rotate(90,312,216)"/>
              <polygon class="arrowhead" points="192,216 180,210.4 180,221.6 " fill="black" transform="rotate(90,184,216)"/>
              <polygon class="arrowhead" points="152,216 140,210.4 140,221.6 " fill="black" transform="rotate(90,144,216)"/>
              <polygon class="arrowhead" points="128,240 116,234.4 116,245.6 " fill="black" transform="rotate(0,120,240)"/>
              <g class="text">
                <text x="52" y="52">Endorser</text>
                <text x="176" y="52">Reference</text>
                <text x="316" y="52">Verifier</text>
                <text x="448" y="52">Relying</text>
                <text x="504" y="52">Party</text>
                <text x="160" y="68">Value</text>
                <text x="304" y="68">Owner</text>
                <text x="440" y="68">Owner</text>
                <text x="172" y="84">Provider</text>
                <text x="92" y="132">Endorsements</text>
                <text x="232" y="132">Reference</text>
                <text x="360" y="132">Appraisal</text>
                <text x="504" y="132">Appraisal</text>
                <text x="220" y="148">Values</text>
                <text x="348" y="148">Policy</text>
                <text x="392" y="148">for</text>
                <text x="492" y="148">Policy</text>
                <text x="536" y="148">for</text>
                <text x="356" y="164">Evidence</text>
                <text x="512" y="164">Attestation</text>
                <text x="496" y="180">Results</text>
                <text x="236" y="244">Verifier</text>
                <text x="100" y="292">Evidence</text>
                <text x="336" y="292">Attestation</text>
                <text x="320" y="308">Results</text>
                <text x="52" y="372">Attester</text>
                <text x="400" y="372">Relying</text>
                <text x="456" y="372">Party</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
   .--------.     .---------.       .--------.       .-------------.
  | Endorser |   | Reference |     | Verifier |     | Relying Party |
   '-+------'    | Value     |     | Owner    |     | Owner         |
     |           | Provider  |      '---+----'       '----+--------'
     |            '-----+---'           |                 |
     |                  |               |                 |
     | Endorsements     | Reference     | Appraisal       | Appraisal
     |                  | Values        | Policy for      | Policy for
     |                  |               | Evidence        | Attestation
      '-----------.     |               |                 | Results
                   |    |               |                 |
                   v    v               v                 |
                 .-------------------------.              |
         .------>|         Verifier        +-----.        |
        |        '-------------------------'      |       |
        |                                         |       |
        | Evidence                    Attestation |       |
        |                             Results     |       |
        |                                         |       |
        |                                         v       v
  .-----+----.                                .---------------.
  | Attester |                                | Relying Party |
  '----------'                                '---------------'
]]></artwork>                                '---------------']]></artwork>
        </artset>
      </figure>
      <t>The text below summarizes the activities conducted by the roles illustrated in <xref target="dataflow"/>.
Roles are assigned to entities. Entities are often system components <xref target="RFC4949"/>, such as devices. As the term device "device" is typically more intuitive than the term entity "entity" or system component, "system component", device is often used as an illustrative synonym throughout this document.</t>
      <t>The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier.</t>
      <t>The Verifier role is assigned to entities that use the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, Endorsers
by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester.
This procedure is called the appraisal "appraisal of Evidence.</t> Evidence".</t>
      <t>Subsequently, the Verifier role generates Attestation Results for use by Relying Parties.</t>
      <t>The Appraisal Policy for Evidence might be obtained from the Verifier Owner via some protocol mechanism,
or might be configured into the Verifier by the Verifier Owner,
or might be programmed into the Verifier,
or might be obtained via some other mechanism.</t>
      <t>The Relying Party role is assigned to an entity that uses Attestation Results by applying its own
appraisal policy to make application-specific decisions, such as authorization decisions.
This procedure is called the appraisal "appraisal of Attestation Results.</t> Results".</t>
      <t>The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism,
or might be configured into the Relying Party by the Relying Party Owner,
or might be programmed into the Relying Party, or might be obtained via some other mechanism.</t>
      <t>See <xref target="messages"/> for further discussion of the conceptual messages shown in <xref target="dataflow"/>.  <xref target="terminology"/> provides a more complete definition of all RATS roles.</t>
      <section anchor="twotypes">
        <name>Two Types of Environments of an Attester</name>
        <t>As shown in <xref target="twotypes-env"/>, an Attester consists of at least one Attesting Environment and at least one
Target Environment co-located in one entity.
In some implementations, the Attesting and Target Environments might be combined into one environment.
Other implementations might have multiple Attesting and Target Environments,
such as in the examples described in more detail in Sections <xref target="layered-attestation"/> target="layered-attestation" format="counter"/>
and <xref target="compositedevice"/>. target="compositedevice" format="counter"/>.  Other examples may exist. All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations.</t>

        <figure anchor="twotypes-env">
          <name>Two Types of Environments</name> Environments within an Attester</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="464" width="320" viewBox="0 0 320 464" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 8,144 L 8,448" fill="none" stroke="black"/>
                <path d="M 24,32 L 24,96" fill="none" stroke="black"/>
                <path d="M 48,176 L 48,240" fill="none" stroke="black"/>
                <path d="M 152,352 L 152,416" fill="none" stroke="black"/>
                <path d="M 168,240 L 168,344" fill="none" stroke="black"/>
                <path d="M 184,176 L 184,240" fill="none" stroke="black"/>
                <path d="M 216,104 L 216,352" fill="none" stroke="black"/>
                <path d="M 264,352 L 264,416" fill="none" stroke="black"/>
                <path d="M 288,32 L 288,96" fill="none" stroke="black"/>
                <path d="M 304,144 L 304,448" fill="none" stroke="black"/>
                <path d="M 24,32 L 288,32" fill="none" stroke="black"/>
                <path d="M 24,96 L 288,96" fill="none" stroke="black"/>
                <path d="M 8,144 L 208,144" fill="none" stroke="black"/>
                <path d="M 224,144 L 304,144" fill="none" stroke="black"/>
                <path d="M 48,176 L 184,176" fill="none" stroke="black"/>
                <path d="M 48,240 L 184,240" fill="none" stroke="black"/>
                <path d="M 152,352 L 264,352" fill="none" stroke="black"/>
                <path d="M 152,416 L 264,416" fill="none" stroke="black"/>
                <path d="M 8,448 L 304,448" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="224,104 212,98.4 212,109.6 " fill="black" transform="rotate(270,216,104)"/>
                <polygon class="arrowhead" points="176,344 164,338.4 164,349.6 " fill="black" transform="rotate(90,168,344)"/>
                <g class="text">
                  <text x="156" y="68">Verifier</text>
                  <text x="84" y="196">Target</text>
                  <text x="104" y="212">Environment</text>
                  <text x="260" y="228">Evidence</text>
                  <text x="128" y="292">Collect</text>
                  <text x="132" y="308">Claims</text>
                  <text x="200" y="372">Attesting</text>
                  <text x="208" y="388">Environment</text>
                  <text x="164" y="436">Attester</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
  .--------------------------------.
  |                                |
  |            Verifier            |
  |                                |
  '--------------------------------'
                          ^
                          |
.-------------------------|----------.
|                         |          |
|    .----------------.   |          |
|    | Target         |   |          |
|    | Environment    |   |          |
|    |                |   | Evidence |
|    '--------------+-'   |          |
|                   |     |          |
|                   |     |          |
|           Collect |     |          |
|            Claims |     |          |
|                   |     |          |
|                   v     |          |
|                 .-------+-----.    |
|                 | Attesting   |    |
|                 | Environment |    |
|                 |             |    |
|                 '-------------'    |
|               Attester             |
'------------------------------------'
]]></artwork>
'------------------------------------']]></artwork>
          </artset>
        </figure>
        <t>Claims are collected from Target Environments.
That is, Attesting Environments collect the values and the information to be represented in Claims, Claims by reading system registers and variables, calling into subsystems, and taking measurements on code, memory, or other security related relevant assets of the Target Environment.
Attesting Environments then format the Claims appropriately, and typically appropriately; typically, they
use key material and
cryptographic functions, such as signing or cipher algorithms, to
generate Evidence.
There is no limit to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), Environment. For example, TEEs, embedded Secure Elements
(eSEs), Trusted Platform Modules (TPMs) TPMs <xref target="TCGarch"/>, or BIOS firmware.</t>
        <t>An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.
Execution environments that are designed specifically to be capable of Claims collection are referred to in this document as Attesting Environments. "Attesting Environments".
For example, a TPM doesn't actively collect Claims itself, itself.  Instead, it instead
requires another component to feed various values to the TPM.
Thus, an Attesting Environment in such a case would be the combination
of the TPM together with whatever component is feeding it the measurements.</t>
      </section>
      <section anchor="layered-attestation">
        <name>Layered Attestation Environments</name>
        <t>By definition, the Attester role generates Evidence.  An Attester
        may consist of one or more nested environments (layers).  The bottom
        layer of an Attester has an Attesting Environment that is typically
        designed to be immutable or difficult to modify by malicious code.  In
        order to appraise Evidence generated by an Attester, the Verifier
        needs to trust various layers, including the bottom Attesting
        Environment.  Trust in the Attester's layers, including the bottom
        layer, can be established in various ways ways, as discussed in <xref
        target="verifier"/>.</t>
        <t>In layered attestation, Claims can be collected from or about each
        layer beginning with an initial layer.  The corresponding Claims can
        be structured in a nested fashion that reflects the nesting of the
        Attester's layers.  Normally, Claims are not self-asserted, rather self-asserted.  Rather, a
        previous layer acts as the Attesting Environment for the next layer.
        Claims about an initial layer typically are typically asserted by an
        Endorser.</t>
	<t>The example device illustrated in <xref target="layered"/> includes
        (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an
        operating system kernel.</t>
        <figure anchor="layered">
          <name>Layered Attester</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="656" width="440" width="448" viewBox="0 0 440 448 656" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 8,192 L 8,640" fill="none" stroke="black"/>
                <path d="M 40,32 L 40,64" fill="none" stroke="black"/>
                <path d="M 40,96 L 40,160" fill="none" stroke="black"/>
                <path d="M 40,224 L 40,304" fill="none" stroke="black"/>
                <path d="M 40,352 L 40,480" fill="none" stroke="black"/>
                <path d="M 40,528 L 40,608" fill="none" stroke="black"/>
                <path d="M 152,32 L 152,64" fill="none" stroke="black"/>
                <path d="M 152,96 L 152,160" fill="none" stroke="black"/>
                <path d="M 152,384 160,384 L 152,448" 160,448" fill="none" stroke="black"/>
                <path d="M 160,480 168,480 L 160,520" 168,520" fill="none" stroke="black"/>
                <path d="M 168,304 176,304 L 168,376" 176,376" fill="none" stroke="black"/>
                <path d="M 184,456 192,456 L 184,528" 192,528" fill="none" stroke="black"/>
                <path d="M 248,384 256,384 L 248,448" 256,448" fill="none" stroke="black"/>
                <path d="M 264,224 272,224 L 264,304" 272,304" fill="none" stroke="black"/>
                <path d="M 264,352 272,352 L 264,408" 272,408" fill="none" stroke="black"/>
                <path d="M 264,424 272,424 L 264,480" 272,480" fill="none" stroke="black"/>
                <path d="M 264,528 272,528 L 264,608" 272,608" fill="none" stroke="black"/>
                <path d="M 304,96 L 304,160" fill="none" stroke="black"/>
                <path d="M 304,192 312,192 L 304,408" 312,408" fill="none" stroke="black"/>
                <path d="M 304,424 312,424 L 304,640" 312,640" fill="none" stroke="black"/>
                <path d="M 344,48 L 344,88" fill="none" stroke="black"/>
                <path d="M 344,168 352,168 L 344,416" 352,416" fill="none" stroke="black"/>
                <path d="M 392,96 L 392,160" fill="none" stroke="black"/>
                <path d="M 40,32 L 152,32" fill="none" stroke="black"/>
                <path d="M 152,48 L 344,48" fill="none" stroke="black"/>
                <path d="M 40,64 L 152,64" fill="none" stroke="black"/>
                <path d="M 40,96 L 152,96" fill="none" stroke="black"/>
                <path d="M 304,96 L 392,96" fill="none" stroke="black"/>
                <path d="M 152,128 L 296,128" fill="none" stroke="black"/>
                <path d="M 40,160 L 152,160" fill="none" stroke="black"/>
                <path d="M 304,160 L 392,160" fill="none" stroke="black"/>
                <path d="M 8,192 L 304,192" 312,192" fill="none" stroke="black"/>
                <path d="M 40,224 L 264,224" 272,224" fill="none" stroke="black"/>
                <path d="M 40,304 L 264,304" 272,304" fill="none" stroke="black"/>
                <path d="M 40,352 L 160,352" 168,352" fill="none" stroke="black"/>
                <path d="M 176,352 184,352 L 264,352" 272,352" fill="none" stroke="black"/>
                <path d="M 152,384 160,384 L 248,384" 256,384" fill="none" stroke="black"/>
                <path d="M 248,416 256,416 L 344,416" 352,416" fill="none" stroke="black"/>
                <path d="M 152,448 160,448 L 248,448" 256,448" fill="none" stroke="black"/>
                <path d="M 40,480 L 176,480" 184,480" fill="none" stroke="black"/>
                <path d="M 192,480 200,480 L 264,480" 272,480" fill="none" stroke="black"/>
                <path d="M 40,528 L 264,528" 272,528" fill="none" stroke="black"/>
                <path d="M 40,608 L 264,608" 272,608" fill="none" stroke="black"/>
                <path d="M 8,640 L 304,640" 312,640" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="352,168 340,162.4 340,173.6 points="360,168 348,162.4 348,173.6 " fill="black" transform="rotate(270,344,168)"/> transform="rotate(270,352,168)"/>
                <polygon class="arrowhead" points="352,88 340,82.4 340,93.6 " fill="black" transform="rotate(90,344,88)"/>
                <polygon class="arrowhead" points="304,128 292,122.4 292,133.6 " fill="black" transform="rotate(0,296,128)"/>
                <polygon class="arrowhead" points="192,456 180,450.4 180,461.6 points="200,456 188,450.4 188,461.6 " fill="black" transform="rotate(270,184,456)"/> transform="rotate(270,192,456)"/>
                <polygon class="arrowhead" points="176,376 164,370.4 164,381.6 points="184,376 172,370.4 172,381.6 " fill="black" transform="rotate(90,168,376)"/> transform="rotate(90,176,376)"/>
                <polygon class="arrowhead" points="168,520 156,514.4 156,525.6 points="176,520 164,514.4 164,525.6 " fill="black" transform="rotate(90,160,520)"/> transform="rotate(90,168,520)"/>
                <g class="text">
                  <text x="224" y="36">Endorsement</text>
                  <text x="288" y="36">for</text>
                  <text x="320" y="36">ROM</text>
                  <text x="92" y="52">Endorser</text>
                  <text x="216" y="100">Reference</text>
                  <text x="88" y="116">Reference</text>
                  <text x="204" y="116">Values</text>
                  <text x="248" y="116">for</text>
                  <text x="72" y="132">Value</text>
                  <text x="348" y="132">Verifier</text>
                  <text x="96" y="148">Provider(s)</text>
                  <text x="180" y="148">ROM,</text>
                  <text x="248" y="148">bootloader,</text>
                  <text x="200" y="164">and</text>
                  <text x="244" y="164">kernel</text>
                  <text x="76" y="244">Kernel</text> x="88" y="244">Kernel(C)</text>
                  <text x="384" x="392" y="260">Layered</text>
                  <text x="92" y="276">Target</text>
                  <text x="388" x="396" y="276">Evidence</text>
                  <text x="96" y="292">Environment</text>
                  <text x="384" x="392" y="292">for</text>
                  <text x="396" x="404" y="308">bootloader</text>
                  <text x="128" x="136" y="324">Collect</text>
                  <text x="384" x="392" y="324">and</text>
                  <text x="124" x="132" y="340">Claims</text>
                  <text x="380" x="388" y="340">kernel</text>
                  <text x="92" y="372">Bootloader</text> x="104" y="372">Bootloader(B)</text>
                  <text x="92" y="404">Target</text>
                  <text x="200" x="208" y="404">Attesting</text>
                  <text x="96" y="420">Environment</text>
                  <text x="200" x="208" y="420">Environment</text>
                  <text x="120" x="128" y="500">Collect</text>
                  <text x="228" x="236" y="500">Evidence</text>
                  <text x="280" x="288" y="500">for</text>
                  <text x="116" x="124" y="516">Claims</text>
                  <text x="236" x="244" y="516">bootloader</text>
                  <text x="64" y="548">ROM</text> x="76" y="548">ROM(A)</text>
                  <text x="200" x="208" y="580">Attesting</text>
                  <text x="200" x="208" y="596">Environment</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
    .-------------.   Endorsement for ROM
    |  Endorser   +-----------------------.
    '-------------'                       |
                                          v
    .-------------.   Reference      .----------.
    | Reference   |   Values for     |          |
    | Value       +----------------->| Verifier |
    | Provider(s) | ROM, bootloader, |          |
    '-------------'    and kernel    '----------'
                                          ^
.------------------------------------.    |
|                                    |    |
|   .---------------------------.    |    |
|   | Kernel Kernel(C)                 |    |    |
|   |                           |    |    | Layered
|   |   Target                  |    |    | Evidence
|   | Environment               |    |    |   for
|   '---------------+-----------'    |    | bootloader
|           Collect |                |    |   and
|           Claims  |                |    | kernel
|   .---------------|-----------.    |    |
|   | Bootloader Bootloader(B) v           |    |    |
|   |             .-----------. |    |    |
|   |   Target    | Attesting | |    |    |
|   | Environment |Environment+-----------'
|   |             |           | |    |
|   |             '-----------' |    |
|   |                 ^         |    |
|   '--------------+--|---------'    |
|          Collect |  | Evidence for |
|          Claims  v  | bootloader   |
|   .-----------------+---------.    |
|   | ROM ROM(A)                    |    |
|   |                           |    |
|   |               Attesting   |    |
|   |              Environment  |    |
|   '---------------------------'    |
|                                    |
'------------------------------------'
]]></artwork>
'------------------------------------']]></artwork>
          </artset>
        </figure>
        <t>The first Attesting Environment, the Environment (the ROM in this example, example)
has to ensure the integrity of the bootloader (the first Target Environment).
There are
potentially multiple kernels to boot, and boot; the decision is up to the bootloader.
Only a bootloader with intact integrity will make an appropriate decision.
Therefore, the Claims relating to the integrity of the bootloader have to be measured securely.
At this stage of the boot-cycle boot cycle of the
device, the Claims collected typically cannot be composed into Evidence.</t>
        <t>After the boot sequence is started, the BIOS conducts the most
        important and defining feature of layered attestation, which is that attestation: the
        successfully measured bootloader now becomes (or contains) an
        Attesting Environment for the next layer.  This procedure in layered
        attestation is sometimes called "staging".  It is important that the
        bootloader not be able to alter any Claims about itself that were
        collected by the BIOS.  This can be ensured having those Claims be
        either signed by the BIOS or stored in a tamper-proof manner by the
        BIOS.</t>
        <t>Continuing with this example, the bootloader's Attesting
        Environment is now in charge of collecting Claims about the next
        Target Environment, which in Environment.  In this example example, it is the kernel to be booted.

The final Evidence thus contains two sets of Claims: one set about the
bootloader as measured and signed by the BIOS,
plus a BIOS and another set of Claims about the
kernel as measured and signed by the bootloader.</t>
        <t>This example could be extended further by making the kernel become another
Attesting Environment for an application as another Target Environment.
This would result in a third set of Claims in the Evidence pertaining to that application.</t>
        <t>The essence of this example is a cascade of staged environments. Each
environment has the responsibility
of measuring the next environment before the next environment is started.
In general, the number of layers may vary by device or implementation,
and an Attesting Environment might even have multiple Target Environments
that it measures, rather than only one as shown by example in <xref target="layered"/>.</t>
      </section>
      <section anchor="compositedevice">
        <name>Composite Device</name>
        <t>A composite device is an entity composed of multiple sub-entities such that its
trustworthiness has to be determined by the appraisal of all these sub-entities.</t>
        <t>Each sub-entity has at least one Attesting Environment collecting the Claims
from at least one Target Environment, then Environment. Then, this sub-entity generates Evidence
about its trustworthiness. Therefore, trustworthiness; therefore, each sub-entity can be called an Attester. "Attester".
Among all the Attesters, there may be only some which that have the ability to communicate
with the Verifier while others do not.</t>
        <t>For example, a carrier-grade router consists of a chassis and multiple slots.
The trustworthiness of the router depends on all its slots' trustworthiness.
Each slot has an Attesting Environment, such as a TEE, collecting the
Claims of its boot process, after which it generates Evidence from the Claims.</t>
        <t>Among these slots, only a "main" slot can communicate with the Verifier
while other slots cannot. But However, other slots can communicate with the main
slot by the links between them inside the router.
So the
The main slot collects the Evidence of other slots, produces the final Evidence of the whole router router, and conveys the final Evidence to the Verifier.
Therefore, the router is a composite
device, each slot is an Attester, and the main slot is the lead Attester.</t>
        <t>Another example is a multi-chassis router composed of multiple single carrier-grade routers.
Multi-chassis router setups create redundancy groups that provide higher throughput by interconnecting
multiple routers in these groups, which can be treated as one logical router for simpler management.
A multi-chassis router setup provides a management point that connects to the Verifier.
Typically, one router in the group is designated as the main router.
Other routers in the multi-chassis setup are connected to the main router only via physical network links
and links; therefore, they are therefore managed and appraised via the main router's help.
Consequently, a multi-chassis router setup is a composite device,
each router is an Attester, and the main router is the lead Attester.</t>
        <t><xref target="composite"/> depicts the conceptual data flow for a composite device.</t>
   <figure anchor="composite">
          <name>Composite Device</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="416" width="552" viewBox="0 0 552 416" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 8,160 L 8,400" fill="none" stroke="black"/>
                <path d="M 24,176 L 24,352" fill="none" stroke="black"/>
                <path d="M 48,240 L 48,304" fill="none" stroke="black"/>
                <path d="M 120,208 L 120,240" fill="none" stroke="black"/>
                <path d="M 160,32 L 160,64" fill="none" stroke="black"/>
                <path d="M 184,240 L 184,304" fill="none" stroke="black"/>
                <path d="M 208,192 L 208,288" fill="none" stroke="black"/>
                <path d="M 288,72 L 288,192" fill="none" stroke="black"/>
                <path d="M 312,192 L 312,288" fill="none" stroke="black"/>
                <path d="M 336,176 L 336,200" fill="none" stroke="black"/>
                <path d="M 336,280 L 336,352" fill="none" stroke="black"/>
                <path d="M 392,176 L 392,224" fill="none" stroke="black"/>
                <path d="M 400,32 L 400,64" fill="none" stroke="black"/>
                <path d="M 408,240 408,224 L 408,256" fill="none" stroke="black"/>
                <path d="M 424,272 424,256 L 424,288" fill="none" stroke="black"/>
                <path d="M 496,176 L 496,224" fill="none" stroke="black"/>
                <path d="M 512,208 L 512,256" fill="none" stroke="black"/>
                <path d="M 528,240 L 528,288" fill="none" stroke="black"/>
                <path d="M 544,160 L 544,400" fill="none" stroke="black"/>
                <path d="M 160,32 L 400,32" fill="none" stroke="black"/>
                <path d="M 160,64 L 400,64" fill="none" stroke="black"/>
                <path d="M 8,160 L 280,160" fill="none" stroke="black"/>
                <path d="M 296,160 L 544,160" fill="none" stroke="black"/>
                <path d="M 24,176 L 280,176" fill="none" stroke="black"/>
                <path d="M 296,176 L 336,176" fill="none" stroke="black"/>
                <path d="M 392,176 L 496,176" fill="none" stroke="black"/>
                <path d="M 208,192 L 312,192" fill="none" stroke="black"/>
                <path d="M 120,208 L 200,208" fill="none" stroke="black"/>
                <path d="M 320,208 L 392,208" fill="none" stroke="black"/>
                <path d="M 496,208 L 512,208" fill="none" stroke="black"/>
                <path d="M 392,224 L 496,224" fill="none" stroke="black"/>
                <path d="M 48,240 L 184,240" fill="none" stroke="black"/>
                <path d="M 320,240 L 408,240" fill="none" stroke="black"/>
                <path d="M 512,240 L 528,240" fill="none" stroke="black"/>
                <path d="M 408,256 L 512,256" fill="none" stroke="black"/>
                <path d="M 320,272 L 424,272" fill="none" stroke="black"/>
                <path d="M 208,288 L 312,288" fill="none" stroke="black"/>
                <path d="M 424,288 L 528,288" fill="none" stroke="black"/>
                <path d="M 48,304 L 184,304" fill="none" stroke="black"/>
                <path d="M 24,352 L 336,352" fill="none" stroke="black"/>
                <path d="M 8,400 L 544,400" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="328,272 316,266.4 316,277.6 " fill="black" transform="rotate(180,320,272)"/>
                <polygon class="arrowhead" points="328,240 316,234.4 316,245.6 " fill="black" transform="rotate(180,320,240)"/>
                <polygon class="arrowhead" points="328,208 316,202.4 316,213.6 " fill="black" transform="rotate(180,320,208)"/>
                <polygon class="arrowhead" points="296,72 284,66.4 284,77.6 " fill="black" transform="rotate(270,288,72)"/>
                <polygon class="arrowhead" points="208,208 196,202.4 196,213.6 " fill="black" transform="rotate(0,200,208)"/>
                <g class="text">
                  <text x="284" y="52">Verifier</text>
                  <text x="332" y="116">Evidence</text>
                  <text x="380" y="116">of</text>
                  <text x="336" y="132">Composite</text>
                  <text x="404" y="132">Device</text>
                  <text x="72" y="196">Collect</text>
                  <text x="68" y="212">Claims</text>
                  <text x="264" y="212">Attesting</text>
                  <text x="436" y="212">Attester</text>
                  <text x="480" y="212">B</text>
                  <text x="256" y="228">Environment</text>
                  <text x="336" y="228">|</text>
                  <text x="452" y="244">Attester</text>
                  <text x="496" y="244">C</text>
                  <text x="116" y="260">Target</text>
                  <text x="336" y="260">|</text>
                  <text x="116" y="276">Environment(s)</text>
                  <text x="448" y="276">...</text>
                  <text x="380" y="292">Evidence</text>
                  <text x="380" y="308">of</text>
                  <text x="384" y="324">Attesters</text>
                  <text x="52" y="340">lead</text>
                  <text x="108" y="340">Attester</text>
                  <text x="152" y="340">A</text>
                  <text x="364" y="340">(via</text>
                  <text x="420" y="340">Internal</text>
                  <text x="480" y="340">Links</text>
                  <text x="516" y="340">or</text>
                  <text x="376" y="356">Network</text>
                  <text x="460" y="356">Connections)</text>
                  <text x="232" y="388">Composite</text>
                  <text x="300" y="388">Device</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
                   .-----------------------------.
                   |           Verifier          |
                   '-----------------------------'
                                   ^
                                   |
                                   | Evidence of
                                   | Composite Device
                                   |
.----------------------------------|-------------------------------.
| .--------------------------------|-----.      .------------.     |
| |  Collect             .---------+--.  |      |            |     |
| |  Claims   .--------->|  Attesting |<--------+ Attester B +-.   |
| |           |          |Environment |  |      '------------'      '-+----------' |   |
| |  .--------+-------.  |            |<----------+ Attester C +-. |
| |  |     Target     |  |            |  |        '------------'        '-+----------' | |
| |  | Environment(s) |  |            |<------------+ ...        | |
| |  |                |  '------------'  | Evidence '------------' |
| |  '----------------'                  |    of                   |
| |                                      | Attesters               |
| | lead Attester A                      | (via Internal Links or  |
| '--------------------------------------' Network Connections)    |
|                                                                  |
|                       Composite Device                           |
'------------------------------------------------------------------'
]]></artwork>
          </artset>
        </figure>

        <t>In a composite device, each Attester generates its own Evidence by its
Attesting Environment(s) collecting the Claims from its Target Environment(s).
The lead Attester collects Evidence from other Attesters and conveys it to a Verifier.
Collection of Evidence from sub-entities may itself be a form of Claims collection that results in Evidence asserted by the lead Attester.
The lead Attester generates Evidence about the layout of the whole composite device, while sub-Attesters generate Evidence about their respective (sub-)modules.</t>
        <t>In this scenario, the trust model described in <xref target="trustmodel"/> can also be applied to an inside Verifier.</t>
      </section>
      <section anchor="implementation-considerations">
        <name>Implementation Considerations</name>
        <t>An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying
Party, etc.) at the same time.
Multiple entities can cooperate to implement a single RATS role as well.
In essence, the combination of roles and entities can be arbitrary.
For example, in the composite device scenario, the entity inside
the lead Attester can also take on the role of a Verifier, Verifier and the
outer entity of Verifier can take on the role of a Relying Party.
After collecting the Evidence of other Attesters, this inside Verifier uses
Endorsements and appraisal policies (obtained the same way as by any other
Verifier) as part of the appraisal procedures that generate Attestation Results.
The inside Verifier then conveys the Attestation Results of other Attesters to the outside Verifier,
whether in the same conveyance protocol as part of the Evidence or not.</t>
        <t>As explained in <xref target="terminology"/>, there are a variety of roles in the RATS architecture and architecture; they are defined by a unique combination of artifacts they produce and consume.
Conversely, artifacts are also defined by the roles that produce or consume them.
To produce an artifact means that a given role introduces it into the RATS architecture.
To consume an artifact means that a given role has responsibility for processing it in the RATS architecture.
Roles also have the ability to perform additional actions actions, such as caching or forwarding artifacts as opaque data.
As depicted in <xref target="overview"/>, these additional actions can be performed by several roles.</t>
      </section>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t><xref target="RFC4949"/> has defined a number of terms that are also used in this document.
Some of the terms are close to, but not exactly the same.
Where the terms are similar, they are noted below with references.

As explained in <xref target="RFC4949"/>, Section 2.6 target="RFC4949" sectionFormat="of" section="2.6"/>, when this document says "Compare:", the terminology used in this document differs significantly from the definition in the reference.</t>
      <t>This document uses the following terms.</t> terms in the subsections that follow.</t>
      <section anchor="roles">
        <name>Roles</name>
        <dl>
          <dt>Attester:</dt>
          <dd>
            <t>A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether it is authorized to perform some operation.</t>
          </dd>
          <dt/>
          <dd>
            <t>Produces: Evidence</t>
          <dl newline="false" spacing="normal">
            <dt>Produces:</dt><dd>Evidence</dd>
	  </dl>
	</dd>
            <dt>Relying Party:</dt>
          <dd>
            <t>A role performed by an entity that depends on the validity of information about an Attester, Attester for purposes of reliably applying application specific application-specific actions.  Compare: /relying party/ in relying party <xref target="RFC4949"/>.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumes: Attestation
<dl newline="false" spacing="normal">
            <dt>Consumes:</dt><dd>Attestation Results, Appraisal Policy for Attestation Results</t> Results</dd>
          </dl>
	  </dd>
          <dt>Verifier:</dt>
          <dd>
            <t>A role performed by an entity that appraises the validity of Evidence about an Attester
 and produces Attestation Results to be used by a Relying Party.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumes: Evidence,
<dl newline="false" spacing="normal">
            <dt>Consumes:</dt><dd>Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence</t>
          </dd>
          <dt/>
          <dd>
            <t>Produces: Attestation Results</t> Evidence</dd>
            <dt>Produces:</dt><dd>Attestation Results</dd>
</dl>
          </dd>
          <dt>Relying Party Owner:</dt>
          <dd>
            <t>A role performed by an entity (typically an administrator), administrator) that is authorized to configure an Appraisal Policy for Attestation Results in a Relying Party.</t>
          </dd>
          <dt/>
          <dd>
            <t>Produces: Appraisal
<dl newline="false" spacing="normal">
            <dt>Produces:</dt><dd>Appraisal Policy for Attestation Results</t> Results</dd>
</dl>
          </dd>
          <dt>Verifier Owner:</dt>
          <dd>
            <t>A role performed by an entity (typically an administrator), administrator) that is authorized to configure an Appraisal Policy for Evidence in a Verifier.</t>
          </dd>
          <dt/>
          <dd>
            <t>Produces: Appraisal
          <dl newline="false" spacing="normal">
            <dt>Produces:</dt><dd>Appraisal Policy for Evidence</t> Evidence</dd>
	  </dl>
          </dd>
          <dt>Endorser:</dt>
          <dd>
            <t>A role performed by an entity (typically a manufacturer) whose Endorsements may help Verifiers appraise the authenticity of Evidence and infer further capabilities of the Attester.</t>
          </dd>
          <dt/>
          <dd>
            <t>Produces: Endorsements</t>
<dl newline="false" spacing="normal">
          <dt>Produces:</dt><dd>Endorsements</dd>
          </dl>
	  </dd>
          <dt>Reference Value Provider:</dt>
          <dd>
            <t>A role performed by an entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known Claims have been recorded by the Attester.</t>
          </dd>
          <dt/>
          <dd>
            <t>Produces: Reference Values</t>
<dl newline="false" spacing="normal">
            <dt>Produces:</dt><dd>Reference Values</dd>
</dl>
          </dd>
        </dl>
      </section>
      <section anchor="artifacts">
        <name>Artifacts</name>
        <dl>
          <dt>Claim:</dt>
          <dd>
            <t>A piece of asserted information, often in the form of a name/value pair. Claims make up the usual structure of Evidence and other RATS artifacts. conceptual messages.
Compare: /claim/ in claim <xref target="RFC7519"/>.</t>
          </dd>
          <dt>Endorsement:</dt>
          <dd>
            <t>A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities capabilities, such as Claims collection and Evidence signing.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumed By: Verifier</t>
          </dd>
          <dt/>
          <dd>
            <t>Produced By: Endorser</t>
<dl newline="false" spacing="normal">
          <dt>Consumed By:</dt><dd>Verifier</dd>
          <dt>Produced By:</dt><dd>Endorser</dd>
</dl>
          </dd>
          <dt>Evidence:</dt>
          <dd>
            <t>A set of Claims generated by an Attester to be appraised by a Verifier.
Evidence may include configuration data, measurements, telemetry, or inferences.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumed By: Verifier</t>
          </dd>
          <dt/>
          <dd>
            <t>Produced By: Attester</t>
<dl newline="false" spacing="normal">
<dt>Consumed By:</dt><dd>Verifier</dd>
          <dt>Produced By:</dt><dd>Attester</dd>
</dl>
</dd>
          <dt>Attestation Result:</dt>
          <dd>
            <t>The output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumed By: Relying Party</t>
          </dd>
          <dt/>
          <dd>
            <t>Produced By: Verifier</t>
<dl newline="false" spacing="normal">
          <dt>Consumed By:</dt><dd>Relying Party</dd>
          <dt>Produced By:</dt><dd>Verifier</dd>
</dl>
	  </dd>
          <dt>Appraisal Policy for Evidence:</dt>
          <dd>

            <t>A set of rules that informs how
  a Verifier evaluates uses to evaluate the validity of information
  about an Attester. Compare: /security policy/ in security policy <xref target="RFC4949"/>.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumed By: Verifier</t>
          </dd>
          <dt/>
          <dd>
            <t>Produced By: Verifier Owner</t>
<dl newline="false" spacing="normal">
          <dt>Consumed By:</dt><dd>Verifier</dd>
          <dt>Produced By:</dt><dd>Verifier Owner</dd>
</dl>
          </dd>
          <dt>Appraisal Policy for Attestation Results:</dt>
          <dd>
            <t>A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers. Compare: /security policy/ in security policy <xref target="RFC4949"/>.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumed by: Relying Party</t>
          </dd>
          <dt/>
          <dd>
            <t>Produced by: Relying
<dl newline="false" spacing="normal">
            <dt>Consumed by:</dt><dd>Relying Party</dd>
            <dt>Produced by:</dt><dd>Relying Party Owner</t> Owner</dd>
</dl>
          </dd>
          <dt>Reference Values:</dt>
          <dd>
            <t>A set of values against which values of Claims can be compared as part of
applying an Appraisal Policy for Evidence.  Reference Values are sometimes
referred to in other documents as known-good values, golden measurements,
or nominal values, although those "known-good values", "golden measurements",
or "nominal values". These terms typically assume comparison for
equality, whereas here here, Reference Values might be more general and be used
in any sort of comparison.</t>
          </dd>
          <dt/>
          <dd>
            <t>Consumed By: Verifier</t>
          </dd>
          <dt/>
          <dd>
            <t>Produced By: Reference
     <dl newline="false" spacing="normal">
            <dt>Consumed By:</dt><dd>Verifier</dd>
            <dt>Produced By:</dt><dd>Reference Value Provider</t> Provider</dd>
     </dl>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="overview">
      <name>Topological Patterns</name>
      <t><xref target="dataflow"/> shows a data-flow data flow diagram for communication between an Attester,
a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifier
for appraisal, appraisal and the Relying Party receives the Attestation Result from the Verifier.
This section refines the data-flow diagram by describing two
reference models, as well as one example composition thereof. The
discussion that follows is for illustrative purposes only and does
not constrain the interactions between RATS roles to the presented patterns.</t> models.</t>
      <section anchor="passport-model">
        <name>Passport Model</name>
        <t>The passport model Passport Model is so named because of its resemblance to how nations issue
passports to their citizens. The nature of the Evidence that an individual needs
to provide to its local authority is specific to the country involved. The citizen
retains control of the resulting passport document and presents it to other entities
when it needs to assert a citizenship or identity Claim, such as at an airport immigration
desk. The passport is considered sufficient because it vouches for the citizenship and
identity Claims, Claims and it is issued by a trusted authority.</t>
        <t>Thus, in this immigration desk analogy,
the citizen is the Attester,
the passport issuing passport-issuing agency is a Verifier,
and the passport application and identifying information (e.g., birth certificate) is the
the Evidence.
The passport is an Attestation Result, Result and the immigration desk is a Relying Party.</t>
        <t>In this model, an Attester conveys Evidence to a Verifier, which Verifier that compares
the Evidence against its appraisal policy.
The Verifier then gives back an Attestation Result which that the Attester treats as opaque data.</t>
        <t>The Attester does not consume the Attestation Result, but it might cache it.
The Attester can then present the Attestation Result (and possibly additional Claims)
to a Relying Party, which then compares this information against its own
appraisal policy.
The Attester may also present the same Attestation Result to other Relying Parties.</t>
        <t>Three
        <t>There are three ways in which the process may fail include:</t> fail: </t>
        <ul spacing="normal">
          <li>First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence.</li>

          <li>The second way in which the process may fail is when the Attestation Result
is examined by the Relying Party, and based upon the Appraisal Policy for
Attestation Results, the result does not pass comply with the policy.</li>
          <li>The third way is when the Verifier is unreachable or unavailable.</li>
        </ul>
        <t>As with any other information needed by the Relying Party to make an authorization decision,
an Attestation Result can be carried in a resource access protocol between the Attester and Relying Party.
In this model model, the details of the resource access protocol
constrain the serialization format of the Attestation Result. The On the other hand, the
format of the Evidence on the other hand is only constrained by the
Attester-Verifier remote attestation protocol.
This implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence.</t>
        <figure anchor="passport">
          <name>Passport Model</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width="552" viewBox="0 0 552 272" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 48,32 L 48,96" fill="none" stroke="black"/>
                <path d="M 48,176 L 48,240" fill="none" stroke="black"/>
                <path d="M 80,104 L 80,176" fill="none" stroke="black"/>
                <path d="M 120,96 L 120,168" fill="none" stroke="black"/>
                <path d="M 152,32 L 152,96" fill="none" stroke="black"/>
                <path d="M 152,176 L 152,240" fill="none" stroke="black"/>
                <path d="M 272,176 L 272,240" fill="none" stroke="black"/>
                <path d="M 384,176 L 384,240" fill="none" stroke="black"/>
                <path d="M 48,32 L 152,32" fill="none" stroke="black"/>
                <path d="M 48,96 L 152,96" fill="none" stroke="black"/>
                <path d="M 48,176 L 152,176" fill="none" stroke="black"/>
                <path d="M 272,176 L 384,176" fill="none" stroke="black"/>
                <path d="M 152,192 L 264,192" fill="none" stroke="black"/>
                <path d="M 48,240 L 152,240" fill="none" stroke="black"/>
                <path d="M 272,240 L 384,240" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="272,192 260,186.4 260,197.6 " fill="black" transform="rotate(0,264,192)"/>
                <polygon class="arrowhead" points="128,168 116,162.4 116,173.6 " fill="black" transform="rotate(90,120,168)"/>
                <polygon class="arrowhead" points="88,104 76,98.4 76,109.6 " fill="black" transform="rotate(270,80,104)"/>
                <g class="text">
                  <text x="192" y="52">Compare</text>
                  <text x="260" y="52">Evidence</text>
                  <text x="100" y="68">Verifier</text>
                  <text x="192" y="68">against</text>
                  <text x="264" y="68">appraisal</text>
                  <text x="332" y="68">policy</text>
                  <text x="36" y="132">Evidence</text>
                  <text x="176" y="132">Attestation</text>
                  <text x="156" y="148">Result</text>
                  <text x="424" y="196">Compare</text>
                  <text x="504" y="196">Attestation</text>
                  <text x="100" y="212">Attester</text>
                  <text x="208" y="212">Attestation</text>
                  <text x="328" y="212">Relying</text>
                  <text x="420" y="212">Result</text>
                  <text x="480" y="212">against</text>
                  <text x="188" y="228">Result</text>
                  <text x="328" y="228">Party</text>
                  <text x="432" y="228">appraisal</text>
                  <text x="500" y="228">policy</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
       .------------.
       |            | Compare Evidence
       |  Verifier  | against appraisal policy
       |            |
       '--------+---'
           ^    |
  Evidence |    | Attestation
           |    | Result
           |    v
       .---+--------.              .-------------.
       |            +------------->|             | Compare Attestation
       |  Attester  | Attestation  |   Relying   | Result against
       |            | Result       |    Party    | appraisal policy
       '------------'              '-------------'
]]></artwork>              '-------------']]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="background-check-model">
        <name>Background-Check Model</name>
        <t>The background-check model Background-Check Model is so named because of the resemblance
        of how employers and volunteer organizations perform background
        checks. When a prospective employee provides Claims about education or
        previous experience, the employer will contact the respective
        institutions or former employers to validate the Claim. Volunteer
        organizations often perform police background checks on volunteers in
        order to determine the volunteer's trustworthiness.  Thus, in this
        analogy, a prospective volunteer is an Attester, the organization is
        the Relying Party, and the organization that issues a report is a
        Verifier.</t>
        <t>In this model, an Attester conveys Evidence to a Relying Party,
        which treats it as opaque and simply forwards it on to a Verifier.
        The Verifier compares the Evidence against its appraisal policy, policy and
        returns an Attestation Result to the Relying Party.  The Relying Party
        then compares the Attestation Result against its own appraisal
        policy.</t>
        <t>The resource access protocol between the Attester and Relying Party
        includes Evidence rather than an Attestation Result, but that Evidence
        is not processed by the Relying Party.</t>
        <t>Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it.  The only requirement is that the Evidence can be <em>encapsulated in</em> <em>encapsulated</em> in the format
required by the resource access protocol between the Attester and Relying Party.</t>
<t>However, like as seen in the Passport model, Model, an Attestation Result is still consumed by the
Relying Party.  Code footprint and attack surface area can be minimized by
using a serialization format for which the Relying Party already needs a
parser to support the protocol between the Attester and Relying Party,
which may be an existing standard or widely deployed resource access protocol.
Such minimization is especially important if the Relying Party is a
constrained node.</t>
        <figure anchor="backgroundcheck">
          <name>Background-Check Model</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width="520" viewBox="0 0 520 272" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 8,176 L 8,240" fill="none" stroke="black"/>
                <path d="M 112,176 L 112,240" fill="none" stroke="black"/>
                <path d="M 240,32 L 240,96" fill="none" stroke="black"/>
                <path d="M 240,176 L 240,240" fill="none" stroke="black"/>
                <path d="M 280,104 L 280,176" fill="none" stroke="black"/>
                <path d="M 312,96 L 312,168" fill="none" stroke="black"/>
                <path d="M 352,32 L 352,96" fill="none" stroke="black"/>
                <path d="M 352,176 L 352,240" fill="none" stroke="black"/>
                <path d="M 240,32 L 352,32" fill="none" stroke="black"/>
                <path d="M 240,96 L 352,96" fill="none" stroke="black"/>
                <path d="M 8,176 L 112,176" fill="none" stroke="black"/>
                <path d="M 240,176 L 272,176" fill="none" stroke="black"/>
                <path d="M 288,176 L 352,176" fill="none" stroke="black"/>
                <path d="M 112,192 L 232,192" fill="none" stroke="black"/>
                <path d="M 248,192 L 264,192" fill="none" stroke="black"/>
                <path d="M 8,240 L 112,240" fill="none" stroke="black"/>
                <path d="M 240,240 L 352,240" fill="none" stroke="black"/>
                <path d="M 264,192 C 272.83064,192 280,184.83064 280,176" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="320,168 308,162.4 308,173.6 " fill="black" transform="rotate(90,312,168)"/>
                <polygon class="arrowhead" points="288,104 276,98.4 276,109.6 " fill="black" transform="rotate(270,280,104)"/>
                <polygon class="arrowhead" points="240,192 228,186.4 228,197.6 " fill="black" transform="rotate(0,232,192)"/>
                <g class="text">
                  <text x="392" y="52">Compare</text>
                  <text x="460" y="52">Evidence</text>
                  <text x="300" y="68">Verifier</text>
                  <text x="392" y="68">against</text>
                  <text x="464" y="68">appraisal</text>
                  <text x="388" y="84">policy</text>
                  <text x="236" y="132">Evidence</text>
                  <text x="368" y="132">Attestation</text>
                  <text x="348" y="148">Result</text>
                  <text x="392" y="196">Compare</text>
                  <text x="472" y="196">Attestation</text>
                  <text x="60" y="212">Attester</text>
                  <text x="172" y="212">Evidence</text>
                  <text x="312" y="212">Relying</text>
                  <text x="388" y="212">Result</text>
                  <text x="448" y="212">against</text>
                  <text x="312" y="228">Party</text>
                  <text x="400" y="228">appraisal</text>
                  <text x="468" y="228">policy</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
                                .-------------.
                                |             | Compare Evidence
                                |   Verifier  | against appraisal
                                |             | policy
                                '--------+----'
                                     ^   |
                            Evidence |   | Attestation
                                     |   | Result
                                     |   v
   .------------.               .----|--------.
   |            +-------------->|---'         | Compare Attestation
   |  Attester  |   Evidence    |     Relying | Result against
   |            |               |      Party  | appraisal policy
   '------------'               '-------------'
]]></artwork>               '-------------']]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="combinations">
        <name>Combinations</name>
        <t>One variation of the background-check model Background-Check Model is where the Relying Party
and the Verifier are on the same machine, performing machine, performing both functions together.  together.
In this case, there is no need for a protocol between the two.</t>
        <t>It is also worth pointing out that the choice of model depends on the use case, case and that different Relying Parties may use different topological patterns.</t>
        <t>The same device may need to create Evidence for different Relying Parties and/or different use cases.  cases.
For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, network and
the other model to provide Evidence to a server holding confidential data to data to gain access to that data.
As such, both models may simultaneously be in use by the same device.</t>
        <t><xref target="combination"/> shows another example of a combination where Relying Party 1 uses the
passport model,
Passport Model, whereas Relying Party 2 uses an extension of the background-check model. Background-Check Model.
Specifically, in addition to the basic functionality shown in <xref target="backgroundcheck"/>, Relying Party 2
actually provides the Attestation Result back to the Attester, allowing the Attester to
use it with other Relying Parties.  This is the model that the Trusted Application Manager TAM
plans to support in the TEEP architecture <xref target="I-D.ietf-teep-architecture"/>.</t>
        <figure anchor="combination">
          <name>Example Combination</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="416" width="560" viewBox="0 0 560 416" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 40,32 L 40,96" fill="none" stroke="black"/>
                <path d="M 40,176 L 40,240" fill="none" stroke="black"/>
                <path d="M 40,320 L 40,384" fill="none" stroke="black"/>
                <path d="M 80,104 L 80,176" fill="none" stroke="black"/>
                <path d="M 80,248 L 80,320" fill="none" stroke="black"/>
                <path d="M 112,96 L 112,168" fill="none" stroke="black"/>
                <path d="M 112,240 L 112,312" fill="none" stroke="black"/>
                <path d="M 152,32 L 152,96" fill="none" stroke="black"/>
                <path d="M 152,176 L 152,240" fill="none" stroke="black"/>
                <path d="M 152,320 L 152,384" fill="none" stroke="black"/>
                <path d="M 280,320 L 280,384" fill="none" stroke="black"/>
                <path d="M 392,320 L 392,384" fill="none" stroke="black"/>
                <path d="M 40,32 L 152,32" fill="none" stroke="black"/>
                <path d="M 40,96 L 152,96" fill="none" stroke="black"/>
                <path d="M 40,176 L 152,176" fill="none" stroke="black"/>
                <path d="M 40,240 L 152,240" fill="none" stroke="black"/>
                <path d="M 40,320 L 152,320" fill="none" stroke="black"/>
                <path d="M 280,320 L 392,320" fill="none" stroke="black"/>
                <path d="M 152,336 L 272,336" fill="none" stroke="black"/>
                <path d="M 40,384 L 152,384" fill="none" stroke="black"/>
                <path d="M 280,384 L 392,384" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="280,336 268,330.4 268,341.6 " fill="black" transform="rotate(0,272,336)"/>
                <polygon class="arrowhead" points="120,312 108,306.4 108,317.6 " fill="black" transform="rotate(90,112,312)"/>
                <polygon class="arrowhead" points="120,168 108,162.4 108,173.6 " fill="black" transform="rotate(90,112,168)"/>
                <polygon class="arrowhead" points="88,248 76,242.4 76,253.6 " fill="black" transform="rotate(270,80,248)"/>
                <polygon class="arrowhead" points="88,104 76,98.4 76,109.6 " fill="black" transform="rotate(270,80,104)"/>
                <g class="text">
                  <text x="192" y="52">Compare</text>
                  <text x="260" y="52">Evidence</text>
                  <text x="100" y="68">Verifier</text>
                  <text x="192" y="68">against</text>
                  <text x="264" y="68">appraisal</text>
                  <text x="332" y="68">policy</text>
                  <text x="36" y="132">Evidence</text>
                  <text x="168" y="132">Attestation</text>
                  <text x="148" y="148">Result</text>
                  <text x="192" y="196">Compare</text>
                  <text x="96" y="212">Relying</text>
                  <text x="208" y="212">Attestation</text>
                  <text x="284" y="212">Result</text>
                  <text x="88" y="228">Party</text>
                  <text x="120" y="228">2</text>
                  <text x="192" y="228">against</text>
                  <text x="264" y="228">appraisal</text>
                  <text x="332" y="228">policy</text>
                  <text x="36" y="276">Evidence</text>
                  <text x="168" y="276">Attestation</text>
                  <text x="148" y="292">Result</text>
                  <text x="432" y="340">Compare</text>
                  <text x="512" y="340">Attestation</text>
                  <text x="100" y="356">Attester</text>
                  <text x="216" y="356">Attestation</text>
                  <text x="336" y="356">Relying</text>
                  <text x="428" y="356">Result</text>
                  <text x="488" y="356">against</text>
                  <text x="220" y="372">Result</text>
                  <text x="328" y="372">Party</text>
                  <text x="360" y="372">1</text>
                  <text x="440" y="372">appraisal</text>
                  <text x="508" y="372">policy</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
      .-------------.
      |             | Compare Evidence
      |   Verifier  | against appraisal policy
      |             |
      '--------+----'
           ^   |
  Evidence |   | Attestation
           |   | Result
           |   v
      .----+--------.
      |             | Compare
      |   Relying   | Attestation Result
      |   Party 2   | against appraisal policy
      '--------+----'
           ^   |
  Evidence |   | Attestation
           |   | Result
           |   v
      .----+--------.               .-------------.
      |             +-------------->|             | Compare Attestation
      |   Attester  |  Attestation  |   Relying   | Result against
      |             |     Result    |   Party 1   | appraisal policy
      '-------------'               '-------------'
]]></artwork>               '-------------']]></artwork>
          </artset>
        </figure>
      </section>
    </section>
    <section anchor="rolesentities">
      <name>Roles and Entities</name>
      <t>An entity in the RATS architecture includes at least one of the roles defined
in this document.</t>
      <t>An entity can aggregate more than one role into itself, such as being both
a Verifier and a Relying Party, Party or being both a Reference Value Provider and
an Endorser.
As such, any conceptual messages (see <xref target="messages"/> for more
discussion) originating from such roles might also be combined. For example,
Reference Values might be conveyed as part of an appraisal policy if the
Verifier Owner and Reference Value Provider roles are combined. Similarly,
Reference Values might be conveyed as part of an Endorsement if the Endorser
and Reference Value Provider roles are combined.</t>
      <t>Interactions between roles aggregated into the same entity do not necessarily use the
Internet Protocol.
Such interactions might use a loopback device or other IP-based
communication between separate environments, but they do not have to.

Alternative channels to convey conceptual messages include function calls, sockets, GPIO General-Purpose Input/Output (GPIO)
interfaces, local busses, buses, or hypervisor calls. This type of conveyance is typically found
in composite devices. Most importantly, these conveyance methods are
out-of-scope
out of scope of RATS, the  RATS architecture, but they are presumed to exist in order to convey
conceptual messages appropriately between roles.</t>
      <t>In essence, an entity that combines more than one role creates and consumes
the corresponding conceptual messages as defined in this document.</t>
    </section>
    <section anchor="trustmodel">
      <name>Trust Model</name>
      <section anchor="relying-party">
        <name>Relying Party</name>
        <t>This document covers scenarios for which a Relying Party
trusts a Verifier that can appraise the trustworthiness of
information about an Attester.  Such trust
is expressed by storing one or more "trust anchors" in a secure location
known as a trust "trust anchor store.</t> store".</t>
        <t>As defined in <xref target="RFC6024"/>, "A target="RFC6024"/>:</t><blockquote>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." authoritative.</blockquote><t>
The trust anchor may be a certificate or it may be a raw public key
along with additional data if necessary necessary, such as its public key
algorithm and parameters.
In the context of this document, a trust anchor may also be a symmetric key, as
in <xref target="TCG-DICE-SIBDA"/> target="TCG-DICE-SIBDA"/>, or the symmetric mode described in
<xref target="I-D.tschofenig-rats-psa-token"/>.</t>
        <t>Thus, trusting a Verifier might be expressed by having the Relying
Party store the Verifier's key or certificate in its trust anchor store, or store.  It might also
be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is
in the Verifier's certificate path.
For example, the Relying Party can verify that the Verifier is an expected one by out-of-band establishment of key material, material combined with a protocol like TLS to communicate.
There is an assumption that the Verifier has not been compromised between the establishment of the trusted key material and the creation of the Evidence, that the Verifier has not been compromised.</t> Evidence.</t>
        <t>For a stronger level of security, the
Relying Party might require that the Verifier first provide
information about itself that the Relying Party can use to assess
the trustworthiness of the Verifier before accepting its Attestation Results.
Such a process would provide a stronger level of confidence in the correctness of
the information provided, such as a belief that the authentic Verifier has
not been compromised by malware.</t>
        <t>For example, one explicit way for a Relying Party "A" to establish
such confidence in the correctness of a Verifier "B", "B" would be for B to first act as an Attester
where A acts as a combined Verifier/Relying Party.  If A then accepts B as
trustworthy, it can choose to accept B as a Verifier for other Attesters.</t>
        <t>Similarly, the Relying Party also needs to trust the Relying Party Owner
for providing its Appraisal Policy for Attestation Results, and and,
in some scenarios scenarios, the Relying Party might even require that the
Relying Party Owner go through a remote attestation procedure with it before the Relying Party will accept
an updated policy. This can be done similarly in a manner similar to how a Relying Party
could establish trust in a Verifier as discussed above, i.e., verifying credentials against a trust anchor store
and optionally requiring Attestation Results from the Relying Party Owner.</t>
      </section>
      <section anchor="attester">
        <name>Attester</name>
        <t>In some scenarios, Evidence might contain sensitive information information, such as
Personally Identifiable Information (PII) or system identifiable information.
Thus, an Attester must trust the entities to which it conveys Evidence, Evidence to not
reveal sensitive data to unauthorized parties.

The Verifier might share this information with other
authorized parties, parties according to a governing policy that address addresses the
handling of sensitive information (potentially included in Appraisal
Policies for Evidence).
In the background-check model, Background-Check Model, this Evidence may also be revealed to Relying Party(s).</t> Parties.</t>
        <t>When Evidence contains sensitive information, an Attester
typically requires that a Verifier authenticates itself (e.g., at TLS session establishment) and might even request a remote attestation before the Attester
sends the sensitive Evidence.  This can be done by having the
Attester first act as a Verifier/Relying Party, Party and the Verifier act as its
own Attester, as discussed above.</t>
      </section>
      <section anchor="rpowner-trust">
        <name>Relying Party Owner</name>
        <t>The Relying Party Owner might also require that the
Relying Party first act as an Attester, Attester by providing Evidence that the Owner
can appraise, appraise before the Owner would give the Relying Party an updated
policy that might contain sensitive information.
In such a case, authentication or attestation in both directions might
be needed, in which case typically needed. Typically, one side's Evidence must be considered safe to
share with an untrusted entity, entity in order to bootstrap the sequence.
See <xref target="privacy-considerations"/> for more discussion.</t>
      </section>
      <section anchor="verifier">
        <name>Verifier</name>
        <t>The Verifier trusts (or more specifically, the Verifier's security
policy is written in a way that configures the Verifier to trust) a
manufacturer,
manufacturer or the manufacturer's hardware, hardware so as to be able to
appraise the trustworthiness of that manufacturer's devices.  Such trust
is expressed by storing one or more trust anchors in the Verifier's
trust anchor store.</t>
        <t>In a typical solution, a Verifier comes to trust an Attester
        indirectly by having an Endorser (such as a manufacturer) vouch for
        the Attester's ability to securely generate Evidence through
        Endorsements (see <xref target="endorsements"/>). Endorsements might
        describe the ways in which the Attester resists attack, attacks, protects secrets
        secrets, and measures Target Environments. Consequently, the
        Endorser's key material is stored in the Verifier's trust anchor store
        so that Endorsements can be authenticated and used in the Verifier's
        appraisal process.</t>
	<t>In some solutions, a Verifier might be
        configured to directly trust an Attester by having the Verifier have
        possess the Attester's key material (rather than the Endorser's) in
        its trust anchor store.</t>
        <t>Such direct trust must first be established at the time of trust anchor
store configuration either by checking with an Endorser at that
time,
time or by conducting a security analysis of the specific device.
Having the Attester directly in the trust anchor store narrows
the Verifier's trust to only specific devices rather than all devices
the Endorser might vouch for, such as all devices manufactured by the
same manufacturer in the case that the Endorser is a manufacturer.</t>
        <t>Such narrowing is often important since physical possession of a device
can also be used to conduct a number of attacks, and so a device in
a physically secure environment (such as one's own premises) may be
considered trusted trusted, whereas devices owned by others would not be.
This often results in a desire to either to have the owner run their
own Endorser that would only endorse devices one owns, owns or to use
Attesters directly in the trust anchor store.   When there are many
Attesters owned, the use of an Endorser enables better scalability.</t>
        <t>That is, a Verifier might appraise the trustworthiness of an application component, operating
system component, or service under the assumption that information
provided about it by the lower-layer firmware or software is true.
A stronger level of assurance of security comes when information can be vouched
for by hardware or by ROM code, especially if such hardware is
physically resistant to hardware tampering.
In most cases, components that have to be vouched for via Endorsements because (because no Evidence is generated about them them) are referred to as roots "roots of trust.</t> trust".</t>
        <t>The manufacturer having arranged for an Attesting Environment to be provisioned with key material with which to sign Evidence, the Verifier is then provided with
some way of verifying the signature on the Evidence.  This may be in the form of an appropriate trust anchor, anchor or the Verifier may be provided with a database of public keys (rather than certificates) or even carefully curated and secured lists of symmetric keys.</t>
        <t>The nature of how the Verifier manages to validate the signatures produced by the Attester is critical to the secure operation of a remote attestation system, system but is not the subject of standardization within this architecture.</t>
        <t>A conveyance protocol that provides authentication and integrity protection can be used
to convey Evidence that is otherwise unprotected (e.g., not signed). Appropriate conveyance of unprotected Evidence (e.g., <xref target="I-D.birkholz-rats-uccs"/>) target="I-D.ietf-rats-uccs"/>) relies on the following conveyance protocol's protection capabilities:</t>
<ol spacing="normal" type="1"><li>The type="1">

<li>The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the Attesting Environment(s) that collected Claims about the Target Environment(s).</li>
          <li>All unprotected Evidence that is conveyed is supplied exclusively by the Attesting Environment that has the key material that protects the conveyance channel</li> channel.</li>
          <li>A trusted environment protects the conveyance channel's key material material, which may depend on other Attesting Environments with equivalent strength protections.</li>
        </ol>
        <t>As illustrated in <xref target="I-D.birkholz-rats-uccs"/>, target="I-D.ietf-rats-uccs"/>, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the responsibility of vouching for the Evidence's authenticity and freshness.
If protected Evidence is generated, the Attester's Attesting Environments take on that responsibility.
In cases where unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier is capable of handling Evidence in a manner that preserves the Evidence's authenticity and freshness.
Generating and conveying unprotected Evidence always creates significant risk and the benefits of that approach have to be carefully weighed against potential drawbacks.</t>
        <t>See <xref target="security-considerations"/> for discussion on security strength.</t>
      </section>
      <section anchor="endorser-reference-value-provider-and-verifier-owner">
        <name>Endorser, Reference Value Provider, and Verifier Owner</name>
<t>In some scenarios, the Endorser, Reference Value Provider, and Verifier Owner may need to trust the Verifier
before giving the Endorsement, Reference Values, or appraisal policy to it.  This can be done
similarly in a
similar manner to how a Relying Party might establish trust in a Verifier.</t>
        <t>As discussed in <xref target="rpowner-trust"/>, authentication or attestation in both directions might be
needed, in which case typically
needed. Typically, one side's identity or
Evidence in this case must be considered safe to share with an untrusted entity, entity
in order to bootstrap the sequence.
See <xref target="privacy-considerations"/> for more discussion.</t>
      </section>
    </section>
    <section anchor="messages">
      <name>Conceptual Messages</name>
      <t><xref target="dataflow"/> illustrates the flow of conceptual messages between various roles.
This section provides additional elaboration and implementation considerations.
It is the responsibility of protocol specifications to define the actual data format
and semantics of any relevant conceptual messages.</t>
      <section anchor="evidence">
        <name>Evidence</name>
        <t>Evidence is a set of Claims about the target environment Target Environment that reveal operational
status, health, configuration configuration, or construction that have security relevance.
Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.
Claims need to be collected in a manner that is reliable such that a Target Environment cannot lie to the Attesting Environment about its trustworthiness properties.
Evidence needs to be securely associated with the target environment Target Environment
so that the Verifier cannot be tricked into accepting Claims originating
from a different environment (that may be more trustworthy).
Evidence also must be protected from an active on-path attacker who may observe,
change
change, or misdirect Evidence as it travels from the Attester to the Verifier.
The timeliness of Evidence can be captured using Claims that pinpoint the time
or interval when changes in operational status, health, and so forth occur.</t>
      </section>
      <section anchor="endorsements">
        <name>Endorsements</name>
        <t>An Endorsement is a secure statement that some entity (e.g., a
        manufacturer) vouches for the integrity of the device's various capabilities
        capabilities, such as claims Claims collection, signing, launching code,
        transitioning to other environments, storing secrets, and more.  For
        example, if the device's signing capability is in hardware, then an
        Endorsement might be a manufacturer certificate that signs a public
        key whose corresponding private key is only known inside the device's
        hardware.  Thus, when Evidence and such an Endorsement are used
        together, an appraisal procedure can be conducted based on appraisal
        policies that may not be specific to the device instance, instance but are merely
        specific to the manufacturer providing the Endorsement. For example,
        an appraisal policy might simply check that devices from a given
        manufacturer have information matching a set of Reference Values, or an Values. An appraisal policy might also have a set of more complex logic on how to
        appraise the validity of information.</t>
        <t>However, while an appraisal policy that treats all devices from a
        given manufacturer the same may be appropriate for some use cases, it
        would be inappropriate to use such an appraisal policy as the sole
        means of authorization for use cases that wish to constrain
        <em>which</em> compliant devices are considered authorized for some
        purpose.  For example, an enterprise using remote attestation for
        Network Endpoint Assessment (NEA) <xref target="RFC5209"/> may not wish to
        let every healthy laptop from the same manufacturer onto the network, but instead network.
        Instead, it may only want to let devices that it legally owns onto the
        network.  Thus, an Endorsement may be helpful information in
        authenticating information about a device, but is not necessarily
        sufficient to authorize access to resources which that may need
        device-specific information information, such as a public key for the device or
        component or user on the device.</t>
      </section>
      <section anchor="reference-values">
        <name>Reference Values</name>
        <t>Reference Values used in appraisal procedures come from a Reference
        Value Provider and are then used by the Verifier to compare to
        Evidence.  Reference Values with matching Evidence produces produce acceptable
        Claims.  Additionally, an appraisal policy may play a role in determining
        the acceptance of Claims.</t>
      </section>
      <section anchor="attestation-results">
        <name>Attestation Results</name>
        <t>Attestation Results are the input used by the Relying Party to
        decide the extent to which it will trust a particular Attester, Attester and
        allow it to access some data or perform some operation.</t>
        <t>Attestation Results may carry a boolean value indicating compliance
        or non-compliance with a Verifier's appraisal policy, policy or may carry a
        richer set of Claims about the Attester, against which the Relying
        Party applies its Appraisal Policy for Attestation Results.</t>
        <t>The quality of the Attestation Results depends upon the ability of the Verifier to evaluate the Attester.
Different Attesters have a different <em>Strength of Function</em> <xref target="strengthoffunction"/>, which results in the Attestation Results being qualitatively different in strength.</t>
        <t>An Attestation Result that indicates non-compliance can be used by an Attester (in the passport model) Passport Model) or
a Relying Party (in the background-check model) Background-Check Model) to indicate that the Attester
should not be treated as authorized and may be in need of remediation.  In some cases,
it may even indicate that the Evidence itself cannot be authenticated as being correct.</t>
        <t>By default, the Relying Party does not believe the Attester to be compliant.
Upon receipt of an authentic Attestation Result and given the Appraisal Policy for Attestation Results is satisfied,
the Attester is allowed to perform the prescribed actions or access.
The simplest such appraisal policy might authorize granting the Attester full access or control over the resources guarded by the Relying Party.
A more complex appraisal policy might involve using the information
provided in the Attestation Result to compare against expected values, values or to apply complex analysis
of other information contained in the Attestation Result.</t>
        <t>Thus, Attestation Results can contain detailed information about an
        Attester, which can include privacy sensitive information as discussed
        in <xref target="privacy-considerations"/>.  Unlike Evidence, which is
        often very device- and vendor-specific, Attestation Results can be
        vendor-neutral, if the Verifier has a way to generate vendor-agnostic
        information based on the appraisal of vendor-specific information in
        Evidence.  This allows a Relying Party's appraisal policy to be
        simpler, potentially based on standard ways of expressing the
        information, while still allowing interoperability with heterogeneous
        devices.</t>
        <t>Finally, whereas Evidence is signed by the device (or indirectly by
        a manufacturer, manufacturer if Endorsements are used), Attestation Results are
        signed by a Verifier, allowing a Relying Party to only need a trust
        relationship with one entity, entity rather than a larger set of
entities, entities
        for purposes of its appraisal policy.</t>
      </section>
      <section anchor="appraisal-policies">
        <name>Appraisal Policies</name>
        <t>The Verifier, when Verifier (when appraising Evidence, Evidence) or the Relying Party, when Party (when
appraising Attestation Results, Results) checks the values of matched Claims
against constraints specified in its appraisal policy.
Examples of such constraints checking include:</t> include the following:</t>
        <ul spacing="normal">
          <li>comparison
          <li>Comparison for equality against a Reference Value, or</li>
          <li>a Value.</li>
          <li>A check for being in a range bounded by Reference Values, or</li>
          <li>membership Values.</li>
          <li>Membership in a set of Reference Values, or</li>
          <li>a Values.</li>
          <li>A check against values in other Claims.</li>
        </ul>
        <t>Upon completing all appraisal policy constraints, the remaining Claims are accepted
as input toward determining Attestation Results, when Results (when appraising Evidence, Evidence)
or as input to a Relying Party, when Party (when appraising Attestation Results.</t> Results).</t>
      </section>
    </section>
    <section anchor="claims-encoding-formats">
      <name>Claims Encoding Formats</name>
      <t>The following diagram
      <t><xref target="clientserver"/> illustrates a relationship to which remote attestation is desired to be added:</t>
      <figure anchor="clientserver">
        <name>Typical Resource Access</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="128" width="432" viewBox="0 0 432 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,32 L 8,96" fill="none" stroke="black"/>
              <path d="M 120,32 L 120,96" fill="none" stroke="black"/>
              <path d="M 248,32 L 248,96" fill="none" stroke="black"/>
              <path d="M 352,32 L 352,96" fill="none" stroke="black"/>
              <path d="M 8,32 L 120,32" fill="none" stroke="black"/>
              <path d="M 248,32 L 352,32" fill="none" stroke="black"/>
              <path d="M 120,48 L 240,48" fill="none" stroke="black"/>
              <path d="M 8,96 L 120,96" fill="none" stroke="black"/>
              <path d="M 248,96 L 352,96" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="248,48 236,42.4 236,53.6 " fill="black" transform="rotate(0,240,48)"/>
              <g class="text">
                <text x="396" y="36">Evaluate</text>
                <text x="392" y="52">request</text>
                <text x="60" y="68">Attester</text>
                <text x="164" y="68">Access</text>
                <text x="212" y="68">some</text>
                <text x="304" y="68">Relying</text>
                <text x="392" y="68">against</text>
                <text x="188" y="84">resource</text>
                <text x="304" y="84">Party</text>
                <text x="396" y="84">security</text>
                <text x="388" y="100">policy</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
   .-------------.               .------------. Evaluate
   |             +-------------->|            | request
   |  Attester   |  Access some  |   Relying  | against
   |             |    resource   |    Party   | security
   '-------------'               '------------' policy
]]></artwork> policy]]></artwork>
        </artset>
      </figure>

      <t>In this diagram, the protocol between the Attester and a Relying Party
can be any new or existing protocol (e.g., HTTP(S), COAP(S),
ROLIE CoAP(S),
Resource-Oriented Lightweight Information Exchange (ROLIE) <xref target="RFC8322"/>,
802.1x, OPC UA <xref target="OPCUA"/>, etc.), etc.) depending on the use case.</t>
      <t>Typically, such protocols already have mechanisms for passing security information for authentication and authorization purposes.
Common formats include JWTs JSON Web Tokens (JWTs) <xref target="RFC7519"/>, CWTs <xref target="RFC8392"/>, and X.509 certificates.</t>
      <t>Retrofitting already deployed already-deployed protocols with remote attestation requires
adding RATS conceptual messages to the existing data flows. This must be
done in a way that does not degrade the security properties of the systems involved
and should use native extension mechanisms provided by the underlying
protocol. For example, if a TLS handshake is to be extended with
remote attestation capabilities, attestation Evidence may be embedded
in an ad-hoc ad hoc X.509 certificate extension (e.g., <xref target="TCG-DICE"/>), target="TCG-DICE"/>) or into a new
TLS Certificate Type (e.g., <xref target="I-D.tschofenig-tls-cwt"/>).</t>
      <t>Especially for constrained nodes nodes, there is a desire to minimize
the amount of parsing code needed in a Relying Party, Party in order to both
minimize footprint and to minimize the attack surface. While
it would be possible to embed a CWT inside a JWT, or a JWT inside an
X.509 extension, etc., there is a desire to encode the information
natively
in a format that is already supported by the Relying Party.</t>
      <t>This motivates having a common "information model" that describes
the set of remote attestation related information in an encoding-agnostic
way,
way and allowing allows multiple encoding formats (CWT, JWT, X.509, etc.)
that encode the same information into the Claims format needed by the
Relying Party.</t>
      <t>The following diagram
      <t><xref target="multievidence_diag"/> illustrates that Evidence and
      Attestation Results might be expressed via multiple potential encoding formats,
      formats so that they can be conveyed by various existing protocols.  It
      also motivates why the Verifier might also be responsible for accepting
      Evidence that encodes Claims in one format, format while issuing Attestation
      Results that encode Claims in a different format.</t>
      <figure anchor="multievidence_diag">
        <name>Multiple Attesters and Relying Parties with Different Formats</name>
        <artset>
          <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="352" width="560" viewBox="0 0 560 352" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
              <path d="M 8,112 L 8,144" fill="none" stroke="black"/>
              <path d="M 8,176 L 8,208" fill="none" stroke="black"/>
              <path d="M 8,240 L 8,272" fill="none" stroke="black"/>
              <path d="M 8,304 L 8,336" fill="none" stroke="black"/>
              <path d="M 128,48 L 128,80" fill="none" stroke="black"/>
              <path d="M 128,112 L 128,144" fill="none" stroke="black"/>
              <path d="M 128,176 L 128,208" fill="none" stroke="black"/>
              <path d="M 128,240 L 128,272" fill="none" stroke="black"/>
              <path d="M 128,304 L 128,336" fill="none" stroke="black"/>
              <path d="M 208,112 L 208,272" fill="none" stroke="black"/>
              <path d="M 232,80 L 232,104" fill="none" stroke="black"/>
              <path d="M 232,280 L 232,304" fill="none" stroke="black"/>
              <path d="M 288,80 L 288,112" fill="none" stroke="black"/>
              <path d="M 288,272 L 288,304" fill="none" stroke="black"/>
              <path d="M 312,112 L 312,272" fill="none" stroke="black"/>
              <path d="M 392,48 L 392,80" fill="none" stroke="black"/>
              <path d="M 392,112 L 392,144" fill="none" stroke="black"/>
              <path d="M 392,176 L 392,208" fill="none" stroke="black"/>
              <path d="M 392,240 L 392,272" fill="none" stroke="black"/>
              <path d="M 392,304 L 392,336" fill="none" stroke="black"/>
              <path d="M 552,48 L 552,80" fill="none" stroke="black"/>
              <path d="M 552,112 L 552,144" fill="none" stroke="black"/>
              <path d="M 552,176 L 552,208" fill="none" stroke="black"/>
              <path d="M 552,240 L 552,272" fill="none" stroke="black"/>
              <path d="M 552,304 L 552,336" fill="none" stroke="black"/>
              <path d="M 8,48 L 128,48" fill="none" stroke="black"/>
              <path d="M 392,48 L 552,48" fill="none" stroke="black"/>
              <path d="M 128,64 L 216,64" fill="none" stroke="black"/>
              <path d="M 304,64 L 384,64" fill="none" stroke="black"/>
              <path d="M 8,80 L 128,80" fill="none" stroke="black"/>
              <path d="M 392,80 L 552,80" fill="none" stroke="black"/>
              <path d="M 8,112 L 128,112" fill="none" stroke="black"/>
              <path d="M 208,112 L 312,112" fill="none" stroke="black"/>
              <path d="M 392,112 L 552,112" fill="none" stroke="black"/>
              <path d="M 128,128 L 200,128" fill="none" stroke="black"/>
              <path d="M 312,128 L 384,128" fill="none" stroke="black"/>
              <path d="M 8,144 L 128,144" fill="none" stroke="black"/>
              <path d="M 392,144 L 552,144" fill="none" stroke="black"/>
              <path d="M 8,176 L 128,176" fill="none" stroke="black"/>
              <path d="M 392,176 L 552,176" fill="none" stroke="black"/>
              <path d="M 128,192 L 200,192" fill="none" stroke="black"/>
              <path d="M 312,192 L 384,192" fill="none" stroke="black"/>
              <path d="M 8,208 L 128,208" fill="none" stroke="black"/>
              <path d="M 392,208 L 552,208" fill="none" stroke="black"/>
              <path d="M 8,240 L 128,240" fill="none" stroke="black"/>
              <path d="M 392,240 L 552,240" fill="none" stroke="black"/>
              <path d="M 128,256 L 200,256" fill="none" stroke="black"/>
              <path d="M 312,256 L 384,256" fill="none" stroke="black"/>
              <path d="M 8,272 L 128,272" fill="none" stroke="black"/>
              <path d="M 208,272 L 312,272" fill="none" stroke="black"/>
              <path d="M 392,272 L 552,272" fill="none" stroke="black"/>
              <path d="M 8,304 L 128,304" fill="none" stroke="black"/>
              <path d="M 392,304 L 552,304" fill="none" stroke="black"/>
              <path d="M 128,320 L 216,320" fill="none" stroke="black"/>
              <path d="M 304,320 L 384,320" fill="none" stroke="black"/>
              <path d="M 8,336 L 128,336" fill="none" stroke="black"/>
              <path d="M 392,336 L 552,336" fill="none" stroke="black"/>
              <path d="M 216,64 C 224.83064,64 232,71.16936 232,80" fill="none" stroke="black"/>
              <path d="M 304,64 C 295.16936,64 288,71.16936 288,80" fill="none" stroke="black"/>
              <path d="M 216,320 C 224.83064,320 232,312.83064 232,304" fill="none" stroke="black"/>
              <path d="M 304,320 C 295.16936,320 288,312.83064 288,304" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="392,320 380,314.4 380,325.6 " fill="black" transform="rotate(0,384,320)"/>
              <polygon class="arrowhead" points="392,256 380,250.4 380,261.6 " fill="black" transform="rotate(0,384,256)"/>
              <polygon class="arrowhead" points="392,192 380,186.4 380,197.6 " fill="black" transform="rotate(0,384,192)"/>
              <polygon class="arrowhead" points="392,128 380,122.4 380,133.6 " fill="black" transform="rotate(0,384,128)"/>
              <polygon class="arrowhead" points="392,64 380,58.4 380,69.6 " fill="black" transform="rotate(0,384,64)"/>
              <polygon class="arrowhead" points="240,280 228,274.4 228,285.6 " fill="black" transform="rotate(270,232,280)"/>
              <polygon class="arrowhead" points="240,104 228,98.4 228,109.6 " fill="black" transform="rotate(90,232,104)"/>
              <polygon class="arrowhead" points="208,256 196,250.4 196,261.6 " fill="black" transform="rotate(0,200,256)"/>
              <polygon class="arrowhead" points="208,192 196,186.4 196,197.6 " fill="black" transform="rotate(0,200,192)"/>
              <polygon class="arrowhead" points="208,128 196,122.4 196,133.6 " fill="black" transform="rotate(0,200,128)"/>
              <g class="text">
                <text x="164" y="36">Evidence</text>
                <text x="328" y="36">Attestation</text>
                <text x="408" y="36">Results</text>
                <text x="168" y="52">CWT</text>
                <text x="352" y="52">CWT</text>
                <text x="68" y="68">Attester-A</text>
                <text x="440" y="68">Relying</text>
                <text x="496" y="68">Party</text>
                <text x="528" y="68">V</text>
                <text x="168" y="116">JWT</text>
                <text x="352" y="116">JWT</text>
                <text x="68" y="132">Attester-B</text>
                <text x="440" y="132">Relying</text>
                <text x="496" y="132">Party</text>
                <text x="528" y="132">W</text>
                <text x="168" y="180">X.509</text>
                <text x="352" y="180">X.509</text>
                <text x="68" y="196">Attester-C</text>
                <text x="260" y="196">Verifier</text>
                <text x="440" y="196">Relying</text>
                <text x="496" y="196">Party</text>
                <text x="528" y="196">X</text>
                <text x="168" y="244">TPM</text>
                <text x="352" y="244">TPM</text>
                <text x="68" y="260">Attester-D</text>
                <text x="440" y="260">Relying</text>
                <text x="496" y="260">Party</text>
                <text x="528" y="260">Y</text>
                <text x="168" y="308">other</text>
                <text x="352" y="308">other</text>
                <text x="68" y="324">Attester-E</text>
                <text x="440" y="324">Relying</text>
                <text x="496" y="324">Party</text>
                <text x="528" y="324">Z</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
                Evidence           Attestation Results
.--------------.   CWT                    CWT   .-------------------.
|  Attester-A  +-----------.        .---------->|  Relying Party V  |
'--------------'            |      |            `-------------------'
                            v      |
.--------------.   JWT   .---------+--.   JWT   .-------------------.
|  Attester-B  +-------->|            +-------->|  Relying Party W  |
'--------------'         |            |         `-------------------'
                         |            |
.--------------.  X.509  |            |  X.509  .-------------------.
|  Attester-C  +-------->|  Verifier  +-------->|  Relying Party X  |
'--------------'         |            |         `-------------------'
                         |            |
.--------------.   TPM   |            |   TPM   .-------------------.
|  Attester-D  +-------->|            +-------->|  Relying Party Y  |
'--------------'         '---------+--'         `-------------------'
                            ^      |
.--------------.  other     |      |     other  .-------------------.
|  Attester-E  +-----------'        '---------->|  Relying Party Z  |
'--------------'                                `-------------------'
]]></artwork>                                `-------------------']]></artwork>
        </artset>
      </figure>
    </section>
    <section anchor="freshness">
      <name>Freshness</name>
      <t>A Verifier or Relying Party might need to learn the point in time
(i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims can be considered fresh,
meaning they still reflect the latest state of the Attester, and that any
Attestation Result was generated using the latest Appraisal Policy for Evidence.</t> Evidence, Endorsements, and Reference Values.</t>
      <t>This section provides a number of details.
It
However, it does not however define any protocol formats, formats and the interactions shown are abstract.
This section is intended for those creating protocols and solutions to understand the options available to ensure freshness.
The way in which freshness is provisioned in a protocol is an architectural decision.
Provisioning of freshness has an impact on the number of needed round trips in a protocol, and therefore protocol; therefore, it must be made very early in the design.
Different decisions will have significant impacts on resulting interoperability,
which is why this section goes into sufficient detail such that choices in freshness will be compatible across interacting protocols, such as depicted in <xref target="multievidence_diag"/>.</t>
      <t>Freshness is assessed based on the Appraisal Policy for Evidence or
      Attestation Results that compares the estimated epoch against an
      "expiry" threshold defined locally to that policy.  There is, however,
      always a race condition possible in that the state of the Attester, Attester and
      the appraisal policies might change immediately after the Evidence or
      Attestation Result was generated.  The goal is merely to narrow their
      recentness to something the Verifier (for Evidence) or Relying Party
      (for Attestation Result) is willing to accept.  Some flexibility on the
      freshness requirement is a key component for enabling caching and reuse
      of both Evidence and Attestation Results, which is especially valuable
      in cases where their computation uses a substantial part of the resource
      budget (e.g., energy in constrained devices).</t>
      <t>There are three common approaches for determining the epoch of Evidence or an
Attestation Result.</t>
      <section anchor="explicit-timekeeping-using-synchronized-clocks">
        <name>Explicit Timekeeping using Using Synchronized Clocks</name>
        <t>The first approach is to rely on synchronized and trustworthy clocks, clocks and
include a signed timestamp (see <xref target="I-D.birkholz-rats-tuda"/>) along with the
Claims in the Evidence or Attestation Result.  Timestamps can also be added on a
per-Claim basis to distinguish the time of generation of Evidence or Attestation
Result from the time that a specific Claim was generated.  The clock's
trustworthiness can generally be established via Endorsements and typically requires additional Claims about the signer's time
synchronization mechanism.</t>
        <t>In some use cases, however,
        <t>However, a trustworthy clock might not be available. available in some use cases. For
example, in many Trusted Execution Environments (TEEs) TEEs today, a clock is only
available outside the TEE and so TEE; thus, it cannot be trusted by the TEE.</t>
      </section>
      <section anchor="implicit-timekeeping-using-nonces">
        <name>Implicit Timekeeping using Using Nonces</name> <t>A second approach
        places the onus of timekeeping solely on the Verifier (for Evidence)
        or the Relying Party (for Attestation Results), and Results). For example, this
        approach might be suitable, for example, suitable in case the Attester does not have a
        trustworthy clock or time synchronization is otherwise impaired.
	In
        this approach, a non-predictable an unpredictable nonce is sent by the appraising entity,
        entity and the nonce is then signed and included along with the Claims
        in the Evidence or Attestation Result.  After checking that the sent
        and received nonces are the same, the appraising entity knows that the
        Claims were signed after the nonce was generated.  This allows
        associating a "rough" epoch to the Evidence or Attestation Result.  In
        this case case, the epoch is said to be rough because:</t>
        <ul spacing="normal">
          <li>The epoch applies to the entire Claim set instead of a more granular
association, and</li>
          <li>The time between the creation of Claims and the collection of Claims is
indistinguishable.</li>
        </ul>
      </section>
      <section anchor="epochfreshness">
        <name>Implicit Timekeeping using Using Epoch IDs</name>
        <t>A third approach relies on having epoch identifiers (or "IDs") (IDs)
periodically sent to both the sender and receiver of Evidence or
Attestation Results by some "Epoch "epoch ID Distributor".</t> distributor".</t>
        <t>Epoch IDs are different from nonces as they can be used more than once and
can even be used by more than one entity at the same time.
Epoch IDs are different from timestamps as they do not have to convey information about a point in time, i.e., they are not necessarily monotonically increasing integers.</t>
        <t>Like the nonce approach, this allows associating a "rough" epoch without
requiring a trustworthy clock or time synchronization in order to generate or
appraise the freshness of Evidence or Attestation Results.  Only the
Epoch
epoch ID Distributor distributor requires access to a clock so it can periodically send
new epoch IDs.</t>
        <t>The most recent epoch ID is included in the produced Evidence or Attestation
Results, and the appraising entity can compare the epoch ID in received
Evidence or Attestation Results against the latest epoch ID it received from
the Epoch epoch ID Distributor distributor to determine if it is within the current epoch.
An actual solution also needs to take into account race conditions
when transitioning to a new epoch, such as by using a counter signed
by the Epoch epoch ID Distributor distributor as the epoch ID, or by including both the current and
previous epoch IDs in messages and/or checks, checks by requiring retries
in case of mismatching epoch IDs, or by buffering incoming messages
that might be associated with an epoch ID that the receiver has not yet
obtained.</t>
        <t>More generally, in order to prevent an appraising entity from generating false
negatives (e.g., discarding Evidence that is deemed stale even if it is
not), the appraising entity should keep an "epoch window" consisting of the
most recently received epoch IDs.  The depth of such epoch window is directly
proportional to the maximum network propagation delay between the first to receive the epoch ID and the last to receive the epoch ID, ID and it is inversely proportional to the epoch duration.
The appraising entity shall compare the
epoch ID carried in the received Evidence or Attestation Result with the epoch IDs
in its epoch window to find a suitable match.</t>
        <t>Whereas the nonce approach typically requires the appraising entity
to keep state for each nonce generated, the epoch ID approach minimizes
the state kept to be independent of the number of Attesters or Verifiers
from which it expects to receive Evidence or Attestation Results, Results as long
as all use the same Epoch epoch ID Distributor.</t> distributor.</t>
      </section>
      <section anchor="discussion">
        <name>Discussion</name>
        <t>Implicit and explicit timekeeping can be combined into hybrid mechanisms.
For example, if clocks exist within the Attesting Environment and are considered trustworthy (tamper-proof) but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved peers, peers followed by any number of timestamp
based exchanges.</t>
        <t>It is important to note that the actual values in Claims might have been
generated long before the Claims are signed.  If so, it is the signer's
responsibility to ensure that the values are still correct fresh when they are
signed.  For example, values generated at boot time might have been saved to
secure storage until network connectivity is established to the remote Verifier
and a nonce is obtained.</t>
        <t>A more detailed discussion with examples appears in <xref target="time-considerations"/>.</t>
        <t>For a discussion on the security of epoch IDs see <xref target="epochids-sec"/>.</t>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>The conveyance of Evidence and the resulting Attestation Results
reveal a great deal of information about the internal state of a
device as well as potentially any users of the device.</t>
      <t>In many cases, the whole point of attestation procedures is
to provide reliable information about the type of the device and the
firmware/software that the device is running.</t>
      <t>This information might be particularly interesting to many attackers.
For example, knowing that a device is
running a weak version of firmware provides a way to aim attacks better.</t>
      <t>In some circumstances, if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could potentially provide an attacker with insight into defensive mitigations.
It is recommended that attention be paid to confidentiality of such information.</t>
      <t>Additionally, many Claims in Evidence, many Claims in Attestation Results, and appraisal policies potentially contain Personally Identifying Information (PII) depending on the end-to-end use case of
the remote attestation procedure.
Remote attestation that includes containers and applications, e.g., a blood pressure monitor, may further
reveal details about specific systems or users.</t>
      <t>In some cases, an attacker may be able to make inferences about the contents of Evidence
from the resulting effects or timing of the processing.
For example, an attacker might be able to infer the value of specific Claims if it knew that only certain values were accepted by the Relying Party.</t>
      <t>Conceptual messages (see <xref target="messages"/>) carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.
If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections.</t>
      <t>As Evidence might contain sensitive or confidential information,
Attesters are responsible for only sending such Evidence to trusted
Verifiers.
Some Attesters might want a stronger level of assurance of
the trustworthiness of a Verifier before sending Evidence to it.
In such cases,
an Attester can first act as a Relying Party and ask for the Verifier's own
Attestation Result, and appraising Result. Appraising it just as a Relying Party would appraise
an Attestation Result for any other purpose.</t>
      <t>Another approach to deal with Evidence is to remove PII from the Evidence
while still being able to verify that the Attester is one of a large set.
This approach is often called "Direct Anonymous Attestation".  See
Section 6.2 of <xref target="CCC-DeepDive"/> section 6.2 and <xref target="I-D.ietf-rats-daa"/> for more discussion.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document provides an architecture for doing remote attestation.
No specific wire protocol is documented here.
Without a specific proposal to compare against, it is impossible to know if the security threats listed below have been mitigated well.</t>
      <t>The security considerations below should be read as being essentially being, essentially, requirements against realizations of the RATS Architecture. architecture.
Some threats apply to protocols, protocols and some are against implementations (code), (code) and some threats are against physical infrastructure (such as factories).</t>
      <t>The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester.</t>
      <section anchor="attester-and-attestation-key-protection">
        <name>Attester and Attestation Key Protection</name>
        <t>Implementers need to pay close attention to the protection of the Attester and the manufacturing processes for provisioning attestation key material. If either of these are compromised, intended levels of assurance for RATS  remote attestation procedures are compromised because attackers can forge Evidence or manipulate the Attesting Environment.
For example, a Target Environment should not be able to tamper with the
Attesting Environment that measures it, it by isolating the two environments
from each other in some way.</t>
        <t>Remote attestation applies to use cases with a range of security requirements, so the requirements. The protections discussed here range from low to high security where security: low security may be limited to application or process isolation by the device's operating system, system and high security may involve specialized hardware to defend against physical attacks on a chip.</t>
        <section anchor="on-device-attester-and-key-protection">
          <name>On-Device Attester and Key Protection</name>
          <t>It is assumed that an Attesting Environment is sufficiently isolated from the
Target Environment it collects Claims about and that it signs the resulting Claims set with an attestation
key,
key so that the Target Environment cannot forge Evidence about itself.  Such
an isolated environment might be provided by a process, a dedicated chip,
a TEE, a virtual machine, or another secure mode of operation.
The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly. Confidentiality protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence.</t>
          <t>In many cases cases, the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Environments, Environments to prevent creating forged Evidence.
Some common examples include the user of a mobile phone or FIDO authenticator.</t>
          <t>Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, system and restricted access to root or system privileges. In contrast, For for really simple single-use devices that don't use a protected mode operating system, like system (like a Bluetooth speaker, speaker), the only factual isolation might be the sturdy housing of the device.</t>
          <t>Measures for a moderately protected system could include a special restricted operating environment, such as a TEE. In this case, only security-oriented software has access to the Attester and key material.</t>
          <t>Measures for a highly protected system could include specialized hardware that is used to provide protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF RF, and power side channel attacks.</t>
        </section>
        <section anchor="attestation-key-provisioning-processes">
          <name>Attestation Key Provisioning Processes</name>
          <t>Attestation key provisioning is the process that occurs in the factory or elsewhere to establish signing key material on the device and the validation key material off the device.
Sometimes
Sometimes, this procedure is referred to as personalization "personalization" or customization.</t> "customization".</t>
          <t>When generating keys off-device in the factory or in the device, the use of
a Cryptographically Strong Sequence cryptographically strong sequence (<xref section="6.2" sectionFormat="comma" target="RFC4086"/>) needs consideration.</t>
          <section anchor="off-device-key-generation">
            <name>Off-Device Key Generation</name>
            <t>One way to provision key material is to first generate it external to the device and then copy the key onto the device.
In this case, confidentiality protection of the generator, as well as for generator and the path over which the key is provisioned, provisioned is necessary.
The manufacturer needs to take care to protect corresponding key material with measures appropriate for its value.</t>
            <t>The degree of protection afforded to this key material can vary by the intended
function of the device and the specific practices of the device manufacturer or integrator.
The confidentiality protection is fundamentally based upon some amount of physical protection: while protection. While encryption is often used to provide confidentiality when a key is conveyed across a factory, factory where the attestation key is created or applied, it must be available in an unencrypted form.
The physical protection can therefore vary from situations where the key is unencrypted only within carefully controlled secure enclaves within silicon, silicon to situations where an entire facility is considered secure, secure
by the simple means of locked doors and limited access.</t>
            <t>The cryptography that is used to enable confidentiality protection of the attestation key comes with its own requirements to be secured.
This results in recursive problems, as the key material used to provision attestation keys must again somehow have been provisioned securely beforehand (requiring an additional level of protection, protection and so on).</t>
            <t>Commonly, a combination of some physical security measures and some cryptographic measures are used to establish confidentiality protection.</t>
          </section>
          <section anchor="on-device-key-generation">
            <name>On-Device Key Generation</name>
            <t>When key material is generated within a device and the secret part of it never leaves the device,
then the problem may lessen.
 For public-key cryptography, it is, by definition, is not necessary to maintain confidentiality
 of the public key: however key.  However, integrity of the chain of custody of the
 public key is necessary in order to avoid attacks where an attacker is able
 to get a key they control endorsed.</t> endorsed that the attacker controls.</t>
            <t>To summarize: summarize, attestation key provisioning must ensure that only valid attestation key material is established in Attesters.</t>
          </section>
        </section>
      </section>
      <section anchor="conceptual-message-protection">
        <name>Conceptual Message Protection</name>
        <t>Any solution that conveys information in any conceptual message (see <xref target="messages"/>)
must support end-to-end integrity protection
and replay attack prevention, and prevention. It often also needs to support additional
security properties, including:</t>
        <ul spacing="normal">
          <li>end-to-end encryption,</li>
          <li>denial of service
          <li>denial-of-service protection,</li>
          <li>authentication,</li>
          <li>auditing,</li>
          <li>fine grained
          <li>fine-grained access controls, and</li>
          <li>logging.</li>
        </ul>
        <t><xref target="freshness"/> discusses ways in which freshness can be used in this
architecture to protect against replay attacks.</t>
        <t>To assess the security provided by a particular appraisal policy, it
is important to understand the strength of the root of trust, e.g.,
whether it is mutable software, software or firmware that is read-only after
boot,
boot or immutable hardware/ROM.</t>
        <t>It is also important that the appraisal policy was itself obtained securely. securely itself.
If an attacker can configure or modify appraisal policies, policies and Endorsements or Reference Values for a Relying Party or for a Verifier, then integrity of the process is compromised.</t>
        <t>Security protections in the RATS architecture may be applied at different layers, whether by a conveyance protocol, protocol or an information encoding format.
This architecture expects conceptual messages to be end-to-end protected based on the role interaction context.
For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.</t>
        <t>The RATS architecture allows for an entity to function in multiple roles
(<xref target="rolesentities"/>) and for composite devices (<xref target="compositedevice"/>).
Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still hold despite the lack of separation, separation and that emergent risk is not introduced.  The specifics of this evaluation will depend on the implementation and the use case and hence is case; hence, they are out of scope for this document.
Isolation mechanisms in software or hardware that separate Attesting Environments and Target Environments <xref target="twotypes"/> (<xref target="twotypes"/>) can support an implementer's evaluation and resulting design decisions.</t>
      </section>
      <section anchor="epochids-sec">
        <name>Epoch ID-based Attestation</name>
        <name>Attestation Based on Epoch ID</name>
        <t>Epoch IDs, described in <xref target="epochfreshness"/>, can be tampered with, replayed, dropped, delayed, and
reordered by an attacker.</t>
        <t>An attacker could be either be external or belong to the distribution group, for group (for
example, if one of the Attester entities have been compromised.</t> compromised).</t>
        <t>An attacker who is able to tamper with epoch IDs can potentially lock all the
participants in a certain epoch of choice forever, effectively freezing time.
This is problematic since it destroys the ability to ascertain freshness of
Evidence and Attestation Results.</t>
        <t>To mitigate this threat, the transport should be at least integrity protected
and provide origin authentication.</t>
        <t>Selective dropping of epoch IDs is equivalent to pinning the victim node to a past epoch.
An attacker could drop epoch IDs to only some entities and not others, which will typically result in a denial of service due to the permanent staleness of the Attestation Result or Evidence.</t>
        <t>Delaying or reordering epoch IDs is equivalent to manipulating the victim's
timeline at will.  This ability could be used by a malicious actor (e.g., a
compromised router) to mount a confusion attack where, for attack. For example, a Verifier
is
can be tricked into accepting Evidence coming from a past epoch as fresh, while while, in
the meantime meantime, the Attester has been compromised.</t>
        <t>Reordering and dropping attacks are mitigated if the transport provides the ability to detect reordering and drop.
However, the delay attack described above can't be thwarted in this manner.</t>
      </section>
      <section anchor="trust-anchor-protection">
        <name>Trust Anchor Protection</name>
        <t>As noted in <xref target="trustmodel"/>, Verifiers and Relying Parties have trust anchor stores
that must be secured.
<xref target="RFC6024"/> contains more discussion of trust anchor store requirements
for protecting public keys.
Section 6 of <xref target="NIST-800-57-p1"/> contains a comprehensive treatment of the
topic, including the protection of symmetric key material.
Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification.
Additionally, if the trust anchor is a symmetric key, the trust anchor store must
not allow unauthorized read.</t>
        <t>If certificates are used as trust anchors, Verifiers and Relying Parties are also
responsible for validating the entire certificate path up to the trust anchor,
which includes checking for certificate revocation.
For an example of such a proceedure procedure, see Section 6 of <xref target="RFC5280"/>.</t> target="RFC5280" sectionFormat="of" section="6"/>.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document does not require any actions by IANA.</t>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Special thanks go to
Joerg Borchert,
Nancy Cam-Winget,
Jessica Fitzgerald-McKay,
Diego Lopez,
Laurence Lundblade,
Paul Rowe,
Hannes Tschofenig,
Frank Xia,
and
David Wooten.</t>
    </section>
    <section anchor="notable-contributions">
      <name>Notable Contributions</name>
      <t>Thomas Hardjono created initial versions of the terminology section in collaboration with Ned Smith.
Eric Voit provided the conceptual separation between Attestation Provision Flows and Attestation Evidence Flows.
Monty Wisemen created the content structure of the first three architecture drafts.
Carsten Bormann provided many of the motivational building blocks with respect to the Internet Threat Model.</t>
      <t>Peter Loscocco contributed critical review feedback as part of the weekly design team meetings that added precision and depth to several sections.</t> has no IANA actions.</t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.birkholz-rats-tuda" to="RATS-TUDA"/>
<displayreference target="I-D.ietf-rats-uccs" to="RATS-UCCS"/>
<displayreference target="I-D.ietf-teep-architecture" to="TEEP-ARCH"/>
<displayreference target="I-D.ietf-rats-daa" to="RATS-DAA"/>
<displayreference target="I-D.tschofenig-rats-psa-token" to="RATS-PSA-TOKEN"/>
<displayreference target="I-D.tschofenig-tls-cwt" to="TLS-CWT"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC7519">
          <front>
            <title>JSON Web Token (JWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones">
              <organization/>
            </author>
            <author fullname="J. Bradley" initials="J." surname="Bradley">
              <organization/>
            </author>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura">
              <organization/>
            </author>
            <date month="May" year="2015"/>
            <abstract>
              <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7519"/>
          <seriesInfo name="DOI" value="10.17487/RFC7519"/>
        </reference>
        <reference anchor="RFC8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones">
              <organization/>
            </author>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem">
              <organization/>
            </author>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman">
              <organization/>
            </author>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
              <organization/>
            </author>
            <date month="May" year="2018"/>
            <abstract>
              <t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties.  The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection.  A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value.  CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8392"/>
          <seriesInfo name="DOI" value="10.17487/RFC8392"/>
        </reference>
        <reference anchor="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 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>

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

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="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 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 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>
        <reference anchor="RFC5209">
          <front>
            <title>Network Endpoint Assessment (NEA): Overview and Requirements</title>
            <author fullname="P. Sangster" initials="P." surname="Sangster">
              <organization/>
            </author>
            <author fullname="H. Khosravi" initials="H." surname="Khosravi">
              <organization/>
            </author>
            <author fullname="M. Mani" initials="M." surname="Mani">
              <organization/>
            </author>
            <author fullname="K. Narayan" initials="K." surname="Narayan">
              <organization/>
            </author>
            <author fullname="J. Tardo" initials="J." surname="Tardo">
              <organization/>
            </author>
            <date month="June" year="2008"/>
            <abstract>
              <t>This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model.  NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system.  This may take place during the request for network access and/or subsequently at any time while connected to the network.  The learned posture information can then be applied to a variety of compliance-oriented decisions.  The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software.  In order to provide context for the requirements, a reference model and terminology are introduced.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5209"/>
          <seriesInfo name="DOI" value="10.17487/RFC5209"/>
        </reference>
        <reference anchor="RFC8322">
          <front>
            <title>Resource-Oriented Lightweight Information Exchange (ROLIE)</title>
            <author fullname="J. Field" initials="J." surname="Field">
              <organization/>
            </author>
            <author fullname="S. Banghart" initials="S." surname="Banghart">
              <organization/>
            </author>
            <author fullname="D. Waltermire" initials="D." surname="Waltermire">
              <organization/>
            </author>
            <date month="February" year="2018"/>
            <abstract>
              <t>This document defines a resource-oriented approach for security automation information publication, discovery, and sharing.  Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories.  This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8322"/>
          <seriesInfo name="DOI" value="10.17487/RFC8322"/>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8322.xml"/>

        <reference anchor="OPCUA" target="https://opcfoundation.org/developer-tools/specifications-unified-architecture/part-2-security-model/">
          <front>
            <title>OPC Unified Architecture Specification, Part 2: Security Model, Release 1.03</title>
            <author>
              <organization>OPC Foundation</organization>
            </author>
            <date year="2015" month="November" day="25"/> month="November"/>
          </front>
          <seriesInfo name="OPC 10000-2" value=""/>
        </reference>

        <reference anchor="TCG-DICE" target="https://trustedcomputinggroup.org/wp-content/uploads/DICE-Certificate-Profiles-r01_3june2020-1.pdf"> target="https://trustedcomputinggroup.org/wp-content/uploads/DICE-Attestation-Architecture-r23-final.pdf">
          <front>
            <title>DICE Certificate Profiles</title> Attestation Architecture</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date>n.d.</date>
            <date year="2021" month="March"/>
          </front>
	  <refcontent>Version 1.00</refcontent>
	  <refcontent>Revision 0.23</refcontent>

        </reference>
        <reference anchor="I-D.birkholz-rats-tuda">
          <front>
            <title>Time-Based Uni-Directional Attestation</title>
            <author fullname="Andreas Fuchs" initials="A." surname="Fuchs">
              <organization>Fraunhofer Institute for Secure Information Technology</organization>
            </author>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer Institute for Secure Information Technology</organization>
            </author>
            <author fullname="Ira McDonald" initials="I." surname="McDonald">
              <organization>High North Inc</organization>
            </author>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <date day="10" month="July" year="2022"/>
            <abstract>
              <t>   This document defines the method and bindings used to convey Evidence
   via Time-based Uni-Directional Attestation (TUDA) in Remote
   ATtestation procedureS (RATS).  TUDA does not require a challenge-
   response handshake and thereby does not rely on the conveyance of a
   nonce to prove freshness of remote attestation Evidence.  TUDA
   enables the creation of Secure Audit Logs that can constitute
   believable Evidence about both current and past operational states of
   an Attester.  In TUDA, RATS entities require access to a Handle
   Distributor to which a trustable and synchronized time-source is
   available.  The Handle Distributor takes on the role of a Time Stamp
   Authority (TSA) to distribute Handles incorporating Time Stamp Tokens
   (TST) to

<!-- [I-D.birkholz-rats-tuda] IESG state I-D Exists -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.birkholz-rats-tuda.xml"/>

<!-- [I-D.birkholz-rats-uccs] Replaced by [I-D.ietf-rats-uccs]; the RATS entities.  RATS require an Attesting Environment
   that generates believable Evidence.  While a TPM latter is used as the
   corresponding root of trust also referenced in this specification, any other type of
   root of trust can be used with TUDA.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-birkholz-rats-tuda-07"/>
        </reference>
        <reference anchor="I-D.birkholz-rats-uccs">
          <front>
            <title>A CBOR Tag for Unprotected CWT Claims Sets</title>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donoghue">
              <organization>Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universitaet Bremen TZI</organization>
            </author>
            <date day="8" month="March" year="2021"/>
            <abstract>
              <t>   CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the
   protection afforded by wrapping them into COSE, as is required for a
   true CWT.  This specification defines a CBOR tag for such unprotected
   CWT Claims Sets (UCCS) and discusses conditions for its proper use.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-birkholz-rats-uccs-03"/>
        </reference>
        <reference anchor="I-D.ietf-teep-architecture">
          <front>
            <title>Trusted Execution Environment Provisioning (TEEP) Architecture</title>
            <author fullname="Mingliang Pei" initials="M." surname="Pei">
              <organization>Broadcom</organization>
            </author>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>Arm Limited</organization>
            </author>
            <author fullname="Dave Thaler" initials="D." surname="Thaler">
              <organization>Microsoft</organization>
            </author>
            <author fullname="Dave Wheeler" initials="D. M." surname="Wheeler">
              <organization>Amazon</organization>
            </author>
            <date day="11" month="July" year="2022"/>
            <abstract>
              <t>   A Trusted Execution Environment (TEE) is an environment that enforces
   that any code within that environment cannot be tampered with, and
   that any data used by such code cannot be read or tampered with by
   any code outside that environment.  This architecture document
   motivates the design and standardization of a protocol for managing
   the lifecycle of trusted applications running inside such a TEE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teep-architecture-18"/>
        </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) document.-->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rats-uccs.xml"/>

<!-- [I-D.ietf-teep-architecture] IESG state Approved-announcement 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"/>
        </reference> be sent::Revised I-D Needed -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-teep-architecture.xml"/>

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

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

        <reference anchor="TCGarch" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf">
          <front>
            <title>Trusted Platform Module Library - Library, Part 1: Architecture</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2019" month="November" day="08"/> month="November"/>
          </front>
        </reference>

        <reference anchor="WebAuthN" target="https://www.w3.org/TR/webauthn-1/">
          <front>
            <title>Web Authentication: An API for accessing Public Key Credentials</title> Credentials Level 1</title>
            <author>
              <organization>W3C</organization>
            </author>
            <date>n.d.</date>
            <date year="2019" month="March"/>
          </front>
        </reference>

        <reference anchor="CTAP" target="https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html">
          <front>
            <title>Client to Authenticator Protocol</title> Protocol (CTAP)</title>
            <author>
              <organization>FIDO Alliance</organization>
            </author>
            <date>n.d.</date>
            <date year="2018" month="February"/>
          </front>
        </reference>

        <reference anchor="strengthoffunction" target="https://csrc.nist.gov/glossary/term/strength_of_function">
          <front>
            <title>Strength of Function</title>
            <author>
              <organization>NISC</organization>
              <organization>NIST</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

<reference anchor="CCC-DeepDive" target="https://confidentialcomputing.io/whitepaper-02-latest"> target="https://confidentialcomputing.io/white-papers-reports">
          <front>
            <title>Confidential Computing Deep Dive</title>
            <title>A Technical Analysis of Confidential Computing</title>
            <author>
              <organization>Confidential Computing Consortium</organization>
            </author>
            <date>n.d.</date>
            <date year="2022" month="November"/>
          </front>
	  <refcontent>Version 1.3</refcontent>
        </reference>

        <reference anchor="TCG-DICE-SIBDA" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_DICE_SymIDAttest_v1_r0p94_pubrev.pdf"> target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_DICE_SymIDAttest_v1_r0p95_pub-1.pdf">
          <front>
            <title>Symmetric Identity Based Device Attestation for DICE</title> Attestation</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2019" month="July" day="24"/> year="2020" month="January"/>
          </front>
	  <refcontent>Version 1.0</refcontent>
	  <refcontent>Revision 0.95</refcontent>
        </reference>

        <reference anchor="NIST-800-57-p1" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf">
          <front>
            <title>Recommendation for Key Managemement: Management: Part 1 - General</title>
	    <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
            <author initials="E." surname="Barker" fullname="Elaine Barker">
              <organization>NIST</organization>
            </author>
            <date year="2020" month="May"/>
          </front>
        </reference>
        <reference anchor="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.tschofenig-rats-psa-token">
          <front>
            <title>Arm's Platform Security Architecture (PSA) Attestation Token</title>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>Arm Limited</organization>
            </author>
            <author fullname="Simon Frost" initials="S." surname="Frost">
              <organization>Arm Limited</organization>
            </author>
            <author fullname="Mathias Brossard" initials="M." surname="Brossard">
              <organization>Arm Limited</organization>
            </author>
            <author fullname="Adrian L. Shaw" initials="A. L." surname="Shaw">
              <organization>HP Labs</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Arm Limited</organization>
            </author>
            <date day="6" month="September" year="2022"/>
            <abstract>
              <t>   The Platform Security Architecture (PSA) is a family of hardware and
   firmware security specifications, as well as open-source reference
   implementations, to help device makers and chip manufacturers build
   best-practice security into products.  Devices that are PSA compliant
   are able to produce attestation tokens as described in this memo,
   which are the basis for a number of different protocols, including
   secure provisioning and network access control.  This document
   specifies the PSA attestation token structure and semantics.

   The PSA attestation token is a profiled Entity Attestation Token
   (EAT).

   This specification describes what claims are used in an attestation
   token generated by PSA compliant systems, how these claims get
   serialized to the wire, and how they are cryptographically protected.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-token-10"/>
        </reference>
        <reference anchor="I-D.tschofenig-tls-cwt">
          <front>
            <title>Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>Arm Limited</organization>
            </author>
            <author fullname="Mathias Brossard" initials="M." surname="Brossard">
              <organization>Arm Limited</organization>
            </author>
            <date day="13" month="July" year="2020"/>
            <abstract>
              <t>   The TLS protocol supports different credentials, including pre-shared
   keys, raw public keys, and X.509 certificates.  For use with public
   key cryptography developers have to decide between raw public keys,
   which require out-of-band agreement and full-fletched X.509
   certificates.  For devices where the reduction of code size is
   important it is desirable to minimize the use of X.509-related
   libraries.  With the CBOR Web Token (CWT) a structure has been
   defined that allows CBOR-encoded claims to be protected with CBOR
   Object Signing and Encryption (COSE).

   This document registers a new value to the "TLS Certificate Types"
   sub-registry to allow TLS and DTLS to use CWTs.  Conceptually, CWTs
   can be seen as a certificate format (when with public key
   cryptography) or a Kerberos ticket (when used with symmetric key
   cryptography).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-tschofenig-tls-cwt-02"/>
        </reference>
        <reference anchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author>
            <author fullname="J. Schiller" initials="J." surname="Schiller">
              <organization/>
            </author>
            <author fullname="S. Crocker" initials="S." surname="Crocker">
              <organization/>
            </author>
            <date month="June" year="2005"/>
            <abstract>
              <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts.  However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>

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

<!-- [I-D.tschofenig-rats-psa-token] IESG state	I-D Exists -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.tschofenig-rats-psa-token.xml"/>

<!-- [I-D.tschofenig-tls-cwt] IESG state Expired -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.tschofenig-tls-cwt.xml"/>

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

      </references>
    </references>

    <section anchor="time-considerations">
      <name>Time Considerations</name>
      <t><xref target="freshness"/> discussed various issues and requirements around freshness of evidence, Evidence and
summarized three approaches that might be used by different solutions to address them.
This appendix provides more details with examples to help illustrate potential approaches,
to approaches and inform those creating specific solutions.</t>
      <t>The table below defines a number of relevant events, events with an ID that
is used in subsequent diagrams.  The times of said events might be
defined in terms of an absolute clock time, such as the Coordinated Universal Time timescale,
or might be defined relative to some other timestamp or timeticks counter, such as a clock resetting its epoch each time it is powered on.</t>

<table>
  <name>Relevant Events over Time</name>
        <thead>
          <tr>
            <th align="left">ID</th>
            <th align="left">Event</th>
            <th align="left">Explanation of event</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">VG</td>
            <td align="left">Value generated</td>
            <td align="left">A value to appear in a Claim was created.  In some cases, a value may have technically existed before an Attester became aware of it it, but the Attester might have no idea how long it has had that value.  In such a case, the Value value created time is the time at which the Claim containing the copy of the value was created.</td>
          </tr>
          <tr>
            <td align="left">NS</td>
            <td align="left">Nonce sent</td>
            <td align="left">A nonce not predictable to an Attester (recentness &amp; uniqueness) is sent to an Attester.</td>
          </tr>
          <tr>
            <td align="left">NR</td>
            <td align="left">Nonce relayed</td>
            <td align="left">A nonce is relayed to an Attester by another entity.</td>
          </tr>
          <tr>
            <td align="left">IR</td>
            <td align="left">Epoch ID received</td>
            <td align="left">An epoch ID is successfully received and processed by an entity.</td>
          </tr>
          <tr>
            <td align="left">EG</td>
            <td align="left">Evidence generation</td>
            <td align="left">An Attester creates Evidence from collected Claims.</td>
          </tr>
          <tr>
            <td align="left">ER</td>
            <td align="left">Evidence relayed</td>
            <td align="left">A Relying Party relays Evidence to a Verifier.</td>
          </tr>
          <tr>
            <td align="left">RG</td>
            <td align="left">Result generation</td>
            <td align="left">A Verifier appraises Evidence and generates an Attestation Result.</td>
          </tr>
          <tr>
            <td align="left">RR</td>
            <td align="left">Result relayed</td>
            <td align="left">A Relying Party relays an Attestation Result to a Relying Party.</td>
          </tr>
          <tr>
            <td align="left">RA</td>
            <td align="left">Result appraised</td>
            <td align="left">The Relying Party appraises Attestation Results.</td>
          </tr>
          <tr>
            <td align="left">OP</td>
            <td align="left">Operation performed</td>
            <td align="left">The Relying Party performs some operation requested by the Attester via a resource access protocol as depicted in <xref target="clientserver"/>, e.g., across a session created earlier at time(RA).</td>
          </tr>
          <tr>
            <td align="left">RX</td>
            <td align="left">Result expiry</td>
            <td align="left">An Attestation Result should no longer be accepted, according to the Verifier that generated it.</td>
          </tr>
        </tbody>
      </table>
      <t>Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.
This list is not intended to be complete,
but complete;
it is just representative enough to highlight various timing considerations.</t>
      <t>All times are relative to the local clocks, indicated by an "_a" (Attester),
"_v" (Verifier), or "_r" (Relying Party) suffix.</t>
      <t>Times with an appended Prime (') indicate a second instance of the same event.</t>
      <t>How and if clocks are synchronized depends upon the model.</t>
      <t>In the figures below, curly braces indicate containment.
For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence
and Evidence; thus, it is thus covered by its signature.</t>
      <section anchor="example-1-timestamp-based-passport-model-example">
        <name>Example 1: Timestamp-based Timestamp-Based Passport Model Example</name>
        <t>The following example Model</name>
        <t><xref target="timestamp-based-passport-model"/>
illustrates a hypothetical Passport Model
solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party, which
depends on using a secure clock synchronization mechanism.
As a result, the receiver of a conceptual message containing a
timestamp can directly compare it to its own clock and timestamps.</t>
      <figure anchor="timestamp-based-passport-model">
        <name>Timestamp-Based Passport Model</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="416" width="520" viewBox="0 0 520 416" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
              <path d="M 48,64 L 48,80" fill="none" stroke="black"/>
              <path d="M 48,176 L 48,272" fill="none" stroke="black"/>
              <path d="M 48,304 L 48,336" fill="none" stroke="black"/>
              <path d="M 48,368 L 48,384" fill="none" stroke="black"/>
              <path d="M 96,32 L 96,64" fill="none" stroke="black"/>
              <path d="M 272,32 L 272,64" fill="none" stroke="black"/>
              <path d="M 320,64 L 320,112" fill="none" stroke="black"/>
              <path d="M 320,144 L 320,208" fill="none" stroke="black"/>
              <path d="M 320,240 L 320,272" fill="none" stroke="black"/>
              <path d="M 360,32 L 360,64" fill="none" stroke="black"/>
              <path d="M 384,32 L 384,64" fill="none" stroke="black"/>
              <path d="M 448,64 L 448,112" fill="none" stroke="black"/>
              <path d="M 448,144 L 448,272" fill="none" stroke="black"/>
              <path d="M 512,32 L 512,64" fill="none" stroke="black"/>
              <path d="M 8,32 L 96,32" fill="none" stroke="black"/>
              <path d="M 272,32 L 360,32" fill="none" stroke="black"/>
              <path d="M 384,32 L 512,32" fill="none" stroke="black"/>
              <path d="M 8,64 L 96,64" fill="none" stroke="black"/>
              <path d="M 272,64 L 360,64" fill="none" stroke="black"/>
              <path d="M 384,64 L 512,64" fill="none" stroke="black"/>
              <path d="M 48,192 L 96,192" fill="none" stroke="black"/>
              <path d="M 264,192 L 312,192" fill="none" stroke="black"/>
              <path d="M 56,256 L 96,256" fill="none" stroke="black"/>
              <path d="M 248,256 L 320,256" fill="none" stroke="black"/>
              <path d="M 48,320 L 64,320" fill="none" stroke="black"/>
              <path d="M 400,320 L 416,320" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="424,320 412,314.4 412,325.6 " fill="black" transform="rotate(0,416,320)"/>
              <polygon class="arrowhead" points="320,192 308,186.4 308,197.6 " fill="black" transform="rotate(0,312,192)"/>
              <polygon class="arrowhead" points="64,256 52,250.4 52,261.6 " fill="black" transform="rotate(180,56,256)"/>
              <g class="text">
                <text x="52" y="52">Attester</text>
                <text x="316" y="52">Verifier</text>
                <text x="424" y="52">Relying</text>
                <text x="480" y="52">Party</text>
                <text x="60" y="100">time(VG_a)</text>
                <text x="48" y="116">|</text>
                <text x="48" y="132">~</text>
                <text x="320" y="132">~</text>
                <text x="448" y="132">~</text>
                <text x="48" y="148">|</text>
                <text x="60" y="164">time(EG_a)</text>
                <text x="180" y="196">Evidence{time(EG_a)}</text>
                <text x="332" y="228">time(RG_v)</text>
                <text x="144" y="260">Attestation</text>
                <text x="220" y="260">Result</text>
                <text x="192" y="276">{time(RG_v),time(RX_v)}</text>
                <text x="48" y="292">~</text>
                <text x="448" y="292">~</text>
                <text x="448" y="308">|</text>
                <text x="112" y="324">Attestation</text>
                <text x="280" y="324">Result{time(RG_v),time(RX_v)}</text>
                <text x="468" y="324">time(RA_r)</text>
                <text x="448" y="340">|</text>
                <text x="48" y="356">~</text>
                <text x="448" y="356">~</text>
                <text x="448" y="372">|</text>
                <text x="460" y="388">time(OP_r)</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
   .----------.                     .----------.  .---------------.
   | Attester |                     | Verifier |  | Relying Party |
   '----+-----'                     '-----+----'  '-------+-------'
        |                                 |               |
     time(VG_a)                           |               |
        |                                 |               |
        ~                                 ~               ~
        |                                 |               |
     time(EG_a)                           |               |
        |                                 |               |
        +------Evidence{time(EG_a)}------>|               |
        |                                 |               |
        |                              time(RG_v)         |
        |                                 |               |
        |<-----Attestation Result---------+               |
        |      {time(RG_v),time(RX_v)}    |               |
        ~                                                 ~
        |                                                 |
        +--Attestation Result{time(RG_v),time(RX_v)}--> time(RA_r)
        |                                                 |
        ~                                                 ~
        |                                                 |
        |                                              time(OP_r)
]]></artwork>                                              time(OP_r)]]></artwork>
        </artset>
      </figure>
        <t>The Verifier can check whether the Evidence is fresh when appraising
it at time(RG_v) by checking <tt>time(RG_v) - time(EG_a) &lt; Threshold</tt>, where the
Verifier's threshold is large enough to account for the maximum
permitted clock skew between the Verifier and the Attester.</t>
        <t>If time(VG_a) is also included in the Evidence along with the Claim value
generated at that time, and the Verifier decides that it can trust the
time(VG_a) value, the Verifier can also determine whether the Claim value is
recent by checking <tt>time(RG_v) - time(VG_a) &lt; Threshold</tt>.
The threshold is decided by the Appraisal Policy for Evidence, and again Evidence and, again,  needs to take
into account the maximum permitted clock skew between
the Verifier and the Attester.</t>
        <t>The Attester does not consume the Attestation Result, Result but might cache it.</t>
        <t>The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA_r) by checking the <tt>time(RA_r) - time(RG_v) &lt; Threshold</tt>,
where the Relying Party's threshold is large enough to account for the
maximum permitted clock skew between the Relying Party and the Verifier.
The result might then be used for some time (e.g., throughout the lifetime
of a connection established at time(RA_r)).  The  However, the Relying Party must be
careful, however, to
careful not to allow continued use beyond the period for which
it deems the Attestation Result to remain fresh enough.  Thus,
it might allow use (at time(OP_r)) as long as <tt>time(OP_r) - time(RG_v) &lt; Threshold</tt>.
However, if the Attestation Result contains an expiry time time(RX_v) time(RX_v), then
it could explicitly check <tt>time(OP_r) &lt; time(RX_v)</tt>.</t>
</section>
      <section anchor="example-2-nonce-based-passport-model-example">
        <name>Example 2: Nonce-based Nonce-Based Passport Model Example</name>
        <t>The following example Model</name>
        <t><xref target="nonce-based-passport-model"/> illustrates a hypothetical Passport Model
solution that uses nonces instead of timestamps.  Compared to the
timestamp-based example, it requires an extra round trip
to retrieve a nonce, nonce and requires that the Verifier and Relying Party
track state to remember the nonce for some period of time.</t>
        <t>The advantage is that it does not require that any clocks
are synchronized.
As a result, the receiver of a conceptual message containing a
timestamp cannot directly compare it to its own clock or timestamps.
Thus, we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, them since times from different clocks cannot be compared.
Only the delta between two events from the sender can be used by the receiver.</t>
      <figure anchor="nonce-based-passport-model">
        <name>Nonce-Based Passport Model</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="544" width="536" viewBox="0 0 536 544" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
              <path d="M 48,64 L 48,80" fill="none" stroke="black"/>
              <path d="M 48,144 L 48,176" fill="none" stroke="black"/>
              <path d="M 48,208 L 48,320" fill="none" stroke="black"/>
              <path d="M 48,352 L 48,384" fill="none" stroke="black"/>
              <path d="M 48,416 L 48,464" fill="none" stroke="black"/>
              <path d="M 48,496 L 48,512" fill="none" stroke="black"/>
              <path d="M 96,32 L 96,64" fill="none" stroke="black"/>
              <path d="M 272,32 L 272,64" fill="none" stroke="black"/>
              <path d="M 320,64 L 320,112" fill="none" stroke="black"/>
              <path d="M 320,176 L 320,256" fill="none" stroke="black"/>
              <path d="M 320,288 L 320,320" fill="none" stroke="black"/>
              <path d="M 360,32 L 360,64" fill="none" stroke="black"/>
              <path d="M 384,32 L 384,64" fill="none" stroke="black"/>
              <path d="M 448,64 L 448,112" fill="none" stroke="black"/>
              <path d="M 448,144 L 448,320" fill="none" stroke="black"/>
              <path d="M 448,384 L 448,464" fill="none" stroke="black"/>
              <path d="M 512,32 L 512,64" fill="none" stroke="black"/>
              <path d="M 8,32 L 96,32" fill="none" stroke="black"/>
              <path d="M 272,32 L 360,32" fill="none" stroke="black"/>
              <path d="M 384,32 L 512,32" fill="none" stroke="black"/>
              <path d="M 8,64 L 96,64" fill="none" stroke="black"/>
              <path d="M 272,64 L 360,64" fill="none" stroke="black"/>
              <path d="M 384,64 L 512,64" fill="none" stroke="black"/>
              <path d="M 56,160 L 72,160" fill="none" stroke="black"/>
              <path d="M 128,160 L 288,160" fill="none" stroke="black"/>
              <path d="M 48,224 L 72,224" fill="none" stroke="black"/>
              <path d="M 144,224 L 312,224" fill="none" stroke="black"/>
              <path d="M 56,304 L 72,304" fill="none" stroke="black"/>
              <path d="M 224,304 L 320,304" fill="none" stroke="black"/>
              <path d="M 56,368 L 72,368" fill="none" stroke="black"/>
              <path d="M 128,368 L 416,368" fill="none" stroke="black"/>
              <path d="M 48,432 L 64,432" fill="none" stroke="black"/>
              <path d="M 424,432 L 440,432" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="448,432 436,426.4 436,437.6 " fill="black" transform="rotate(0,440,432)"/>
              <polygon class="arrowhead" points="320,224 308,218.4 308,229.6 " fill="black" transform="rotate(0,312,224)"/>
              <polygon class="arrowhead" points="64,368 52,362.4 52,373.6 " fill="black" transform="rotate(180,56,368)"/>
              <polygon class="arrowhead" points="64,304 52,298.4 52,309.6 " fill="black" transform="rotate(180,56,304)"/>
              <polygon class="arrowhead" points="64,160 52,154.4 52,165.6 " fill="black" transform="rotate(180,56,160)"/>
              <g class="text">
                <text x="52" y="52">Attester</text>
                <text x="316" y="52">Verifier</text>
                <text x="424" y="52">Relying</text>
                <text x="480" y="52">Party</text>
                <text x="60" y="100">time(VG_a)</text>
                <text x="48" y="116">|</text>
                <text x="48" y="132">~</text>
                <text x="320" y="132">~</text>
                <text x="448" y="132">~</text>
                <text x="320" y="148">|</text>
                <text x="100" y="164">Nonce1</text>
                <text x="332" y="164">time(NS_v)</text>
                <text x="60" y="196">time(EG_a)</text>
                <text x="108" y="228">Evidence</text>
                <text x="92" y="244">{Nonce1,</text>
                <text x="220" y="244">time(EG_a)-time(VG_a)}</text>
                <text x="332" y="276">time(RG_v)</text>
                <text x="120" y="308">Attestation</text>
                <text x="196" y="308">Result</text>
                <text x="168" y="324">{time(RX_v)-time(RG_v)}</text>
                <text x="48" y="340">~</text>
                <text x="448" y="340">~</text>
                <text x="448" y="356">|</text>
                <text x="100" y="372">Nonce2</text>
                <text x="460" y="372">time(NS_r)</text>
                <text x="60" y="404">time(RR_a)</text>
                <text x="116" y="436">[Attestation</text>
                <text x="292" y="436">Result{time(RX_v)-time(RG_v)},</text>
                <text x="492" y="436">time(RA_r)</text>
                <text x="144" y="452">Nonce2,</text>
                <text x="268" y="452">time(RR_a)-time(EG_a)]</text>
                <text x="48" y="484">~</text>
                <text x="448" y="484">~</text>
                <text x="448" y="500">|</text>
                <text x="460" y="516">time(OP_r)</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
   .----------.                     .----------.  .---------------.
   | Attester |                     | Verifier |  | Relying Party |
   '----+-----'                     '-----+----'  '-------+-------'
        |                                 |               |
     time(VG_a)                           |               |
        |                                 |               |
        ~                                 ~               ~
        |                                 |               |
        |<--Nonce1---------------------time(NS_v)         |
        |                                 |               |
     time(EG_a)                           |               |
        |                                 |               |
        +---Evidence--------------------->|               |
        | {Nonce1, time(EG_a)-time(VG_a)} |               |
        |                                 |               |
        |                              time(RG_v)         |
        |                                 |               |
        |<--Attestation Result------------+               |
        |   {time(RX_v)-time(RG_v)}       |               |
        ~                                                 ~
        |                                                 |
        |<--Nonce2-------------------------------------time(NS_r)
        |                                                 |
     time(RR_a)                                           |
        |                                                 |
        +--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r)
        |        Nonce2, time(RR_a)-time(EG_a)]           |
        |                                                 |
        ~                                                 ~
        |                                                 |
        |                                              time(OP_r)
]]></artwork>                                              time(OP_r)]]></artwork>
        </artset>
      </figure>
        <t>In this example solution, the Verifier can check whether the Evidence is
fresh at <tt>time(RG_v)</tt> by verifying that <tt>time(RG_v)-time(NS_v) &lt; Threshold</tt>.</t>
        <t>The
        <t>However, the Verifier cannot, however, cannot simply rely on a Nonce to
determine whether the value of a Claim is recent, recent since the Claim value
might have been generated long before the nonce was sent by the Verifier.
However,
Nevertheless, if the Verifier decides that the Attester can be trusted to
correctly provide the delta <tt>time(EG_a)-time(VG_a)</tt>, then it can determine recency
by checking <tt>time(RG_v)-time(NS_v) + time(EG_a)-time(VG_a) &lt; Threshold</tt>.</t>

<t>Similarly if, based on an Attestation Result from a Verifier it trusts, the
Relying Party decides that the Attester can be trusted to correctly provide
time deltas, then it can determine whether the Attestation Result is fresh by
checking <tt>time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) &lt;
Threshold</tt>.  Although the Nonce2 and <tt>time(RR_a)-time(EG_a)</tt> values
cannot be inside the Attestation Result, they might be signed by the Attester
such that the Attestation Result vouches for the Attester's signing
capability.</t>
        <t>The
        <t>However, the Relying Party must still be careful, however, to careful not to allow continued
use beyond the period for which it deems the Attestation Result to remain
valid.  Thus, if the Attestation Result sends a validity lifetime
in terms of <tt>time(RX_v)-time(RG_v)</tt>, then the Relying Party can check
<tt>time(OP_r)-time(NS_r) &lt; time(RX_v)-time(RG_v)</tt>.</t>
      </section>
      <section anchor="example-3-epoch-id-based-passport-model-example">
        <name>Example 3: Epoch ID-based Passport Model Example</name> Based on Epoch ID</name>
        <t>The example in <xref target="fig-epochid-passport"/> illustrates a hypothetical Passport Model
solution that uses epoch IDs instead of nonces or timestamps.</t>
        <t>The Epoch epoch ID Distributor distributor broadcasts epoch ID <tt>I</tt> <tt>I</tt>, which starts a new
epoch <tt>E</tt> for a protocol participant upon reception at <tt>time(IR)</tt>.</t>
        <t>The Attester generates Evidence incorporating epoch ID <tt>I</tt> and conveys it to the
	Verifier.</t>

        <t>The Verifier appraises that the received epoch ID <tt>I</tt> is "fresh" according to the
definition provided in <xref target="epochfreshness"/> whereby retries are required in the case of mismatching epoch IDs, and IDs; then the Verifier generates an Attestation Result.  The
Attestation Result is conveyed to the Attester.</t>
        <t>After the transmission of epoch ID <tt>I'</tt> a new epoch <tt>E'</tt> is
established when <tt>I'</tt> is received by each protocol participant.  The Attester
relays the Attestation Result obtained during epoch <tt>E</tt> (associated with epoch ID
<tt>I</tt>) to the Relying Party using the epoch ID for the current epoch <tt>I'</tt>.
If the Relying Party had not yet received <tt>I'</tt>, then the Attestation Result would be rejected, but rejected. The Attestation Result is received in this example, it is received.</t> example.</t>
        <t>In the illustrated scenario, <xref target ="fig-epochid-passport"/>, the epoch ID for relaying an Attestation Result to the Relying Party is current, current while a previous epoch ID was used to generate Verifier evaluated evidence. Evidence.
This indicates that at least one epoch transition has occurred, occurred and the Attestation Results may only be as fresh as the previous epoch.
If the Relying Party remembers the previous epoch ID <tt>I</tt> during an epoch window
as discussed in <xref target="epochfreshness"/>, and the message is received during
that window, the Attestation Result is accepted as fresh, and otherwise fresh; otherwise, it is
rejected as stale.</t>
        <figure anchor="fig-epochid-passport">
          <name>Epoch ID-based ID-Based Passport Model</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="512" width="520" viewBox="0 0 520 512" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
                <path d="M 48,80 L 48,96" fill="none" stroke="black"/>
                <path d="M 48,224 L 48,352" fill="none" stroke="black"/>
                <path d="M 48,384 L 48,432" fill="none" stroke="black"/>
                <path d="M 48,464 L 48,480" fill="none" stroke="black"/>
                <path d="M 96,48 L 96,80" fill="none" stroke="black"/>
                <path d="M 128,32 L 128,80" fill="none" stroke="black"/>
                <path d="M 184,80 L 184,232" fill="none" stroke="black"/>
                <path d="M 184,264 L 184,304" fill="none" stroke="black"/>
                <path d="M 184,344 L 184,368" fill="none" stroke="black"/>
                <path d="M 240,32 L 240,80" fill="none" stroke="black"/>
                <path d="M 272,48 L 272,80" fill="none" stroke="black"/>
                <path d="M 320,80 L 320,128" fill="none" stroke="black"/>
                <path d="M 320,192 L 320,272" fill="none" stroke="black"/>
                <path d="M 320,304 L 320,352" fill="none" stroke="black"/>
                <path d="M 320,408 L 320,432" fill="none" stroke="black"/>
                <path d="M 320,464 L 320,480" fill="none" stroke="black"/>
                <path d="M 360,48 L 360,80" fill="none" stroke="black"/>
                <path d="M 384,48 L 384,80" fill="none" stroke="black"/>
                <path d="M 448,80 L 448,128" fill="none" stroke="black"/>
                <path d="M 448,192 L 448,352" fill="none" stroke="black"/>
                <path d="M 448,416 L 448,432" fill="none" stroke="black"/>
                <path d="M 512,48 L 512,80" fill="none" stroke="black"/>
                <path d="M 128,32 L 240,32" fill="none" stroke="black"/>
                <path d="M 8,48 L 96,48" fill="none" stroke="black"/>
                <path d="M 272,48 L 360,48" fill="none" stroke="black"/>
                <path d="M 384,48 L 512,48" fill="none" stroke="black"/>
                <path d="M 8,80 L 96,80" fill="none" stroke="black"/>
                <path d="M 128,80 L 240,80" fill="none" stroke="black"/>
                <path d="M 272,80 L 360,80" fill="none" stroke="black"/>
                <path d="M 384,80 L 512,80" fill="none" stroke="black"/>
                <path d="M 112,176 L 152,176" fill="none" stroke="black"/>
                <path d="M 168,176 L 176,176" fill="none" stroke="black"/>
                <path d="M 192,176 L 200,176" fill="none" stroke="black"/>
                <path d="M 216,176 L 264,176" fill="none" stroke="black"/>
                <path d="M 368,176 L 392,176" fill="none" stroke="black"/>
                <path d="M 48,240 L 72,240" fill="none" stroke="black"/>
                <path d="M 144,240 L 312,240" fill="none" stroke="black"/>
                <path d="M 56,320 L 72,320" fill="none" stroke="black"/>
                <path d="M 224,320 L 320,320" fill="none" stroke="black"/>
                <path d="M 120,368 L 152,368" fill="none" stroke="black"/>
                <path d="M 192,368 L 200,368" fill="none" stroke="black"/>
                <path d="M 232,368 L 264,368" fill="none" stroke="black"/>
                <path d="M 376,368 L 392,368" fill="none" stroke="black"/>
                <path d="M 48,400 L 72,400" fill="none" stroke="black"/>
                <path d="M 232,400 L 392,400" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="400,400 388,394.4 388,405.6 " fill="black" transform="rotate(0,392,400)"/>
                <polygon class="arrowhead" points="400,368 388,362.4 388,373.6 " fill="black" transform="rotate(0,392,368)"/>
                <polygon class="arrowhead" points="400,176 388,170.4 388,181.6 " fill="black" transform="rotate(0,392,176)"/>
                <polygon class="arrowhead" points="320,240 308,234.4 308,245.6 " fill="black" transform="rotate(0,312,240)"/>
                <polygon class="arrowhead" points="272,368 260,362.4 260,373.6 " fill="black" transform="rotate(0,264,368)"/>
                <polygon class="arrowhead" points="272,176 260,170.4 260,181.6 " fill="black" transform="rotate(0,264,176)"/>
                <polygon class="arrowhead" points="128,368 116,362.4 116,373.6 " fill="black" transform="rotate(180,120,368)"/>
                <polygon class="arrowhead" points="120,176 108,170.4 108,181.6 " fill="black" transform="rotate(180,112,176)"/>
                <polygon class="arrowhead" points="64,320 52,314.4 52,325.6 " fill="black" transform="rotate(180,56,320)"/>
                <circle cx="184" cy="176" r="6" class="opendot" fill="white" stroke="black"/>
                <circle cx="184" cy="368" r="6" class="opendot" fill="white" stroke="black"/>
                <g class="text">
                  <text x="160" y="52">Epoch</text>
                  <text x="196" y="52">ID</text>
                  <text x="52" y="68">Attester</text>
                  <text x="184" y="68">Distributor</text>
                  <text x="316" y="68">Verifier</text>
                  <text x="424" y="68">Relying</text>
                  <text x="480" y="68">Party</text>
                  <text x="60" y="116">time(VG_a)</text>
                  <text x="48" y="132">|</text>
                  <text x="48" y="148">~</text>
                  <text x="320" y="148">~</text>
                  <text x="448" y="148">~</text>
                  <text x="48" y="164">|</text>
                  <text x="320" y="164">|</text>
                  <text x="448" y="164">|</text>
                  <text x="60" y="180">time(IR_a)</text>
                  <text x="160" y="180">I</text>
                  <text x="208" y="180">I</text>
                  <text x="316" y="180">time(IR_v)</text>
                  <text x="444" y="180">time(IR_r)</text>
                  <text x="48" y="196">|</text>
                  <text x="60" y="212">time(EG_a)</text>
                  <text x="108" y="244">Evidence</text>
                  <text x="176" y="260">{I,time(EG_a)-time(VG_a)}</text>
                  <text x="316" y="292">time(RG_v)</text>
                  <text x="120" y="324">Attestation</text>
                  <text x="196" y="324">Result</text>
                  <text x="176" y="340">{I,time(RX_v)-time(RG_v)}</text>
                  <text x="64" y="372">time(IR'_a)</text>
                  <text x="168" y="372">I'-</text>
                  <text x="212" y="372">I'</text>
                  <text x="320" y="372">time(IR'_v)</text>
                  <text x="448" y="372">time(IR'_r)</text>
                  <text x="320" y="388">|</text>
                  <text x="448" y="388">|</text>
                  <text x="124" y="404">[Attestation</text>
                  <text x="204" y="404">Result</text>
                  <text x="444" y="404">time(RA_r)</text>
                  <text x="192" y="420">{I,time(RX_v)-time(RG_v)},I']</text>
                  <text x="48" y="452">~</text>
                  <text x="320" y="452">~</text>
                  <text x="448" y="452">~</text>
                  <text x="448" y="468">|</text>
                  <text x="444" y="484">time(OP_r)</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
                  .-------------.
   .----------.   | Epoch ID    |   .----------.  .---------------.
   | Attester |   | Distributor |   | Verifier |  | Relying Party |
   '----+-----'   '------+------'   '-----+----'  '-------+-------'
        |                |                |               |
     time(VG_a)          |                |               |
        |                |                |               |
        ~                |                ~               ~
        |                |                |               |
     time(IR_a) <-----I--o--I------> time(IR_v) ---> time(IR_r)
        |                |                |               |
     time(EG_a)          |                |               |
        |                |                |               |
        +---Evidence--------------------->|               |
        |   {I,time(EG_a)-time(VG_a)}     |               |
        |                |                |               |
        |                |           time(RG_v)           |
        |                |                |               |
        |<--Attestation Result------------+               |
        |   {I,time(RX_v)-time(RG_v)}     |               |
        |                |                |               |
     time(IR'_a) <----I'-o--I' ----> time(IR'_v) --> time(IR'_r)
        |                                 |               |
        +---[Attestation Result--------------------> time(RA_r)
        |   {I,time(RX_v)-time(RG_v)},I'] |               |
        |                                 |               |
        ~                                 ~               ~
        |                                 |               |
        |                                 |          time(OP_r)
]]></artwork>          time(OP_r)]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="example-4-timestamp-based-background-check-model-example">
        <name>Example 4: Timestamp-based Timestamp-Based Background-Check Model Example</name>
        <t>The following example Model</name>
        <t><xref target="timestamp-based-bg-check-model"/> illustrates a hypothetical Background-Check Model
solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party.
The Attester conveys Evidence to the Relying Party, which treats it as opaque and simply forwards it on to the Verifier.</t>
      <figure anchor="timestamp-based-bg-check-model">
        <name>Timestamp-Based Background-Check Model</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="568" viewBox="0 0 568 368" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
              <path d="M 72,64 L 72,80" fill="none" stroke="black"/>
              <path d="M 72,104 L 72,112" fill="none" stroke="black"/>
              <path d="M 72,168 L 72,304" fill="none" stroke="black"/>
              <path d="M 72,336 L 72,352" fill="none" stroke="black"/>
              <path d="M 96,32 L 96,64" fill="none" stroke="black"/>
              <path d="M 176,32 L 176,64" fill="none" stroke="black"/>
              <path d="M 240,64 L 240,112" fill="none" stroke="black"/>
              <path d="M 240,144 L 240,208" fill="none" stroke="black"/>
              <path d="M 240,240 L 240,272" fill="none" stroke="black"/>
              <path d="M 304,32 L 304,64" fill="none" stroke="black"/>
              <path d="M 472,32 L 472,64" fill="none" stroke="black"/>
              <path d="M 512,64 L 512,112" fill="none" stroke="black"/>
              <path d="M 512,144 L 512,240" fill="none" stroke="black"/>
              <path d="M 512,272 L 512,304" fill="none" stroke="black"/>
              <path d="M 512,336 L 512,352" fill="none" stroke="black"/>
              <path d="M 560,32 L 560,64" fill="none" stroke="black"/>
              <path d="M 8,32 L 96,32" fill="none" stroke="black"/>
              <path d="M 176,32 L 304,32" fill="none" stroke="black"/>
              <path d="M 472,32 L 560,32" fill="none" stroke="black"/>
              <path d="M 8,64 L 96,64" fill="none" stroke="black"/>
              <path d="M 176,64 L 304,64" fill="none" stroke="black"/>
              <path d="M 472,64 L 560,64" fill="none" stroke="black"/>
              <path d="M 72,192 L 104,192" fill="none" stroke="black"/>
              <path d="M 176,192 L 232,192" fill="none" stroke="black"/>
              <path d="M 288,224 L 304,224" fill="none" stroke="black"/>
              <path d="M 472,224 L 504,224" fill="none" stroke="black"/>
              <path d="M 288,288 L 312,288" fill="none" stroke="black"/>
              <path d="M 464,288 L 512,288" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="512,224 500,218.4 500,229.6 " fill="black" transform="rotate(0,504,224)"/>
              <polygon class="arrowhead" points="296,288 284,282.4 284,293.6 " fill="black" transform="rotate(180,288,288)"/>
              <polygon class="arrowhead" points="240,192 228,186.4 228,197.6 " fill="black" transform="rotate(0,232,192)"/>
              <g class="text">
                <text x="52" y="52">Attester</text>
                <text x="216" y="52">Relying</text>
                <text x="272" y="52">Party</text>
                <text x="516" y="52">Verifier</text>
                <text x="60" y="100">time(VG_a)</text>
                <text x="72" y="132">~</text>
                <text x="240" y="132">~</text>
                <text x="512" y="132">~</text>
                <text x="72" y="148">|</text>
                <text x="60" y="164">time(EG_a)</text>
                <text x="140" y="196">Evidence</text>
                <text x="148" y="212">{time(EG_a)}</text>
                <text x="236" y="228">time(ER_r)</text>
                <text x="388" y="228">Evidence{time(EG_a)}</text>
                <text x="508" y="260">time(RG_v)</text>
                <text x="236" y="292">time(RA_r)</text>
                <text x="360" y="292">Attestation</text>
                <text x="436" y="292">Result</text>
                <text x="240" y="308">|</text>
                <text x="380" y="308">{time(RX_v)}</text>
                <text x="72" y="324">~</text>
                <text x="240" y="324">~</text>
                <text x="512" y="324">~</text>
                <text x="240" y="340">|</text>
                <text x="252" y="356">time(OP_r)</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
.----------.         .---------------.                    .----------.
| Attester |         | Relying Party |                    | Verifier |
'-------+--'         '-------+-------'                    '----+-----'
        |                    |                                 |
  time(VG_a)                 |                                 |
        |                    |                                 |
        ~                    ~                                 ~
        |                    |                                 |
  time(EG_a)                 |                                 |
        |                    |                                 |
        +----Evidence------->|                                 |
        |   {time(EG_a)}     |                                 |
        |               time(ER_r) ---Evidence{time(EG_a)}---->|
        |                    |                                 |
        |                    |                            time(RG_v)
        |                    |                                 |
        |               time(RA_r) <---Attestation Result------+
        |                    |           {time(RX_v)}          |
        ~                    ~                                 ~
        |                    |                                 |
        |                 time(OP_r)                           |
]]></artwork>                           |]]></artwork>
        </artset>
      </figure>
        <t>The time considerations in this example are equivalent to those
discussed under Example 1 above.</t> <xref target="example-1-timestamp-based-passport-model-example" format="none">Example 1</xref>.</t>
      </section>
      <section anchor="example-5-nonce-based-background-check-model-example">
        <name>Example 5: Nonce-based Nonce-Based Background-Check Model Example</name>
        <t>The following example Model</name>
        <t><xref target="nonce-based-bg-check-model"/> illustrates a hypothetical Background-Check Model
solution that uses nonces and thus nonces; thus, it does not require that any clocks
are
be synchronized.
In this example solution, a nonce is generated by a Verifier at the request of a Relying Party, Party when the Relying Party needs to send one to an Attester.</t>
      <figure anchor="nonce-based-bg-check-model">
        <name>Nonce-Based Background-Check Model</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="432" width="536" viewBox="0 0 536 432" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
              <path d="M 48,64 L 48,80" fill="none" stroke="black"/>
              <path d="M 48,144 L 48,208" fill="none" stroke="black"/>
              <path d="M 48,240 L 48,368" fill="none" stroke="black"/>
              <path d="M 48,400 L 48,416" fill="none" stroke="black"/>
              <path d="M 96,32 L 96,64" fill="none" stroke="black"/>
              <path d="M 176,32 L 176,64" fill="none" stroke="black"/>
              <path d="M 240,64 L 240,112" fill="none" stroke="black"/>
              <path d="M 240,144 L 240,176" fill="none" stroke="black"/>
              <path d="M 240,208 L 240,272" fill="none" stroke="black"/>
              <path d="M 240,304 L 240,336" fill="none" stroke="black"/>
              <path d="M 304,32 L 304,64" fill="none" stroke="black"/>
              <path d="M 440,32 L 440,64" fill="none" stroke="black"/>
              <path d="M 480,64 L 480,112" fill="none" stroke="black"/>
              <path d="M 480,176 L 480,304" fill="none" stroke="black"/>
              <path d="M 480,336 L 480,368" fill="none" stroke="black"/>
              <path d="M 480,400 L 480,416" fill="none" stroke="black"/>
              <path d="M 528,32 L 528,64" fill="none" stroke="black"/>
              <path d="M 8,32 L 96,32" fill="none" stroke="black"/>
              <path d="M 176,32 L 304,32" fill="none" stroke="black"/>
              <path d="M 440,32 L 528,32" fill="none" stroke="black"/>
              <path d="M 8,64 L 96,64" fill="none" stroke="black"/>
              <path d="M 176,64 L 304,64" fill="none" stroke="black"/>
              <path d="M 440,64 L 528,64" fill="none" stroke="black"/>
              <path d="M 248,160 L 304,160" fill="none" stroke="black"/>
              <path d="M 352,160 L 432,160" fill="none" stroke="black"/>
              <path d="M 56,192 L 80,192" fill="none" stroke="black"/>
              <path d="M 128,192 L 208,192" fill="none" stroke="black"/>
              <path d="M 48,256 L 80,256" fill="none" stroke="black"/>
              <path d="M 208,256 L 232,256" fill="none" stroke="black"/>
              <path d="M 304,288 L 320,288" fill="none" stroke="black"/>
              <path d="M 448,288 L 472,288" fill="none" stroke="black"/>
              <path d="M 288,352 L 312,352" fill="none" stroke="black"/>
              <path d="M 464,352 L 480,352" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="480,288 468,282.4 468,293.6 " fill="black" transform="rotate(0,472,288)"/>
              <polygon class="arrowhead" points="296,352 284,346.4 284,357.6 " fill="black" transform="rotate(180,288,352)"/>
              <polygon class="arrowhead" points="256,160 244,154.4 244,165.6 " fill="black" transform="rotate(180,248,160)"/>
              <polygon class="arrowhead" points="240,256 228,250.4 228,261.6 " fill="black" transform="rotate(0,232,256)"/>
              <polygon class="arrowhead" points="64,192 52,186.4 52,197.6 " fill="black" transform="rotate(180,56,192)"/>
              <g class="text">
                <text x="52" y="52">Attester</text>
                <text x="216" y="52">Relying</text>
                <text x="272" y="52">Party</text>
                <text x="484" y="52">Verifier</text>
                <text x="60" y="100">time(VG_a)</text>
                <text x="48" y="116">|</text>
                <text x="48" y="132">~</text>
                <text x="240" y="132">~</text>
                <text x="480" y="132">~</text>
                <text x="480" y="148">|</text>
                <text x="328" y="164">Nonce</text>
                <text x="476" y="164">time(NS_v)</text>
                <text x="104" y="196">Nonce</text>
                <text x="252" y="196">time(NR_r)</text>
                <text x="60" y="228">time(EG_a)</text>
                <text x="144" y="260">Evidence{Nonce}</text>
                <text x="252" y="292">time(ER_r)</text>
                <text x="384" y="292">Evidence{Nonce}</text>
                <text x="492" y="324">time(RG_v)</text>
                <text x="240" y="356">ime(RA_r)</text>
                <text x="360" y="356">Attestation</text>
                <text x="436" y="356">Result</text>
                <text x="240" y="372">|</text>
                <text x="368" y="372">{time(RX_v)-time(RG_v)}</text>
                <text x="48" y="388">~</text>
                <text x="240" y="388">~</text>
                <text x="480" y="388">~</text>
                <text x="240" y="404">|</text>
                <text x="252" y="420">time(OP_r)</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
.----------.         .---------------.                .----------.
| Attester |         | Relying Party |                | Verifier |
'----+-----'         '-------+-------'                '----+-----'
     |                       |                             |
  time(VG_a)                 |                             |
     |                       |                             |
     ~                       ~                             ~
     |                       |                             |
     |                       |<-------Nonce-----------time(NS_v)
     |                       |                             |
     |<---Nonce-----------time(NR_r)                       |
     |                       |                             |
  time(EG_a)                 |                             |
     |                       |                             |
     +----Evidence{Nonce}--->|                             |
     |                       |                             |
     |                    time(ER_r) ---Evidence{Nonce}--->|
     |                       |                             |
     |                       |                          time(RG_v)
     |                       |                             |
     |                   ime(RA_r) <---Attestation Result--+
     |                       |    {time(RX_v)-time(RG_v)}  |
     ~                       ~                             ~
     |                       |                             |
     |                    time(OP_r)                       |
]]></artwork>                       |]]></artwork>
        </artset>
      </figure>
        <t>The Verifier can check whether the Evidence is fresh, fresh and whether a Claim
value is recent, which is the same as in Example 2 above.</t> <xref target="example-2-nonce-based-passport-model-example" format="none">Example 2</xref>.</t>
        <t>However, unlike in Example 2,  <xref target="example-2-nonce-based-passport-model-example" format="none">Example 2</xref>, the Relying
        Party can use the Nonce to determine whether the Attestation Result is fresh,
        fresh by verifying that <tt>time(OP_r)-time(NR_r) &lt;
        Threshold</tt>.</t>
        <t>The
        <t>However, the Relying Party must still be careful, however, to careful not to allow continued
use beyond the period for which it deems the Attestation Result to remain
valid.  Thus, if the Attestation Result sends a validity lifetime
in terms of <tt>time(RX_v)-time(RG_v)</tt>, then the Relying Party can check
<tt>time(OP_r)-time(ER_r) &lt; time(RX_v)-time(RG_v)</tt>.</t>
      </section>
    </section>
 <section anchor="contributors" title="Acknowledgments" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="M." surname="Wiseman" fullname="Monty Wiseman">
        <organization/>
        <address>
          <email>montywiseman32@gmail.com</email>
        </address>
      </contact> toc="include">
   <t>The authors would like to thank the following people for their input:</t>

 <t><contact fullname="Joerg Borchert"/>, <contact initials="L." surname="Xia" fullname="Liang Xia">
        <organization/>
        <address>
          <email>frank.xialiang@huawei.com</email>
        </address>
      </contact> fullname="Carsten Bormann"/>, <contact initials="L." surname="Lundblade" fullname="Laurence Lundblade">
        <organization/>
        <address>
          <email>lgl@island-resort.com</email>
        </address>
      </contact> fullname="Nancy Cam-Winget"/>, <contact initials="E." surname="Lear" fullname="Eliot Lear">
        <organization/>
        <address>
          <email>elear@cisco.com</email>
        </address>
      </contact> fullname="Guy Fedorkow"/>, <contact initials="J." surname="Fitzgerald-McKay" fullname="Jessica Fitzgerald-McKay">
        <organization/>
        <address>
      </address>
      </contact> Fitzgerald-McKay"/>, <contact initials="S. C." surname="Helbe" fullname="Sarah C. Helbe">
        <organization/>
        <address>
      </address>
      </contact> fullname="Thomas Fossati"/>, <contact fullname="Simon Frost"/>, <contact initials="A." surname="Guinn" fullname="Andrew Guinn">
        <organization/>
        <address>
      </address>
      </contact> Guinn"/>, <contact initials="P." surname="Loscocco" fullname="Peter Loscocco">
        <organization/>
        <address>
          <email>pete.loscocco@gmail.com</email>
        </address>
      </contact> fullname="Thomas Hardjano"/>, <contact initials="E." surname="Voit" fullname="Eric Voit">
        <organization/>
        <address>
      </address>
      </contact> fullname="Eliot Lear"/>, <contact initials="T." surname="Fossati" fullname="Thomas Fossati">
        <organization/>
        <address>
          <email>thomas.fossati@arm.com</email>
        </address>
      </contact> fullname="Diego Lopez"/>, <contact initials="P." surname="Rowe" fullname="Paul Rowe">
        <organization/>
        <address>
      </address>
      </contact> fullname="Peter Loscocco"/>, <contact initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization/>
        <address>
          <email>cabo@tzi.org</email>
        </address>
      </contact> fullname="Laurence Lundblade"/>, <contact initials="G." surname="Mandyam" fullname="Giri Mandyam">
        <organization/>
        <address>
          <email>mandyam@qti.qualcomm.com</email>
        </address>
      </contact> Mandyam"/>, <contact fullname="Daniel Migault"/>, <contact initials="K." surname="Moriarty" fullname="Kathleen Moriarty">
        <organization/>
        <address>
          <email>kathleen.moriarty.ietf@gmail.com</email>
        </address>
      </contact> Moriarty"/>, <contact initials="G." surname="Fedorkow" fullname="Guy Fedorkow">
        <organization/>
        <address>
          <email>gfedorkow@juniper.net</email>
        </address>
      </contact> fullname="Paul Rowe"/>, <contact initials="S." surname="Frost" fullname="Simon Frost">
        <organization/>
        <address>
          <email>Simon.Frost@arm.com</email>
        </address>
      </contact> fullname="Hannes Tschofenig"/>, <contact fullname="Eric Voit"/>, <contact fullname="Monty Wiseman"/>, <contact fullname="David Wooten"/>, and <contact fullname="Liang Xia"/>. </t>
   </section>

   <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
     <name>Contributors</name>
     <t><contact fullname="Thomas Hardjono"/> created initial versions of the
     terminology section in collaboration with <contact fullname="Ned
     Smith"/>. <contact fullname="Eric Voit"/> provided the conceptual
     separation between Attestation Provision Flows and Attestation Evidence
     Flows.
     <contact fullname="Monty Wisemen"/> was a key author of a document that was merged to create
     this document.
     <contact fullname="Carsten Bormann"/> provided many of the motivational building
     blocks with respect to the Internet Threat Model.</t>
     <t><contact fullname="Peter Loscocco"/> contributed critical review
     feedback as part of the weekly design team meetings that added precision
     and depth to several sections.</t>
</section>
  </back>
  <!-- ##markdown-source:
H4sIADEYNGMAA+y965LbVpYu+B9PgUlHHGWWSericl0UfbqdSkl2VlmWQlKV
68zEtA2SIIkSCLABMNN0Sv0s/RTzAD0vdtZ9rw2AmVKVe+pMxElHyJkksK9r
r72u35pOp0lXdGX+OH2db+suT8+7Lm+7rCvqKn3V1It8uW/yNj1vFpuiyxcd
/JVk83mTX8Er52/f0Dfpf0vf5s22TZb1osq20NqyyVbdtMi71bTJunaaufen
jx4l12t5/fu6eVdU6/Trpt7vEui5Wv6QlXUFbXTNPk+KXUO/td2jBw9+/+BR
kjV59jh9ky/2TdEdknfXj9PLqsubKu+mT7HXZJF1j9OiWtXJrnicpGlXLx6n
h7yFX9u66Zp81drfh234M8n23aZuHidTeBs++2aWPimad5u6/Bke5Xl9k1fv
/Kd1AxN53mT7alOv8iZ9c/kWPtUFGnyRb7OifJxuoJXZXFr5qi262cqenC1z
HBgMM4dpvN7kMJauydo2T3/7JXyzqJcwjnu/+fWj3395D/+GVXicPs1g+bts
2dET+6pr4MOvYU+y6qDzeTpL326yMm9sNk+zqzx8RnN5USyauq1XXRjtsqMn
vtrqV7NFvXVjPDmxYfGvNCL6tcnXQEj2iIzrT2/OdUwvZunrYrHJmmVbVzau
F/hRXsZf0fDeAH3kJcwqfQMDuQZiIApqw2i3i+ZzpLuvWn10tsj+ntFeZFW2
zHTA383SN9ui29hYv8uX9gkNEamxTC/qZlc3dI4cQdB3YaxVvpy1+O5XBX7x
8es6tpTfz9JXWVjD7/NC/qZRfbPPruGTt/liU9VlvS5yt2bXRVkW2Xa2yyp4
6KsNPUujSRY1dFTM9x0ejDSd6g7Bx4f0+6KFFrCPsPz4xTV//sWjr9b4qcxL
3/22yODA/6XI/HtwAOBM/FRkJX7rh+BezIB7VIs8/XZfLedlRifFWijX5VdF
W8KuT4FjwUHvvf2sLOou/TbPGv9WXsIHXy2KdlH3nv9D3rbFIkufF93P67zJ
yuX0xeKP2cE98iZrsk16MQO2UM5z98V5tWzy6/TrfVFV7uNXOTCq9NsaOlss
aj+MHXwzK+WL0VV71hSL9M910bnP3m7qbdamz+u2BUrz7XX0zWzF33wF3KHX
3KtsD+ervvajvsiatsur9EmNfCPa1kU2r7/qfi5mQEzuja+LpkhfwJIfsm1E
BfzRV//WFbN/22cl9N0fwB+zblPm0NuLuimypjv499/Jl7OtfDmjIz22Ll/v
D+nzfAlMoL72TaxX8uFXf91XxQ4YK9wQfu8KIFXg0HXb+dfo4xl9bKuWVLgg
XXGV4xF4/fzit18+/L38+rsvfv/ocZLgdRM/8+vf/1qf+fLRg/D4o0f468tX
F386f0wd662T0g8d1hP4GnYVqJwYyAl9J/c0ffenqlgVwHj8tZy+2eUL+HhB
70xgh5sufRSuSlho4IcTuOiB5OE2eTh78AW3DL1Aw48ePPxy+vDh9NGX3F3W
rJELbbpu1z6+f7/eLVY2IiSD+8v8Ki9rWNlpV9dle7/1/bfTPY8xuvrv72BQ
00fTVsY03eKY7lOHbd4AU8KF1LXAmT58AD/TRwl89Pbi6+nTy4tnx5ftLcoJ
sCwX9Xa370ysiNcPm0gv8qbjseYo5qyKMm9PRufdcZsLbXKNLdL8r3dT5I55
1d3f78o6W7b3se2pa3uqbU+bBw9/+AIoMX/04NGD6cPZbrmC7i6nT00OYEGp
2y9BvLFfR5/ZLxbA7/Ff+ZrkrC7Pd9FiAxfQj/xz1MQyg17gH15WfORxtEi6
kq/KrEPKRuLZl8B5i3mTNQc4RUReDx9HJHjyN+6MLPnJ37TmMP4f3r568eiH
5uHuy9//gON6+IMf1Q+7/RzXu0fsv0dif/A7+PD7fH4OY/4uXgL4NMWPoS+h
aeTr6fmryxRWJM0WC7wgYCav9vMSePMf80N60eRLfD4r26Nr8f0XF6OEdn19
Pbv+gmb59vX963yO71bTh3g6Lt6ev4pHd1EW0BHItn6MMCwgOJB36/Jo988v
n75Mz/G+h5t0dCCrYlln8gANBw92Sx9Prx7NHkyL5RTW73cPHj36LX+6oMEA
G5hmfjDTnQxm8Nps023LRGSdag2DXK321YIWOZrmG/k+rVfpc3niCNEs2mYx
q4q2m63rq/vrEq++5nAfbtztfe3mh3r1wypqZoxYv7t8c4HfXlxcTJ/CEXoq
XH386Yu6gkXgXXf0DR+jEFLstzH7OfI49pNiR+NcaOHesmMxK+r710jmuwy5
8INHUzitoL15Zjl9c/nk6S03zUexzDeH7TbvUAC5pDHAZfIErpAljPqqWMRK
I54N7PiXOtrY1g8wgMun3MsPVw9/aB7sfv9rPNYgVI+e7Ae/nT76NXwIO/l2
+ju4QL787XT3cGwVSHR+Bppe1rzLG/lQBcasqPL4G1o0bDVan9c5Cji5XI60
BMgNQDDK1vkW/qu6x8IwgXN+nVcoTh5ZoOqqhIm1gZLxF/zkPt3vWcnshi/Z
+ziU2ZtXM57jrnvYfNlfkBfZIcVLJ0mS6XQKqgiqkwsgkssKFJDuGoSkVA9q
mv8EGle1Bo2/6NKihWOHAuG+zVcgLuK8QDNPYaJ4HrMEZw3XPA8GedG7qr5O
rzc5MIEGZNA8rek3fAEaK6oUFDdUdUAzgyaAaDMiOaSdfJa83cBDy3qxxwXD
MV0Bybf4jrvW4NTUV3lzVYB8DYPATogkCxxzdVWXV/kyAY21AyH0XZ62+8Um
Rbpp0x1whGIOl1i3AaJbb+jdHdo4WpxouqZ9wQFNUO25yg/4K3S/TPOrrNzz
WPMrOYdwCy6AQrbtLMV7IQPq3O5o0bagmcBqJDIDvi5SEnVSGhk8U+X7DufS
1aDELnUY+KC7udpJgmOUY4Fj5B55ULpp7Yx3dlssl2WeJJ+hmtnAfU1sLoFl
zdN/28MS4CZBGxvYI9zG9gAncQuifcX7RkPLKt4y9+U8T+XUphvQNkgKhPFf
007CIDsaTQNi5RVeGbTNKZBVuURSaMLbduhR68I9hr2Fr0FsBmEQPoUXj6wD
zPANDajlUW7QcDFH7SEjpgCN4xiALlguBlKcy0DWdb1kAktOcSPaepunuJ05
rsUJfn1yRvMstrhhOZEX3H+6BEA2OIZZcoE00bR5eZjIdzIaeBlWDXu8azRJ
GI0u7Rp4fgWrB9uF7y2YGhtYieIKJEc4ihNgEu/gmXqPJJC0SPyLfIIP0V6h
tp2uymy9hgZwig1cCEUDa/Yc/sh/yrY74FJwKfwqPU/noGbDP4t3eCZlhtti
vengrRWccxwsEGbVAotIrwu4eWOKQMZiNAyTRsqpxtd7Jl1u8qzsNgvc6ts6
3ALHAbpYAOkCS3FvYZcNcNhm2eLDmbby8cMATne7efMUbZFnEzoWuxwme4rn
7oSfzpuTMzzLuEMtdADCzlWGfMSUPmgM9GPYnqID8lgBj39GXAIOwxQHlVf4
fJLBNGgUrgvQxg4kRKKWC4QITy+BzQPXMDZaIwNo4aOGppzoqGCWdLLgqHWb
AzcKGw7LMUvItoorvsoWRVngOizT+YF46XJZ4JCB+VzBF2WKOhmQNA7nz0yy
SDtv3Z9ptts1GZBZGyZ2VWT6MbZRw51UELOGc97kKIcQ7/IL/jpv92VHm9ju
dzsYduqnzxwcx1E0tAgtsi/hCP3bYZmv4HKG/oDy85+IrXuOwUvWErPBq8qN
oqlBH0twnNwTcbGMeGVLs4JXF/mu28O0ttAzXOHQ+7mtWklrNT4WuAyRRcCb
bU78GqXPwCWQOrewaMwTrrKmqPctnFAZKN0027xZ4x+3Eiwyo+2W7twdWfMW
tI8d2sF5D3Dt2xzYPu4VDARkAVyq+hq+Bv4KggRSBB1weHQ74Ysy4007eQXP
0P6QzeDEWjx5ApwDRbZqOb3Y5It38sCEaK0oyz0KF9DyjOhnt2+Ae+Z4SImu
cZlUmMCVKcgUeRCmRfP1O0XrQUcHvoU7taFmYAET3rm2Lvf8oN955CcbYq/I
R2Bdoib9k3I/w7WWI3//JruiXcB7itbWjZB20CSS67wsp7AGMKIO+cw2zyp4
taWJ6NuwqkBnsqxMdRNYAxKY8Sas24INNWN7yDe8O1+BVxWtnFvoLCE7K6hb
TMUkUc3xvMNJR2N9a2vEVLETdV5FJZzvFs5kATcE3FfVsm5alS1wqg3evOcw
nTXc8rVIdTjT/hGA35kDEkdiejHehIcDDzB9hU+mi02Ny4DsFqU0fTm+auSN
0AS/i/ZEmiD3Z0KmvxXkrO1RRwGWAn0QI6jye61xFr54aEid8k3Qm3Ba1E+7
n4N0ny6L1SpnszPOap5DS8kq28IqZ40dIP8YvL1o9iiqEz3syUgQLdeQneTK
dUgSXcE+b2jGtpAoX7HMvyl2LfWbwFOgEpARwPg9PDWv6QimPEU5QAUKAdi3
nCLYATiZCVJYDaIGCiSBVOjK2dLR5ZN2BzMCkfN1rtP/E7x1keFdcfNZo5/C
Tizwsw8J83H4k1pZoLCFq13tt3O8v1YovUCjMFKyptIKkGQORI7iAjVzhGNM
YLOX+Q7VCxaX1SSZ2Nxoi/ucSQV1aK+4CjqcMuiMlrkVdSPp8RAaK9NZvMkp
KoAHoc4wdGL3E2GpBflM5RqpcxZmWEPCgZGcSwwJdg/mWtKrdVUe8NvAb5Fc
+cKBfhLuhw9CXaJIBQsJr9BipyjaIsGpHYRPUwN3RdHoNOLLFDb4WQZsTOcA
zyzKPalmcJraRVPsZM1KuGDGBI12v92iwiQrGCQYmGYkATGfhFZB+kVptqm3
NBztGmnts/Q7UVufVctdDauVnrcw4xZXMUn0S1YvkaFdZ1UXiUpAYvCLLJFM
Ji3EtJGI7E48Yiji4WjQKUm+R3y0VUckM/1kC0vF4kDXwa981/MxEnV7lj5j
obwVeqfByDgSIc3WrmTk1TC0GtaP17HAL7M9rC68TCIVklO9zcpDAvQTbPDA
WQ47vFdg87l5ZkXIdYnIMpEO4PoxERtuFbSWLXVgfJVXvVWFFmCTy7bm1c1Y
AjwksPXXmwLGDXd8qeoMGhKQZtcg53e8IHwRyhZscyBeUsxIRiCqSVBTPawL
OPoTWWfqig7sGp6/IFVYdoWWKtosVcAOCQjlqPAVsF4HkIyHcgYe2rwl6idm
kONyp1f7Eu0ByDxhSfAIAjEWeKPo2Ik6YSgsvPFURfrQ5aK7tO7YcAfbA5Sz
pasImQJyzre6QRM8wyrQwMiQJFj/Mi7GTLnCwZ3ianUFSBgp8VgZe4ZHsqlr
lj2R4s94hcmOk5gA4w+DiCRK/mJbyBuWEzLxy2CDYrChGwIb5aul7d/0QWxh
Ps0M0MYOs36DuxU+0N4GHWzycgfjY0GM7qJBXzCsQ94N+pggISrzQysOGkv4
d7zr22JdkeyTZy0wuC0P64X7q29nwDeYs7W9wWcNy3MN0QaMx1QkagLUuErt
R/B9XrCwwvoPafqoB3fETMm6Y1vnZadoaCjdMN9FkwNdU3l3ED2HnPW8X2rD
CatiLEU52CRdFc2Wf3ty+fLNxNjZJM27BUp/wqsfJ8ljUOaFWui8xGSfGXtL
koin05vKlfGa2dF1p0NBgoURN9A10PtiQ4YNaZa4+4QEHdTn8CySMW0JB7EV
cxZJX0LDVXz8+LaILO4vmDtTHACRACkw5DbJxV5mkwTReg/6M16BTeA9Qkmo
69NNTTS2Zxkd6Bd5DDLM0a9A/GwX8Ctad5CRA08ESoH9wfieVjgzD7DUAZ6+
+PasZzwEGaesD+GyVoYEV8diQ4Z5oFMc3wLICBhFI0x8Z7NM1zUeT737hOfR
huKt9Q5emUSMi0RUaY10mzYvr/AeIibY5rneLHBcs6JUYYkHPhOpL9xGuDst
jnLDShcxfxkenpLqqmjqii70aI4wbjPfZmM6I7FMai3aPTGaJaYd0IK3tEj9
w5aml6uxpoFgF3m+ZKNsJZs17IMsoSzpFWYH37LvnQzB7/KDmHmaw65L1DKc
lajkHsLmsjyRmrAECwHEgu+wnW870dsGhTd65u7zCm80e7LDv/jWNmd4XM9p
NmxQ0nlt6pLkB32RfAR8cfqDMXLonqLxwR+xoGWx0b0sfs46d561iyBywjV/
BTyJDMpEjGTQED0PxexNsd6QjOv6xWcczyOLIn2YsNRgxwNoPTuA6MmviEyR
b2kjiMj3JOzPUZcjvlRmKF0RhzxvyYKmQ/cUY1r7JDWSU3WZnATZOsPwPhbf
UeIxOxpqbnJpsC2HbMbSR88AKtuPiqlokvESoIPiTnEHaJaUZFqAqyIbk3gG
5FWl4g6M6AtdhdDoyEBGSc0a4SsXqKwdvioaH4eu4G1DXrziZ2IW7P4RwmuK
jkwpl9WqyUA92rOidoGBbHWZJK8CV8NrcIvGqN3m0NJLdj0lp/lsPUMeeA2n
YN0UywmaqVcshlFTE3j9Z7hHUUUEOX/LBhw2V5LMgeRxlhQ0m4oZm78n8UCr
HRRdOzrwIhq4KKx1s84qPSVbdCwS2xSx1z2fVMijWPNvyR5G8h+K327NMKyQ
BD04YA1LFDIr+H/D9y0ddh2V2mHzVlXXjHSh1lxoOYtCgYnTzbCvXK8w7mK3
L+WoN2ZRQnsxbN/3yFaz4Iw0cZA59mqF124WFqov36h6GS/IxK7HWCHDi0Bb
Ck2IHsxXCJzYfYM6El25Oa+IsGUNYWLv3E/dJNKwMAQ5cwdT+XBNtnT135I/
jV1HeZW6Azcxi6uxdrYFwV1DJroFbqk2hWKRMg7iR0gWk7ErzNvFYBGYKhZo
dyKzJfQgWk3olq9M3Fm8WtFFR4re0ZumN8Prot0IX1ACGx62I1fQeIvRYXIi
CrCJap03eBq1hyRIm6d3nNXB2XYHP6GDzOxF4yWe/QT7T+N5FmQVvOOuyLiI
vBgESX363I2fowKa9PTt+YszvWaJi5uQm6xIwZZDTrdKaKDFC7wSf2l2x4BO
3z57dkaaQcpBOrKoE7wQVYcgOfLmJkSQffgA8iJwKpBEkY+jkCRWCbZVwshT
YzMiSUWXFAzr2TP2UK6isas0x18PhiXMDr7FjUAPdjtie0yc584MsDCmiZge
gMpZROt70qRpFDxE2Cr42HGwU9QYiOoSTSMEj1IhnNWwAnh4Yf77Cq9woMBJ
ut9hyAXNWz4jXbjGkIRoB8MqkM+Svd8d+WVZiTk+qDuOn5gMaAWzHVsvVolS
jHrio8FEFnOawfLIgYQR8Cn4Rg1g32egsS3rNfkLm1ys+2XGmvk2K+kpd7Fn
OtBNDQu05ksILZ9ouULbZH2NK0FixBwNGU5E4cEJhyJDPE+E3U1Fa+Ig6/do
BuM4ElgFEJbn+SJDebKQfsR5yHZTs0eRC3mTl0sbIUkeIO/VW1z1YKShWwR6
lQ547teyICkaZxpndl/ycbXrMXE6jtOFjwVenr599eJskgxPrYRvfvhgNvVf
fzH7YpZcsqho4zHrcpMvcjSsN/karuKGrxryOExGvbXoE6yd2HlPJWk6CRUu
JwyU7lfZsz5xvg3qG1FCu6n3JbpS+sIC72l/8UFDKmv4HKSBoiYLC67tERK1
+QbqB6ov1sBx2blnMjmPBc33nSNLPH3QIcUTTDiKwMQQFDkkogAPAUVSPilq
CY2LY0Up6AAX7TlIIunlUxFxX1YlKven+O5ZkHRubjQG9cOHCfyF8Z74W2Tb
UEN4gztAwkDoUYwHmz2mxuAzE+N6oGTPdZBteqqktirwttzBqnTtGbEsePDV
5Xds/oMDDCIqnCuaZBZNDe4CWrESQ9fSbIu5KGa0ik0SxMcy0TRE+7fG+826
81m0vhHaKImm4S9sQpPBkGEAND7vOoDVQMpnsQ3v2xmFxuDfsfdBQ9hUuu0P
sYhMp5ORFuxajNuJg3S9vqjbG7XM5hpa+xCaR+poOybWrWgyRSthG/F7Zmps
cwpsGmvAQslYyEy3OYYBFu02NXs+BnzV6NYQJovJUnjCJdgpWy6BDacj1nV2
+5NJiryUtLd7uifgxQJZuvhJjcijCfS5CQcw+/U8olbCyPM5XAV4I2/reVFG
YpQGQU28iUNYQkkG76q/+6SHzsm+hu/byXd+B/KFnkfRii8lWjFJbm6wBQzC
AG4NCkWx6ITOsWHqmyM05qAgokagTuVOwwd67s2gKTXeQ/bv8JNmWXuFqTrp
bCo/M4pgtT/l78ED/hH6FBp5j642UDyAnbxP8c/g7n1Pr7wPsUL6QXwu3uNQ
7k0/5zbvyTsUhse/878vrytoYuwD/jtxT8tHLHRjdJR+fg96+Ny6kQ+0a/h0
2Ag/QY/ci9ru/4wM4Mizt7wra8nGfP4orCf/fW6RH2n/k1tGQOvZhr9fkaxI
p2vwySdMxBwaYTBOGOfP7nmK+dgFURkjGY6CH//oRY1/ruyf/od3vRuT/nQw
qbF35Z1/DoOzsyA/n8cthHftlXtH+70XPzny7p0/Y+/299T/eCnwU/tVqfG/
Yswf+6M7fZXo5nw+soPDn/7mM+cz+/udAxjjefcGO3n8p08E94iTJzeP08/0
4kihYbQdTrMSVJz/frKgiJ4TzkT475hcoqGLZHN/Dq+cfGCpAI1UGL0KjUgY
wc8iTWHw4xVH0IvWzdc12Z8oHsNF9rHWES6yWfKaHqFwiFbcpGR9FKsssDsJ
z6cgCUooGHgmoUnJmUSxV2VUNTun5zxQdAR7gcncSdu6IdF9X1DMEFylVXhB
RO+6GXQ7cY1ZpsOSFLEqzBlbbA9VXR226nviQJAooovW2GgFl40UwpEVUdsj
Bsn2nMVsK77KD2oqPhaQe3f7ew7esg4m5CUJ94zcFSQm9z61G1XDEOHF6M6i
l1QiYF87SlYHDmJ1l5e7gMJEI5PRiD/fO71EsQ9KG2n5ZZkv1SwmPTm/OyYL
7Occ/NqVvchmXjlJ9UBgixGNV6VRlFjj+GTd5lsnyNHtICLX8y4j0dd0ERsF
izUYbWyeTxLkTPCeJGgC1JbIHbLec3yWaOPWlpzUuO34fWh/3WTb7dj78ZM2
ZhsbG+ltYLIEw6itPjlmsV9n3x5ZbU88aGkExTvpBZYfOO73XSTATy0sRiM6
XXyDOh1UBZEHPoWcRsZ62/aPTe0WSojX7xcgh7hBoYmRXu4mjOilT6eON3kO
3Fwj50HTwdVZ7Rt6cFm0i30UujESbY8GoutqeNHc3LiQbGg4ZIjxBWBhkiGK
jGzMZcmaJ91lYsa/rtO3hx3HyTiDOf2NLEwZ+c1nwJ06fBKu0fNoaPrFNK+u
8Nbyr0n6ATdHzlUMoK6UseHyejM9cVn3WPKW0gKjZxb1tKwXegVzHl5HIW2X
Fe+FGRst+m/jO8ROhu22nqy2c9pdIgXuwZ6bJS9pB3udyNsUKGWR5Hf2OUlC
bCONMteAyMi6SbvKASW85GV2QIvD1NkXPnyggM2bG42pz/lOB4JJUx6yNY4x
ixR+O8MMaB+F34YTf9tSCfm6aN846YRNI/E6OtL8qb96fWX9uPoRiaR3yaH9
h/r6yOhDx1o6rpqYmHq8gX+95bv3yfHpvvdTPj7M9741+mPQ5Gz0sfe6vb6l
scf8CbzlsZFxOR1LHuut5OekEQxbG53j3/vYBcdCjjyWxs1JWO0v06v+XH3M
YzNbF9230cfeu3OqZoLRx/zW3fLY4K+xx+Ktuzf+mHH/qMnkzgPEh8h0PX+v
3KHvHb3GUOnTAGliP7T7KoCMsDaUjEgBmYxfUa22Qez6ipUHDVLwgdfsQLMk
DmaVF5K2PD9QJheFrrAupmZkbgxDWSmmeEJiGTu5KV1wLhm3lAzbD91NKSxg
iXbeHNjtIeTGhjANyp8h5Y4cPiJ9DFdilhyZPzm7eJ70qi5vyKApJXja9NIE
tQgM94N3gAVjLlq1TCiED8Wu3QaEV03DcMKrRidjMlmx21DOxhqk2W5D868T
VV+cymPu16pOy2LLLlQKmaJ4FjoEErnSKcFYGgOlRUsWQx7PuZdMhVkneoUF
gae3VhMS+TTx+PYIhZZCFNADlW/h1sdsPAIsgrlJjnhymr+hB464RlvyjbZn
3hdKBIDxzBbejF4ETP+bFx0B2OQ2GO+HRQGBfPxzDGlbZSDQTOhGD85E2XaN
LRfvSyZ53GP09GysK1nbrOHYTFKaDECp5PyeuzrGl330fz8DCWlpnJhnPjUc
Mw9gBclDXN3r2BzE+UJ84qVnTm6ekH+ugp3IlolQV2uZeyGQCsazyvOlJVEJ
yxAdA/pDmt23k6NUxOFxeCI4AvRancasNaCIlWmiiDQJra/Z6UlhENewwujz
cqOC1cFRSbwFReZGKQCoG3zLQmak0UUUe/PZmByaJE8OTvOYRHaMvtkhHNxz
pzUg+YnmQPkWFaWekABZMa5AREGnNIz2jL2F87rrgLfTZ30tZsMmrfF1VstT
MKcZRUpC/Xa77yQRhnxSxQIOBunkNfxJ2uY2w/gzCq8CRkw6Sd0sOX1ds8eD
QKQLoaliOtCercacqexaVlLiaccBdzb/0Tla8mkcUn3vjrboy4kyQNzpeVm0
G77TdDTX2aElY6XXDW5uxF/doOKKqyEkE6cr6plWvSG6pZGtcCAyJt/xvs7h
uuRQHsFmSInc4Gah75kS4gjOuA8Li5R4FKGrVdZu6PZmB+iqzNU3WeWWRT+6
dLPkO7wTKYPJSRzob0d2McX7tukwpBE2nO4yiucJG4n8hhYw1lY9ha7EWV+h
CVsmGqV/9dfB0bLYpWkMQm1quRRzjrBBswX3bd2ycx8+hLzH0/MzmAddMG1X
y2KiZDOlkEqRQpLTJ/gYhsQgnlEusTanF2c4Cgd/w6LQOwSxLQf+2747Fj5x
xlham9cvXyQivpqfVr1Ow59ZckSiHfkZda8d+bk6MtrYt+kfmMmo/RMoVKtt
WvyWkd7AHwTP8dg8/9m7o+UNtWmfgqTwHldsEm3MoI+R9cHN403qPXCbBtz/
+ddbtN7ewh1RpgY/Tmu5re1Z79n36R9tMuNN+mfv6p7/kbvT3ulp2aPv6K0g
L/U07iMvpeTDxv/31StPDvfcG2G3b1GMx3pDmT16gznP0TeYREa3w5k1Rrbj
iY0QP70atpyOb8csanXs2bANXnt+P/JspDS7P6JVHRlDHJJxdKh+s+7dTmD/
2pv92GZ/7pd0qJW7vXXWGGQr8WOyoVcxmVhrw0MVVsOdU+Iqg2kMpnD3URp9
7IjRo/dYdHiOr1v0c8SaMT7AT7ZmmNxzqyEjlrnhC3Fag/oGYtsRLZOcFbDk
qveoPpNIZLYlwHA25prsACLHuG0mICbuaKi+nalqjUBUPtvAjN183DlyuK67
kLphQCMwtP1ONZ/Q8Sx5SfkXfiwk1cFgMcEjjBnxucX/VXmDg3UhgwTKlgh9
IWkGDeH0i7uWgUz4LPCLTrRk6wmogmgU4TXmqFz39nRxWJT6SaLZBW4MQaoN
QllATBOcEbGVOxfu+aqTkH0KAzcsIx4DS5T4LQlhliyAY9jWKOlvMegxE98K
q2WwDqs8I0s9Yh6MCeQc61iwdk7ZdJT12bYIZ3AIC+MuE4zznCMAJMqFhP9T
oZOsPTuucY3Js33H5KjGQLO3zH/xXJ7gnkAXJ6B1kSIX5m7xp26feeET0udQ
OSsZiOMQAyoIkhmnsOeRCVF8i7jwcdw9n7el5vR2G0RYkVbxa0l9t0x6bQVd
jEGMztIOjnFO6LGUQ1BVwcnNnSIUHyzq3vSg6Pj3JnzviBGEjWXXlAKyoVBm
TMIzyAAZeBJQP2i3hhzCiCbmQonEMIvAyAcLR4VhsinzNowodwEgpDwz8aTA
LFMxVIqq85hBG6HzMCS3rcDyjDoJLmOwzJNkV+7bABUT7bcb6u0tef7Fu6/6
00INNLBOjPCpXl+yD7xT5Vq64TOjlqNxqyvb1qoobjcL1qYxaxsNiW1FDI4i
NLUpmmVv5mINsB3AFP2M+YRmCLqOVVsEXVJQU/x2S+ZL1i4wrxfBF5BRxgab
WYowOlHix0b0Xkv+IvAuNGnxFuiaEe35F+fE7Me/CyyS7DCSYs3nIuAssfpO
NqcrtIjODQqk7nt5JwmHAR05SOwCxhydnh94xM/A6YRFpyTWml2AgrZIfUY6
z9TVPj+EJY60cc0zF6+vYhHffNZ3BGPSjn3mIr5CgIpdQrjuOvh2P59aSBXD
yPLQYQ69oCWRN+Z5ACux8xLFlAj2Uhu3rvhK9tmBDXZ3xw04dhVu3ISsR9Hb
Y1yrYxADJJbQ79BCmdh9MARKcEJH3puAmrT4inImvhnjyRkMlX7O4QoEB3ug
UBOkBAprYPbK4gkuqADccZac4A/niaXJmeYP75USoII2cQbG7Bu+F1nTwMPT
dYPnlpFI4ugNvB3atmAHVaCOslZopCMhbNIWB+xzOgFMGdeR3r03BHlhIoAv
b7XXTny2GKZRxkSghjEYBfZFwpMkusJ8SaiS+6ob2e0QoMTNKPyfUi2OXADI
svQEUaROeMScQW7bkQ62I3Hbwe2IFDhLn+y7/ufjbWF/CXUnh6ssqnchXQI+
2aJrAnM+ww7Mkje1vS2D5RVrY/aPFvcwCoIMYsjXbnhZyx5fb9CsLztN0KcU
vTn6Si/sbiCySyt8jyi7MoE6N9oo2thirupGmJ5IHnD8l+7YJedya0Y3FhH0
VEnc6H+MHwKB4S0/cmAQoGisHbhu97tWQ10R47haZtUCgcBq/MKjahKAB6MB
YITtbk+bTLCWkvGNOdU2GulY7nAgTW7SpQAzbnUuTl9ig4qyKcMjOGi66STb
OhcH8Piq0GyioDN7h4GKxF3Ko21HNjxgfeFodMNZCqHxKzbHutJh284qMXNI
Uzz93nh5oOz3d7nyvab4FGMgnyXkKzAFHSu+81nGYDqVCS89NqnEAvbaphzR
ckeY2S4Q9wi58Xhjwtc89YQI352No6Qfnhkjfhcf1ku+cgGIBpIrPt3+aIa2
+d7P7abd2dE8F/kZxmmN2t9vN8F8lDH6tris2zsfPOSZ4se90JfZPm4sH2E2
f3/H9xhKdmcz3Igki0RPS15TQvZNtS36n/D05/T0e51xNH3fiFge3ZuYRuRM
tP9kLQZv7pP0cw5rS9737K7h117wk3wVUQ7bX6WRmRu5TjYe9z+FN91YLmgs
0gi/4Gz+74eTt78HY7FG3NjZW3N8JDiW2SxkVsUjiXvudegptz8WbmRwzka8
ZNQRXJMj3/R255afkGTU9r+hRiJmlp4fa+QUOTEXwwRm9i3JRuhCw0Y+ymyL
M1Sgvgu5dGu0ZKUfbSC+Y6JHGxnocbc18pGTuXWiwUIduPxdyVXxENFGfVmN
XVosrdmGBTFb8hsC4TFO37jxA2l/VMFjIR3bGup1pxoOEtOMSbyxoM8CYSA+
L8JyCJlPQboIoUce5pIRAL22jCqcGBAJjoPBPcdCmBSDgdIlCrcw3mU/cp8P
ZziiywTLVpkduHqGk9qHu8YaCs4krMgg1C60WjSpIHBjhtgpvne25ZC0mcA/
oDAGVISRIizkcyALY9v1gDzoK/oGBBQCvEJ03XmuGCeSUyP6jUsM++yz9DIy
11DtKfR1C+ZOQFjDZrGYCGqjJkqH3IhUQM+ChGVJQpoVknBWCGObpWJdbjNQ
0xmU44W2asTA2hxHO+S9AEJVKmwIKPIiuj4ZrsTUpvjoFvFFqMmcdFgt445w
uTTGrxfkJqLywBIUb5AsFK9yMqC8sDG6jJ0kSbKtIKyXyKYJS6Wag7gKMp7f
i7iRKAFnJp6QHicYaq2RIYWqLUWEQglYSZTG1ysxoNCDp5blY3t7jWDPnKql
iOaJNnyG30QIiGNVC+ig22Eaza16Sw6qeNBkpPJK9Via1XAJVN2BxY/amySK
iiLUQLPj9glsyTKvenMKyy0FVjAXKP9pV2aS6JH2kpPUmkXhRx6iVxJquXuB
7XcpJEI2B4kMNegMqi0CilT/HGBe4ioTXeagNgtl5O1+2ytcFJ6nkSElu16U
DoNqTq2xVwsbIxsLgYOFnqxNqoOhga1a2IgyA6UelZQVs0Sz/uypYe3pYxpG
O1lsOifNLQC7cX/HepPMZVyEMfOiwlI7IHutE6MmuAWh9VKoNjyKpbwofSgs
MlDnLsN9Y/zL81Z0TyUarWUmFINIp8PehLPJeASGWtFcNKmNSrBrvZKbzzw1
ovpr6dW0aLrnvvCCq1VjtLH3uU4h2fkNpf7x0eDXyNpQUsUI4KRzuCHRzwjM
d9GVBztqhPEobovwXltsC0KiMsKvarr6KVmdrH9WSIIBDnsnz6WOvxHB4tHs
Nwy9HUdEtxisSZIcdPP4ZGIj0YUbnbAAsbQeVwxmZbZSl28oxGbjVSeZNbVX
oGeulkD8HFeCL3KiyAG2G9F6tPvBd3HqQh3lSjtDCceH225R6JjnzmZTuPDc
olqJp50cdyT2sRXN2+clN53kinwZwyDpabg20D3yzCqrZZtlgAF1R4tzSBVg
a4bTfSWs4nFwQYwifd22KETEzvLecc4KlQAgy/igrENkVyIeImUYuERDiWkp
PsvdOSQtD1mO64y1GSSw9H4jI6ciW/d75ErzvWB+B/MdudsmH51snNiF/LHr
E4p69ZenJ+u6tUm0OhBz8yPVvTRbhO6tnjQTzTiAE/SBCSYR4sCRZQgE4slm
dHFGMqE/8XBVBDuP1TipAMbZJNXA+Zi0LTn74/PEyUM9XCc3pU8mgn/kFI18
aF5OU7lzSmFDNY75UzmgR2Q3PuiFXtRNqa6EjqsN+Ql0/yvm1+AsYBFTYpUa
1kDJOSgtSH0Mzy77rMwNAYlxHG/jl5jsAOHj2GS9YyrU2ChWAghM8UFcVlHU
9lAMg0vFBJHxyKT7Q6Eb7lxlI0lQlDnvipyVGVP8HY+eCDqLXK5qTsioUO99
LuZJJS91qBQrhzF3G+REewJuVCDw/p6y6iDSoYyN6usJB6eiHIFz//bLh8y5
3ZYaZD4lrhFGZMiscQkH6VUNN6VEtnf9eDzHZu+1ll4SEZletCO5YDATm5Yk
EHpmu0yfHB4HZ2zYJ/5CRwjTkkZsTj5i5ljejjD9IF8Q5w8nP0gimVYiCigW
AVxvEmVjAfehOrGdJHTS4RMZ8KMnZhdXMmSXBk4Klxz6G+PZOV1+rIrSHSLE
tcm5xpH7m+9vXIkBEpCR3uSim2EwwzD1W1lqvJ/N3pQ8nkhLZYHDpK36wFA6
uHXmMyf7WO4tg7jcJv3csYvxrXZkpiP34dFJL4sGnTc851g2MAF97KZu8rXq
eNXQ9mgM0djt37wc81v3ffCtLkyf5cYLoGnbUnWChXz50JlnDcWCoVuDKST5
aJSnWTq8iDKB1afg1aSXuMpcWLUkUpzp8pkSBO+VyITruoTmYy6RkElmS8EW
+hzCE0uJb1JJWbMNN2dLFgaeYdFyDi+CxVMtPDm8VDGkGblQDS+FEjMluk6K
Q5Lcm1Chc4xeksoO1s8nkPwxGYE0fVcx9JVWfb35zGwJPahRDKQjiGP4aEru
7WWRIeyP1SsNRdw1lsYzs6Rv1+wLq8REPfaNOBDao9EvhHBvhsLgye/BSjFU
9bHjOMTVmsXVJRspzEs6+mDyFPBIJnhSwq/roLVLgRvC20ZztAaQhFBXQ45h
O1+94kUI+EYc6MhKPtW6wRlHmHJBw6RwKsFBJ7sJKtrwGMs7SVShWDfIWe1l
bQPiglaRZZtCXMyXo1h3+hm7IiisnKSppcEwSwAZNrqdl5lsInLMSlHs4Rjl
iTal4ygQtaADVaHiCEF8XOSuyJKqwlFRLQv4bE/xJ/mS0MY1Jgh5AzSMuEel
6iBonW+D0q3lfhGFujlIXVuMscauZSDAbDiqWktQRDcuq+eyHiF3nvRcWlH1
hUn4lPgbkmtBP48qITRUoUTmvyl2JLhIaT1msC5+D45Z0VC3xRa4CktCCRDl
Ox6+jSq2vbR7TMEuOAzYMLP74oUfBKawxaMQaD+2zdBGitRjJQJ0tcmCtW8n
ZhVzY8UDhEUOM7SdTRLXrcbhBCbSxRNqKXo/A/a5OHDsTzDSKzewx6P4bxw2
zWV16Ati4r+aF6CgpYu8kVqY+ZkMJ/EUOEv6a2xMz3OZwJwGE6dh9/V2dfxJ
ya8eKhhxxggL0fFWiV3ji7eNBmuXNp6HPjzeLAaHJKfJmhgnVZQYndaYiY/C
5YZG6xjaMmJS4hIYXTY0AvNdiVZypNFZ3NKCUTorPWfH2PwpV9FssTbKwdvH
mZLPElrGGLYuTK+yBVW/mBNf3aKO4Q72Bmw1T/2AyYU0MmpjGEMMSWi1yXNG
DoBTFXZCHBfU0YpRz0hXAjHuV+lzTFHrISQIYAmfYKrC2jIE6siAlnu7ho2q
8F08AepWvF2ow1HggsD9WsOWXJMyd+vwWzXCj45I0ie896m3iyRVEeL6fqf1
8D5S9p84Fh+IFifLY9U6Kjwlzg+hGbkx2zpjCl/VYFiH4mDsq+wKpoh/sjdQ
ABm04LMnM7whjkwxIFtWR0ArkR2OLZ5F2GM8rmROwWzrfYPcQupnqjvThUgH
ch5UX57FzEt8G1E9x2M9JJHIQkVjQ1U/QU2KTGR+LnTbJfFTwePKLfKqUt0L
LSdsXdramuNkGvBej1c7EGkR4xGKoA3D2+SQED8gZUB18C/qfT9bFh7J/liP
7iqTNKVRWzjmtPAd2ztIwzjSONRQP+2Fz4k2GQyl4bEQPPo+1BXs8bPxVvVT
C6siHHwflfmv+lyAtONmhkDwoX2Fdx98ceWnbKnUPXjuYRGC4chj5Id/jmPL
wmKNDPK9R2uLpsFd6LEIs9A1PbIx8pD7jo83/XVsG/oRif6nhz8RwtWCUHRr
tFos9WOsGqgCT0AcwEDzajm92OQgGjiVYB6+W9B3t6oGwgtMNUA4MVANpGam
wrnVJUjlOah7vnxhqPccukypS1AYQg1Ai6zSOpwh9N5nLiY56MxWUdCgZfKf
sFxQCB/SgXEuNaVZCpadi+HC/S26vQCCkpKKRZzCpIBZkyVMq3LSQGbpn3We
aTxPtlrrbGnv/TonPGnkcLZSbeSajWtf20P3hrlYPRldRfLeUloLg1B6YrG+
xqTI7z0wYBWFo0fFSdTupQaUidPe9/PJYvG4PMcSatE5IZVzVGGPDonEYNAD
jEXoxsBZtyH+KkiFQzE7GROzWRwBXXKP9pbxW3kMQ3k2gpjdF0xH5aO7xVNq
+e+89RODNbJV8CmZR5Si+V78G8HbxzXctBzouLyDANEFq/+5fzWFg4aYc7KD
+dL2TxVSb4I6jAsYHqkwckQq4xqKXyYYooyGpyUjRw0Za0RfIVnD4ygKPEA8
Ben7V/BHtmv3peBH/co8VlmncHkh1OrvFdeSb+prjAOapGXxzsonvYqMO5Mj
lEpZwsIM1eZMMlTPtgfX6BJnUHdULEywqrFIeNrum1W2oCA3q8WM/uMtOYrn
iH/JRddGdwvXOOgO8bZofUa2rWSJbAtBgXLFXNE3PmW9MPoPu5MMU3SqIhg0
QXCJhId3yDXsaOnqcB/bpVnyBg05MmHjmnSdMEZIAGIoViOTRBaZeCG2Iui8
O3KMPkZKOvpzTETqy5O3NnCrpPnJQ4hFoqM/kXD6sYhbKLfensUUCbRH5dnj
PwL8MxB0b3/jKirMNSL98pfvo429RfQF2TeSII/Kvj25183fOlAaHRN8RzKZ
Bn+L3Dsu9d4m8R4XeYPIxJLp7ZLvuJArEvBFCJ9tk+RllTPmsIbTdrcKwsGp
G1+gKhXZwSBQXRdhvKUw0Xzyn/8hwiC+OweVNsD/Gnbp7D//w4QlBD7VSGLG
9qVrirMTR7kfLAwKWyx/oamKZETOT6VA1b1DhVls6oJld81IiCLmtKScq/gd
KtL1rFrEVPGF8ETnvFTOI/FWF0Xi78mElUtgUa8ozkoAR8e7hFHdjx7QAbe4
hs+1Ci/pACAQMigI6S9VrhaO4GuIpc9Qoz2qIq8VKesUD4XeCCL0yTu0XEmw
WdzRk1SAxvK4ODmKilgyzBTZX//zP8Z6w73QiGIu903kxH4rWlMQieH0ZlUO
6lBJF15RaVmbLt4DzY/VkxF8hr2UccZDcBHo1+Ii9dfaQ3OhJ7ueJKKO1fiF
R/wC3cegMLV3nkW4eR1UMmk9ahU2mK2sdeDa5Nf1tTt6HAUjh3tjSjCuim5x
UzuPSOlkY5duXW6yRfdGFvY6EXcNmQvHDcSoqJBXht5VU5yc2VtKiie7ksLk
g5AU6ky/itMM+tW+hzLHuGTxkfLDnVJCfOv3Wu2XFBze+Hqvf9ztfeyOtptY
p/v5R07XfesNRUPacA8qqX/EcvwjJ57GPx9DBQNRZHzRRgaJT0biyKfb4cZQ
KIMtLiz8w/QWQ9ztWLhHxRLPCEX2eCaM0okZJHikry1f7Znmq918Ru579Sd/
SFyi3tH8INPVI3wfg5zhEjqU25EM0zZ6mYDZeo3xTJ1EsggAU245O7VBvqvH
mgt0403jYkLGQkK4oLQ9TV+Px7PQZRmBMtuNhnr+WHmo03asxBTOIQnxF2cw
gmJNe4C4f5yjSlASpcXwaIalFuyZpT5jcBBMFRXg4iJ9Lk1MoBmjsmWs9vWC
skUxPbIcjVVTDKN6wwkycNV9+pg8VrRooRbs+akDQSveSCiKPKnU5EqJkYwh
FMcITCAkoRADMnd50BqF3CpIT9i5V62jwBeeKL6C9eDrHV27AbGMr9LLV1Ny
FybjUU1tDiuDBO9h2dSWldsYBQoTSLGkZHqynWKFMwX65LUeJU6NblXRgyCw
sLhHvXiXY2dfv7p8ySE9aDuBDzi6ZY7Y8S2dm81hh4FcLQZn4cszlgewbgeH
k1m6YoTavyKbclENUlyhgRcRJqYURWyj1MctaB/1knYck1an9WraLmruEvmQ
WyYkCnSBk9UIgVbRjBIZrrndZGyBooIpMQ2xmdjSfnv5KkKG7Ri3YsXBEtgp
vYTDUSIs/NHxhGy4EY75GQtcrENiWl3I0uaErThGM871WmBEXkgBb53Jq8cv
GVLOm8xTq70SpScMwcaSO+JxUzpK9F5CDnfcOTHPIuomaYVUaYIX9oRz1IEm
NsAlTtixLKHtVIAO729ODCAMMv84w3iyP9wt6s3Nv7x+fvGbB49+jYL2yXn8
jtUKap0TvONDJ/uPwBag8O7nwFUTLKhDV04LZ6oghkOqENv3+SGquoNOeyla
Q9UY4HzDjdBlZcIISww/qMp7rzn/duzbpvo5SS8QOjZmRvML6TM8qdlJgI3T
Z9Qk6YOWKHSsC1812bWbXZKVtZWBCCExPPSVsdmD3d3oRIhel5JCHOkGbHGb
M5TXpSbKV1QyWIEulaon/T23qBgaZXvYYsg+9wLPtgkRwNuLr6dPLy+eTd9c
Pnl6Dle2RKmFx/FQRZgIoJP+y+X06axroZtVXhXrKfDudrprs2lXv8srUlzY
70UDYltziI3RmzEieQOnNbWVIQ2YdCMzzr2WyAjZsNuVogpgiBHZE++mTpN+
p3rOuphAey3zha2JPhzKlqUX7olzDco7U6dbUlT9Mfsmd1m36eEgDO3QyGTk
gJia6SNfSDHfMY4YcgqYkFwQcwJg0LooXGRqFVW8moRqiEyqwWxFLou3377p
ITm6WlbIDjBUexfcjN7WNejYjl6+HJTdYprGa8KZF0L+4XDimCbNWMniqQMR
EnNbBEMyw5QiOIHwZJlf5RRTqhH+k6EfRahRPEAj3TEAudgaRni6B2Qe30KS
prS4cjJ+WcR9CogsJ3xxtvxoTqeIYxrexYY0tWaNLYQasRbmk6J7eNHpnYUf
+TlKY0sPbjnPyyJ3M7bMvGiPkrE9kopEUvgrIn8O40bbCRphsoMYU+PlPDk/
IblGCYzLld41K898Tp6cTELJKuzjCZXEol3G0IMscsAnbEg7t2I4WTg32ub9
vmPucgUvkCOZd7CFPjKPTnsguycBsGzqWsiDHqUn/XhXJkIbiAa5alXxGPXR
tXW/RNPwKU5MEVSGq2JpZPbRYXwZS7WUKh5EqWFPDoa4f8zG0n/TNeooBDZJ
UQtjYWICxs6o/BHoctwgBZXwyqIuu98tSY4QL33qQdKXhOKt66oh9X1xkLG0
jf5kdaN82rjmFDCJKzRzz3K4NJiZk8Db5GJLDmk/YyIbqYL1joUIc3djC2Nh
bbdVseacg5B2d9nfuUm/UrpgngP3rCR41XMG4QfJK6BIGdwlR39Tpcj00od/
v7q8PKNqhlxRqfAPukYHpedQWiDypYUxRCEDQii6QZAKFmLE+yFpgOIwwdRG
TyIYfLmvXNb0ToN/oxgUXoB2kxFV9YKTnYV42NAEya3mVDRyI6xR1yDsci2Z
TvkVy2WTS8Qrxk6WUsprfK1PfYELUWRJgO8d1iKP4xnPTGgct9cLIlGUBaoS
Iy8fy9kRORGSWULxYCHIQuHxR8cfbWgSFGOrUigAMuEE6Y2i4Gx4w6rg1ZFs
gncpLk0ka5wxFnTMb3I6WiN8xHENG1xLfjaOlNWZuNy5AcOIBFeLcu1dJ0du
iqDihInzGwg9h3qc81oMeMpsqOYK/7z5rNnV+NuUjo1UbBl70lnb7uDMx+7H
ibs94gwinBffMV5XnvhV50HwZYxpEWN3mTHtxB+fj2BQeA9HhSoniSMrCUuM
SnhUbBLlFFRn2prnEig+CVH1VPkyUDLfHcv8XutSqgXcxScIZSu665mxaKVA
TJDaSxVJVDEmibfYIFA4Krk7oUoutwKSH9lad01xlS0OU+2EHejO8uoy35hi
jNZuPrNSiEkvT4VtHqfaRBs59XpajcrWuj/ojoe/BRYgI1FO8ZcZnKKNaV5l
FDi8iQdOmKgq6j9EAGOpjoumu9QA/qVsSnKHUUbIJ27RrHGfapKJLDLpQONL
Rk0wBE0ppANTKPfCIqMIyNzJbp55YlIekmd5cKzHIxmcBjk9RqGgNDRLQguA
BokD1tKyQiPoiiqRRZgdYvDP3WcfPpzNYlQNPkRqQKDehwk2xjlhwQnhnyPZ
iL10BJAJY2tyBsdLtEbFaMHsNMa29oZ1MRyY+kmhdlrfxjsE7o3ZEZDeOLLS
r4GiG7ori4G4A2JVdF56KHytGFdZFhNqaCej9hI7QXQpKyEkAyrpmVOcVnaV
93afTE62Hqc+vjReuLPj9hXUR5C2JHdfoDTxH741eiVa5W7AbHM6kK69hNc5
BqCQ8kQwJ5JcrLaQp/qMg2cSbJRdXAetPaWBjpLjjwHYB8Q4F53b8lU14uKb
sHAhtU7PnFoah7QBMnRTX7N6P6AiTDmjshlxZ20cz1uW+nni1172386vU8XD
G/6wW8CohDgFLmDqMd1eFiqrHRV9rqE7y5MjDVGD50MIZUthw4ZVj/mAIpuR
5s0DTDxwqjPf4g5FYHd87sX8iwzeCsNUSUDEx7Vky7evr2O8D3j0PQb0BQaO
hgcgXzbXJn2oNLR/SfCLLiXKTrSGUqKEBRQ2Z0hqEq+Bw8fNqDxAQ7e7EKyd
NpLF0mZPa180JNnZmnMhL+qBSER4aRhMRQ2wA6oj4D8TM9uPIEwMHPhe0uYE
9hJ2+ODaoOlOLLAs8k5iVjXerORTpJIAsPhyYZCNl2ydI9zqrmu4VzvKCoFP
QvndRJRF/11DUVlIDqDJCDhe3xLpZMBEzVdmqzPY4voa5GOuSayl6Kl52Fn6
vaCzi3XAR8xo2GWj6TXGWvja5uxzp7zJBcFp4EuyuBB/ZilGmBWWS8QC3ZMo
THnFR92eLdrEnQC+KjMGBrRnuEgboQzBtUI19yj0bhIWUhQuV1hQBkfiAfp0
ohtOg/SrOkoMCOAqhry8JfryCCKIA4oCrHF6CTSMuJKKMQ2s6VrDKI9WRacB
08Yik1H7dXSvS5V5Ei5qQl2KLMqxFb3jTGchFHw14fJGGaHqBJsNXRfqoNJY
zL5yKF6hPiJWXB7SH1MTc6Pc4XkeD0lQQtCHju0FX0UbX9rOx9CSxYXU4AVs
CxdKXOwbE1CYgy7TUksqRS4iDQkNKBFoD+sNtCJPbT/7KnjxFJFwgEhGyAlw
aujK0KAE5uiGOsn3x4jizoyB/d4FOwPo/f38ryiAcJG3KDEUl9BSsCKoWapB
NoQZ9hVw2rSnODLinCKEiYTqjjphzYRohFgvxtsD9+saueO+krdhhcS+QQXa
qbIfCNLnjmjcMGGG/k3rQJq4uZnuFwsUxQkhM7fA4QBtOjLne208lQBv9jjB
eKyHjH0RHTS9yb30O7486rrUXiVqQ/hsO4LRREd3l2fvekrLCBq/6JdaCHNQ
QPEIHD9M6hGsMUhRo6up22UBPFSSTUDf858W5b4trnLWxI4OT1mtFp10i6c0
1uWu5E1vfXCMX8zS8zSYCELTd7zb13ZCkg3HkyNVeNdCb+SSOY92ITjdBNLb
NXm17jaOTlqOKTD8HI0rEAIcxIoYctDoinM4gU51hFrQdYSA49m7QNQ9nGlk
2XibUXSZEI52cK+NYSSRUlfw/oZTNS9X6cig/FU36atPR1Yu4MdzGQU3QLqW
6UaWIO3RldCas+0AtC8OiMbDrfe4enpGPMV0mjlO3KzNMRqolHMVmswp+L39
lMX7mteI7RG6efjX6PxkIzU8yOE3p01B0DVsGZ1Dq6uiC6YbukYzqztYC9SC
XG/XORYrW5pLxezm6bLJrtEITt4zslqo3DZuOwtmM9xHk/H0CLAtTaXkAUyu
ReuxHtOHyRvxvXhF7NOaixI1grfPEL3E4LouTK910t0YwK9HADOnBcacjhjA
k7s8ZmqNv81jJnFJZt8mDhLbsJGT/K3W2+TjrbcBEqpu/he35KKZS2PmXmjM
3M1nFnwbQ80FBi0g5wi4xgEBg8A7DeVQpFMJAYwQ3IJoFEKcctAM68aJSHHx
k3hiWhN7nIObHGamZ83FkvA11vwWrjocZ/KyXAvMDOhEFM1DgAMZma0c5IBv
7Djw8YrMHQsUef+eF5+jibAY0gbTR5/mJkfww0nPuCUVHCiPyTRYYm3GcmT0
SCnR4MYxXaPwCAGKk/dZAyyLTII4l2SDKwWnQOaojGTuK4sPboiiVez13JXg
zUYELS0pD0JTnIvTl5OOlrNFYsAK0OSlDQBJGt8wz4PZ2oUKWm3S4VYlaseN
bkkZJxWnLBbvNFo6xOBo/dYQvS4FfV2iW2SNElfDwSApXQDImZsKmcWUx4S7
khuvCL3+CqWJKQaNiYEM/Wabmlqv53RZTxIUktbsnChaMca6uk0EltcAaZUS
KOBBgqPqp44uIlRmQzbasZmRs8hlXVhyKCqtuMmtJJTsB51ckQCaU033iuOx
/TFJ+8dEzH8rypKsF7DB0ZXLYtbNZ5HrgfIoorj6NoTI9tCf6f7th/SNeEyO
gUKjfZVtdHdhQi/6mNATxYGepGW2r1hUZeMP7E/F8JUSP6DQhj4qXj1R4hHh
tdqyrS+urMQmbhumdBuGSd66onIuNbxiXdaHKyNOQaSR2cbHM/KaQvutxQOT
8sHY51Gwd0I3XZdrKDCZPTlu2dUItkHr2Ej42FMhWR95QHRCKx0NOsFrWbRT
Tt+d9BJBLIjIYHXJGJ0rrlk9SBsxLCoFd5vnfbjLxIzVmt9KYHsModGHxowW
M7jRexJaL/dlLJtFolUIaoWdJKkU2mAbsrAprs/Tt7xFTnN0BTE92t03Lh8e
HQW1aC9v2Z2DQ/8poZxjXFcyJNWxjfgIkLWH0uAycGNdMzcXkETnFDk+8U6S
YBKN4naGFio/jOzB0pZdmjLZ9iJbHtnkjQYHmWyi+beYDcHlklAqiRDlsEPr
SzwCJCr7CPdfkej6K7vDbXsTTgUy0dTFJNlMBNK2zyBYOc8bmAoao4idj9jb
EIRZy08CZTKHPyc3DzEIAsv+8tEDLGKkZ0MnUOYUitMchLMfgOftunoXYtVk
G9zm1JqmZInbZOmDlcCSb8QvrsXsjc3rbrNkgul3axbrr6s26bdlbKTP5JgO
sCgDqJKRAb+oIt0DONhIZocVK3RGSZ9S5bBhxV5GexRyxxOFM2mdoYakMW55
auxjJAovZrp6YVkSVmKm/5RJrVHjieWZUyxRvyzEIKlNfdqjpeTQ/6FH7ihK
titeXVkxmr7ZT/CX8NcAzTcYDIl4xrDsRrAiOK5eBssos+TctBWquTZgYbDk
uxKD4DTX0pC+lDNLo2KF1XZDaGWv7MtYlKZMH1rH4gb7Y4hMrOws9ELs14Ci
VHXgdeJL4PjDxR508V4hbkp416qhTG3EE0htwvDfYyWfxsaOK4TIlrhEoM+W
OaYo0A5jZAofD6dmcFm+auo+EW/GeESEwHlJ8op2BPI4SkHHlDE33QhAfySa
bMeIkp8S5yxuEMGgP46V2RpKhyGiZkGh7VO4VnGIJjBLnpomEfyzcqMGJeOH
N2qHhYafSzrjD2jRks/rlSY5ot2EF8P5qo+Nn9OCeaKUEIVgS9YrxtkF49f5
OMga+1+XErjZ23mPAtYrU3Iqw4pxKdCBlfTtSfroeETrGZctWDqp1K9w0m6c
M59FBs7MdbcmidPmxiMWTLXGtvmy8KGFeF5YPEgkHYycbcPeg9rOkaxB1exF
DekeSPoCrPMTNNavMkJ2G9KzgaRRSkYvuMe0eJEXZsmfdoS9v8iLnWVGW+7G
GMxdtRTZidr96KpZwGDgkxZofcnw4t7rR+woj4rN0c43lmGmicUoZy4WAqKY
s3yLwbx8542Ln+FiXTdZZVVZQ2DuXhIC2lZsL4w7fyUyYbiE1/usOQYOjFEB
XrQ9NhoBvRfJqotza0JwwtEz6e9C5W2W8XUVxHEWpgl5V8YjUU6JlWCNIhI4
bva2ni2Bb2yDuXIwx94yDHEelYUar7vDhtfKErHF4Hkk5D0bGISPGUiBritK
WQsufrkhJU4nIfFTpCjGPyWzgUlUx2eJoRH8bJXvQQ4vTak28/qGpC+Kcq1D
3KS8la2ruu16Mpvpl3RHGOVQrEE0rqQnhfZjDTKuYdHjkCM3qtrJ6AQ1k8Sn
E9hoDGqPPDMwGgl/HSFdK8lNOIWKqJMMMJrprt+gBFXjyqCJRGNtk+R5IWKY
xl956yZ7wPXwiSB7SsYkHwAbWyRwc3qVlMUKcDa+xVmTu56iairqKLfFTUwo
IwVEYClZ+gL1nqkRazpwekil1qVJHOQH6k+zNmEm0ZSWYW3L8XoCJGgOkj7i
+G0xkcjLXja2WJMBhmtuIKZHcosmggSsyrqUJiLx21zuiTIpU1s7qwjCx3h8
VoLOwkEoktFn71vUp8fcj0sEpVoiyOVS9dQFnDq8l4l9ZGUwKIzPTpbTOUoT
TAtjVg94fZtjnCJts6TfH7WRuM50ULJsVlXJtAe6mJl3swMVT1X/DLs1UQj9
bcaKiYrEljOaL9HuwApGVyNwa6TIjO7vUaJBG65rbQwCOH5zXIr+TIf5rFrU
ZOl6TvxEqDfEpmgdIO+zyuIzZlrQiLUCU+IpFlP9GNkSNvVxH0qrh6B0G77S
DNaCxfUB1uLtIEvvNQFpAPFIfzllLAZVen8U25H/MuTTHqT5+5CN8WnoSffU
WhUwlEq0VQgGnoAovZWkhdfaPc8AgZQUGFH2biIyXQ8IMYKAHaRWSiB9hcz1
mmLXFAXWGhJL/Tdv3746fQNM/eLlOf2SvH757eUzNkT97otHj0DvSX734NHs
4U+T9OWri/RP5/Ad/PKnc9SI8m4xg5dZX+OcDgt/RYEehR91Dku0tY6gNQRc
Usu2ObozinbLXgKt2GG+uz4SxUggWWwK1BuACl1uDZM3wNf84fu3rS94CWtg
n/zui98/4pibZfqX2ZcPfh+FA87QngPS7qrohMnwRAxPN8xRSnsPjpYm7CXo
9YUmCAZrzIUsNjfbQHbRorQiSbfi7kooiS7OEzKlZpkDKYn1I9ToM2egRfBT
NGBrFabYB7wxUEmBCQoQhm7TTAQXQYOiivm6NzThgU8lowREjKNpNxjnU6gf
krqwINKR9fP+oUn0TZSCiU3BPYNsi0vWAQubburFcFPdrCz2TxE9Pnw4k/Kc
Apx5neC4PWzFW0Qushf7oB5d2U4X1x1m9CTJsxCWvDKndUBHJrlAwCFcKLyC
TpMWmG2xFhi597OmVaeXFmEZ1lqepHH0BKyptteDvXY9sVAdwWBj8QKQVhNv
w5eqRRyvvyWtEw+SeqAyPGfs6cDf7OMq4S2wZWdmMhmffV7RBPt6X6XGFZqy
gG5bQWc5lYIUeVQB5XAMoDDypbUWQ02IHUAOJ571kGnkRJ1CrGdzkolW4Bw7
6wqVHlvCK54WdGbaTQJn19kacRwIcVog4J4+bIzs9AJXlpaX1lLYMZflcytG
yStx58JVRIyQhYtq+CTDVbpLsoix8nESY4bcEcwaDFa0aYZAs/6EJ6kLNziI
VplYTCmMW73Hg+sOMxIvJT837PT1JjaYJzFmngXTlOzJCgEMcWArL7XV7Ciq
BFkxD1r1O60Gd6SEju1XaMPbKbmt23HTPcy1/IwtfyyskbSGp3Xkhz/uPS8g
mU4Cm57HopvJf+5NlOVie9ufEeQzFqtiuep99D/++XFkLLfDpF9JK2PT/kNv
fp+Pf3xs2k/ctGNZNfo4nvb3t077CPb4J067V/loOHNmvIPe5OO7Z37Rm2KA
wb1l5n/5X2Hm6dtXL8Z644/vnvnTv2XP/8etMw9ffO4//nRS/9fj02Yd2a0Q
/08+vnvaz+ITbqN0kxpO+/+864SP/YxP21QpuiRyYXQ/4B10B1D+C71VghOo
XzOjUP9n8BiJNs2wts81MDu9+cyCtDFAKtB93aRjkboaAFjmWSNOGfL3o6kY
A7pOGcoGvzjJd/Vic3JGvnQrCzfmFKAECAKD0oQgsWFSmn3byt1ZcHU9uj6v
N7mYzQxcdxlXwva5nDRHKlOvntqDWCebfFVq/glKNOhA6ATVLfIeJgamjyro
yByuM5/0Fmz60mrfP5L0KssdiZ91ua9S0o9CY00L2nD4i8a94thMHTYRQ8PT
DJSVIdXJIDRHSWfR9QJ4KfBL1BWOF6BALcJh8yKIBOJJXjrD58CSk7GYumVw
InhOqy6y5Iv5+T49AAWxqC6lfSe5DpbOV1QejE7Q5kLOFgb8SgXGWfJK3xP4
nNDohnFKiu0OQUtEwQ9LLVIj1zjrmmLXxv0aNkvD0fManrlFhZT8CTkFvRca
RoFmZO+/1TG27KXnkF6X5cADoySWUO24b0DXwjiFSn1uA9c1mRIJVN5CS5iC
XEguV5KgyYW1oRFpJfmOJMVs0dRtG2jIk0BIOF/mu2JhOT5DvkbAj8/9xjLo
nQ+qO+pKvJ2DtIlizYbKXBhFvKXDSIwoGH9B/QE5vWgOqPPgcOpyabinBOvL
+QocsxoqypIKN9EjN9EslSxpMgY5kloGpj0WVfDyjnMVpaN+jbDCIKIlbLfY
sn+Z4phXXR5nLvUWJRljSQK0uq4Z2UKiDhENi9L3sb2iIf9vxch4XU2Zrt1m
gBRxGqFIDa+K03Hf7xmyc6QuRb8i3QNxVSg0qAQNR0MiJCHRaMXV8UpIjX6X
H0LGMhv5MRWd41clRrFaJk0uSeuU/XGXHudcgy7Pmoy7vJ2Jz8ziBcNB7KUZ
roeBmaaUeF1QBZXGMC7NLjvfL9d5l4hpBTdoTbzCm03EE3bGWqrk5ndUgFh0
eM11khjkfigSE70P0KbIzJG4HQmdVnTFt3CPv8vhLGN2Fl1jbw7VYtMAG/2Z
Ltl68U6t8oz7pElXbOoiuqI8XPcW0XkIcE8X1IqiBLLxMlNvG0oSLWaqK4QM
2Z7mRfMOjurPDCfb7ZcZprA6PF08R6Zr3nY+dN4pzZV6YqnB8HCXUsouS3ao
HGCjVJuEc0xYEd9TDOMmYJXIUZPc5DvOpgU40tuSIGFBfNzj2Pmlhbvn4SI5
Eh+Hz8+WXDbGg6oMkvZpO4ZIa4Mi3S6OivaGQEtQzgubKzYktZo6vBoXIBt4
5pAKVLKUmBcrz4wiaxIsqxSie7BCKs9+yhd7No761MrTt8+eYcpvvSSjk/Qg
ceRJkEJgVhZMDq9oQoFP84jSjuEZPiaX26PH5Ds0dWNUn1batoOxK7OF3Ep1
tWfbtHsdo39L43q3sNlhjA8+MxaKdzZxYHfo3N8XFOvInmS/qoL2MlYqHsWS
ZGzHcChItn0qiLLXUYZBPxvHQ6F0kuiC4M5g+NcOvgaRgXakqtW5jxxdlt25
DdVfrjemPU+xosI5OLlc1IGYNaRHWcMYSwRNkW5Zcy+HizwXs7IkKy955Ba4
Sbg6k/HRUyKDK0MpQ7rOQ6RBuNyp2WTIA1xohyQ0sWn3hCC4ToTx90vGH5um
r1nm7g2K0irUR8rgXoL08ViLr4tYJVGT6tSBiTYyM7IfW2A2ukYoLApjrzAS
FVR/mwHDQC61rDsSl8eM9gjQypkUHNoyZ9yXQGspBYMYp5aK77ef4Gc0o8un
lDuEv8fKMVebt1Md0BPEvC5LJ/ClqJhjTMoJtHdyhhdJUS8NnkiwSmohTkSW
FM+n0FXTu0RGA24ReQ5Z7YmOHDR+ECGK+b6rmxN0zNiMssZXeaPrRwm39cZn
jsD0xRpYYCIPLIUwuijNuKaDELkeFDTR407Obh9FF+5gHUlc0EORMsbi6iPr
gwLpdlrtoh9mD2ITaC2VbAIwCowsUtVqzeDJ32KwmJ2/NLCs7iNPHjIcrHAd
wHg/iYU6p5bFi2Ggq0+HCYLxcUHDYivS9CWGJCFrGqMSd/tboTq9N9takaj7
1LtM0Auf674qbk/ddqJC2HdsSwigtOL6Z9yX24UkX+ZhwEo5zFAyAYwbYX+V
sebkjrUxndAZakI7XWDxSKgMuza2glHJ7wKDs0gnV1SZHHF1GluTGYZHS3Ky
mk76qNzkOJYEU3KLxipmm1BQzSAfkPy43Iur/nRItaAvtYXhZXTXJHLJjs5J
EpN0NRQ2j3cSWzPWpZNDHhEKuduJR8HNirZw6UeOFZtge+GQNIgtlFNlhIXg
GG1BntQEDmtQRzLfIxeRyK+aSnNqP4lDgZ3ng7xf5GM6ZbuKjetqAYEDaGj1
nCNhgbxf0M2lAnbsfMZZ8wqM0CnxuHWAv1jBViPowJr8vK062DGcNWtGkHIp
YAmjy9GEgC5TiiIXIkMY/bNjwoZEOeAVx0YPYU+gCFyfcE4YexQlYdWdXlIK
hPbDIWcNZAlK+8Zi8XyjNFbFncRQDGB4rE1YTuNPxXa/tTKd+Ey25iO5zMvs
EF36rF2SRklDiY+5coYyO/4Q8w8+jkWFVX1yrgw5GBm/sdxresvbIyuaUeVt
4zqJDQezUYrA4Wz17rB8m3Rqq5xIHGS0sFSDgKKiVJDn2EqG2qb42OGVNabh
jVIKolERlbCRijQEfJ+b68HbhA3QbjS4QmIGOs7e3SkYG4ybQqlctY9gaXVA
g41pPi2nzlsmEwe1t36X72DsBImN4n8iQJhaRp6EkjGGx7LhUwPRADVW5USq
lqLWEa+3WW6wlHwgjr05zBsQnEMYUa+QCxxdNn5I/S13TRyBPpCcuD42pYgT
pwzpB7pUXa/OKMFQRR9vgRGVa5FzpTVEqGLLooQUKVZXuMhwRKccV3kF6qdY
OVYo0/tTqoFVICLAzk0knkKTeA5ur03QS+IhtFb6OMCGMkq/y5KRCzMEyYqk
7/KK0YOUBBcMaX8OT9yFwfL9x7U42noiHMJbOZIe6kjwWtiIZCjUHvmSJC+H
A15VBk2sr4gK5GWHktgRAgwvc29SQLVXtDuJoRXUDVx0iChTlMZNgUAq1ISu
JHXfW4CEzUkkjwWHcKSlqdLuvpMUFkvgcIhHDPylQdnABvKM8a1vbnD0IykY
UnonRk2KAvcwocBEBsGNxr+LZTuFh6iRz9JXkhRyEfUAytqR7A+WSmNovMgI
LGZZcbCM+RUEsyUDrTWn+CjOxRjqIuZkU7wKBkvVnP8M1XwM3G5Tn1+BJwQz
bi1e0VJuL8XgJRY0/O56U5fqcGUw3GHVE9J9u1C12oBYxkes1QlD12ZgUeDT
+4Z6aqSvOAYt4tai8KkOzCisTOWvkHtKShcskXA5DMzDKSpoSZ9VorXEbC8B
6hc2hXvFuFBEAMSLXfR/Q2t1LlTJvkGDhOAHC16ts1Uuimax3zIsQ8txnFUA
U2FGTxnMGcOyriJ76sfhZBUCFcBVYjwVWFEm1ydXrwFy5lQxxjbCsEIMLAah
fx0jJTU4vC17bHm9Omq/rngLCsVUtjLlcuxaLtnpMRXiPGjaomA8C9kivS+O
VQEaA8rwk5dcsZFSMWTnHFaKGURmw1/Trp7mDKuu6kPiGN7oUcGk8cG3kqQq
5Xo1F05iLBwoMcxNcWHmZV0vKUWRLogtXLgdIrfizbraN2gQVTYiPnw5gGbu
1yBlSb/3oO9y/D1lKCiFeNO3rCwK/XmTPdUCrLrISpCY4yHwvRw0KfI2k00i
aAQKMkgHvA8NEYZjepYMiMYSrkgissix0Yr+8g61VVpwSprCyGVMGpS7kayi
mrByLM714mMKDZ9xrjjH3ms6IYcp22mI+WOTh0xKlWJ7kKWIycrmJkH0RieL
YuhwpTm+rAWdkqvPuGJNMXC/O5ShA2wSNq057PhkXq446AAOfHWvO/aisMLR
yPsNkFkO4prcKCGifRTnVjRIZU8dFZ8dwHveWRjqlqWeOKhxRoeO41MZGF+O
O7GqoB3X6qSxwgxY8g4PTWiTh0R4IGMV7zxU97Haew49TaRJHY8fStERdCfn
p3Hat09hxxukV/anX8oGM7wDmq1DQKivx7y2EW8lM0iX/pXAHoaNc2C7mhDD
wCJVlHG1BdfeMGEwmV+qWZlaWbMYRDeUT8sk/Wxbw44Dnw4eTmM9Pi2U0+uU
ZfTrWPqUcKmULrmR6FOQYCXvd2bIfVR24dicPGV4Mxh5ddiiOcpN9wQDDvI8
ubm5uLiYPgVV7inQ6IcPFjrzm9kjWtqbG/Q6F3m3Yo/zMstuwVt8o5LsQDY9
hiTaLzscJJYqLh5P3v26GEXfmSXf1YG7XhdNHgVHaeOwKMg3Zsn3bJz2vmYy
h7RsCumlk6tmhHpZyIhAsUwTnU2Ax9AEDOBHuHBk1znCigQNRiQWNMGBFCzm
YoeNH60ZvyzMh4LWMwd/YAGBwa4hTm0x5sLjpZjTTaymXKTzCNubOIUOmxPk
WW62uCaS91xyfQxZCRcNhrefKRqdb829ZKUvgOs1GWM54q5aOQrMT67R9Hmm
GQnAlTPqptRjGE0jIg4+dozi0j/2EdhjJgEMxGC07q4/a3EJwEGMzB9Bn31l
rJ/NI7QYyGY1LHSXkX+jzZ34KapnfDlFh1w1sZCtLRFmhHAsyXM+ls8LbB7E
eoYKvVzH3Embi+3EioxOQmQjXQNtfA9gX7LK0WtW58CUFebpNfIkb42CSRS7
fRmjt/RsOn1pagwZM8YiUUbJxp4Q73ILqriVQSo6MrUXbV1mtutwyUXAgSwX
ktlPISFSLXRAuYEDSdk5fgM8meD3cMa0L3/hT6okvUSihMNzIAmHW6BBlWwA
3cBVHtrjGCziE/qRyMUliLAit/kiIkxDC448rEsBW/AIAnjVankRqyKAtBn3
vKU4VYbukCgxCnEKNTZEVVsOeYDqn7h8IBgWOzp0n6UvK7iJSLuNDsXgzHUS
Nbnfmpp3rBIGwdFr6Gep26/IoUg7I0RXGFB+G0cAWfRzoUCOsQohD6NxUH0s
jlYSKirugVWPQ8H2TpQvoywl2FB+sdl4TNVgcXCJm5lu+4RMCEtB08HFBxEN
A3vwC2iEJWUKHswFxpBPgsjxVOkcEVMCCNbbo0bbI4CtUXFRaNDAi52BkSrW
4s3ZqkWxPFDZsltk/aOcxuF6CqDmVdGR41E8u8JfgMepBTjegL4litWGljME
uHaRK+TUU5+JRmpGljfCpqXpsTVaigNndVM8OhcvMRFyHEh/4p1vFpxO41+6
CdBFL0GTZrbUoMMwHY5PmaOIuttIHb/nl09f+rRs8hO8UMbKNajJ/aFmHNls
KU6kOD8KaVMrspBnTIEbxWSLXGcqmsooW0IzWsMR18F1j/V0XC1dNIzCjNDI
jqE+hGiUoWD3nDz/7M4nuQYrda3LfLp35aUk4xp1Tbr63Az5NAzGRVA7WfoE
NPiuRg8x1ejAyD8OfsMEYTHlh3nbuWX/0b7BBPqandZ9s2h/8WsSG/Ox1Wc7
m4suZWbt1y1MwPERX80c4/6iGKmJqqQi1KPkRvK1WUkpt8D2YyDoRPLKYD64
6XfPZfzaEW+xnmPV2h2nMAAWRMlYgkCz24k4xVXVdlj3iquYsEbKYSBr4Djk
hZ+kBDbGTve/aqOYfPSc/ifvY69Wk4PblntuRKAMUt0rFfhicEFcsEj6E1eN
Hic2ICEGtAX3sUjN/KRsc4nX9tKwZ4pWAqX2qJcmlUrxor6sib6wiDSRzZCL
i4klQAiTdTYqerUTU6cG/aCBBLgiSJo/qw2WqrK5sAHih9Dl1DCE+zMt/Oh9
xTa45S7QhFSvm2y3EY/wG7KFgNrKdQbS05ubf3n9/OLXD373mwkqs6oKo/WM
41IiJY33EwQXGJFILrifX1sIdJK8rHI1vdv2DQpskmMbzSIW60T+XnGjyPmJ
NwS52I7lNmzNIFx1H+LTeruNDN+Tnmuuo6xOGrXDEKo6AcAF2Ei5SV1a0oRA
XSXSjLNFYkThOLRnIWKiVj+KELBHipWZKN8HIsZAATKXiuqIoBh5rjUS9ICu
VjWB1dFCFb26PwvC6GysTpFqR4miRI67h7z9AFOCFnnPhRXPX4De1w3foeKW
O7YzqKYGJdhgyAg6k7XyABZhlSXt9ceSnx4sp8FC1GeO/UEwWJHusOXhSwJU
pudtEnJABspooYVrlnbTE4EEoTCEoTNkwr6SoXK23ZbXZ2RmtFmdpZ3RtpGM
1BZwpbIeFQYmg/GtMzoyRxy4sm+Mc4imM6ubuShJApVn2wLEFYzRxYSyfl9S
xKkhbmTA8b4cCjU60XgzkTcM7hrvGPQw17W4WVSDU3xHJpfAwg6Du47rUH7E
Ye9vllRlJF9bx0VBI5uSLyGxFLujA0tt8AtyyUFXMIItR57o6g8qoQVG2BuI
YN7QBU0kvonMZz4D0upZsDUakWYwTsOCTSufxmGW7rAUVj2hrs7Ig4KCccnZ
EhTJYpHWDA6uZBgUYONGavda+OvFfR9Q9t3Ve3yT7FKpjt0pdCv275AQRCHU
mg14FdVCsGSsAqOCr8gPkGkdK7k2k06CN3RDSd0vyeYoMRwMpT0l6nE0KbZS
MrVQMmHBi+1jkPEyTBCWjRwkI85Y6tiguh9bem+/uASKVwV7eVBuWI68HN1I
UbhidlUXSzNF2Bk2hx6aGEQvQx2duSHFsyggqtTVwDiRt5hhut1mqNI+Hhyv
SG4jCvdRNMSNSLw6atHrx7EUwaciwNrDQkeRyeS8OoQoW600f5Uf4lgF4sOH
EZfZiDMxoXkIAo/3PY8VfUxYUWPYcMYdEoXVTiJfTHEAsLYeTnIygnE1CeG4
lJThxhLuvgl8AUTGEqsVyHXsAKEII+Ax/gQ7BokffqfM8rXkJYpmI5TQatZG
Wa/XHAdycxOSJj6YVa/tVXUPEew+66DQPCFv4XZyUrDwuwVtmQo5lzh2SvTs
QAEDfQgqXlBiaRSA1ktlbx2uNhs26s4K10o0QKK4BOw32e45VlN1QzIrWYhK
qJWULad0Fij5J8E4MMbm2moDquTdf/3yhUXLEcm4EVuoXB8b8prK+xC4tEZ4
2S1CTuV+rIuVkieDNttmxoJZopxCSgPugfCzUht7JXAJ6OOASNpxVeQejwvm
Wm+Ipwp9YX/Nfgy0Q3b7ULKDKnGiAcPyTaiiM4NZdlI1PhtzfGsVE88ieshN
6oP0lKpxqkcw7+ZRpEpQ8aPkd6ksYGANHMTxU99lwAFKZliwqgaD2HEM4DyQ
sZiTuBjHv+O6QaHyJub8oZnHXFyx4cLVOCLPiXnEqfqbbCBbhKG7YQw6XoK8
OmTJJ8z6yEQSIWGM+bkk8UaKP+vQ69S0FMwzUGQUGlUCKi39oii6lC5cLQWh
Dl2a0LrZuuBp+5A/I2i7UTeXx+cvGsF3aMeCRNVWfwtCIaapweyRWlwNbro3
cPTiLxeQgnZXiGOpxLuEODrwtZBBx13DiJt1ruUypeBIgSyb4VXY/SoanIwE
b1qeFwd5UqUcrQRLA40r9ilftJArcpVoLABa7XF0oKvnokw7fzSsa7D+BcBF
kn3FjFY3PdOWTPSYMZi6H7oVEPyyu64xzhHvI+RudrlWYUoUaOGmL/ZVMXbx
BgfUDsmYl4BViaj2NitJH9ToVZeHNzGIPcHJ6OUZfpjojciuPpFqJ3LnoSa5
BBLa0S+5fMJQByTgaeC1MXQuxxDYuzrVxU1qthaCPKaYabWnaHA8TghrKewo
eTjxPEhiMyJeocfNqS8x+/bDwTJ1Tt707s0QD0wJaC5ikIySGNWPXiy+1Ytd
VnWC0qJxZIaAwDAnOHhOQud4N0ZZhJXPfyanKGUqchRrq9J/hujsbcHVGXDn
4AQdJIsiRIZnrXbpE/NcCb9xuAmWWzQygg8IRxCw9Y7Su4hSQyhEhgWMMiqR
OohHI1lTDRtciLAn2dHdWfLcmYzExO7StVpf0xllr6IyTAngirBMBOnJ6Wa7
rI2y2mIqwx5c0wqOHorrFaJEIneiO8kgOLh4jctfoRAl0e36wuxyb9UjgXq2
GWGCULaUxnAFAo1CnmIIpqd6d5FrhE5TlHk2XBvz9ccLhPAMUiMxzbgQj2Vu
C9XYMbR6J9AYilUYrUQ2Jqs7mPgoBDiGHVYfJJ/ZnqLaUFjbq00BLwXS6HqJ
/kHaSqim+mgNy1DKkfPppFpT2GQyjDKWlkBAVhQ1h6YcwbFwjMBQveLj/zos
Le69kaEqpMjwQ7iQxBmFs2BhUr1DiIkri85vnLY+C0XiWNN3ylhgxtkcA9eA
1dwTVxTcPF3QSaTAKXN+AqFIzytgLE2sbdJNq6ydNANCV0W2bkGKo3BtnOvM
1Zq4XUzysFxGsRyaIYqt9b958OjXeKlxxGXbD0wz7SRqMjJwJRJbQzPAoBuz
H2AspboBsKGbm+8u37yd/u7Bg+mXv53uHvp+M97ifCPx6VQ5ZxsSvpKu3mEh
jZA9OowIag/bLaaALnoesjda45eLco1NaMtVFjCdMXaqq74Yud3hk7xheQl2
Jg+Sk3+1XwzMyNB1zvVD/bAnw4fCCDFXUwK1ovGg+oc63SrC4w7Gs6yNWmzv
oiQKPgPVMOnH0qojSwGC2Gbr8aLJ2bHfKTP13RrYmIXGKzIGidOuEbhka13E
5yKuMxuydAOJyWD3GBpYepT2f1DFwN89kLSfy/Pvzntxlf3gScMsEeImc47C
3QF7xSaorfMFhi+W+XLN9M/0hb4mEEKB+6xrtNH94f/9f5p1+qRusLRYN0m+
g0U4pBfZdvo9TDmHT/6AcfGLLH1edD+vMSl4OX2x+GN2mCRPixwa+Rbk3p8n
ybfZnhXib/fVcl5my3ySvMr2ZfoaWNIk+QaZSpu+NVjtSfIcON279C9FRpCD
ydMMuF36fY3iD03gu1qK1qEFRsQzWo56C5TyDYjMf62r2lwQZIfExDnOkbHb
kLP86rJeHwLqX0XRP6FON8lh30Erb4AhwxX/DOn8z3XRBctKx54c1XeDNtKD
9efPzN+bPmcchZ5kZDcQfT1LXsAkD+n3BdkYbE5dyG1IQ0ClTEyyhgkpK9Ig
l022QqHrIoMHoLUnqMdXLuqCglykFQFUZiP6fF+UnPPOiZsCgN+qPosvXFLq
F+geb0mCS18g24cNe4X5lEANoAgtFjXbzXDXMAQJxDeyrGPSfH6druBAYN0y
8hA73DBYxXdYbI2VkC7PtnDhUikQcX4zXBXw34X4FvDioyxtNCXizcfme43Z
n06nVCANyQlBUIYxy2N5fMdMe0uDqEZAaJHo4sBcBlKMUCtySyNCKjcT8lJ3
LoCbxcn8Ki8Fo04EPwlL0YgZcBvCxDFe/6cgObjMxraXzYjWibzcOQxwB94d
BjVJOM+F65NF2JghqUfHJTYNPrYc28xogzG+p9WhJ/MwSsISSCcwBUkRKmwi
xBx57jtFLdfsfI5AQEaLKV/clK1eoiiHKNQAA2i1ztucBivoYoKlokEwSIIX
dY3YBHT6/lQhTgIaAol2qEOgYq4EY/ukPWkCMZFisD0FiDcBQoGT8K5VgAof
gcNDgk3NuTBFyI2nYFUSO9naStEnZEmDFX+Py/YeGAqu0fjPe8K8y4K/i1Yr
eY8Ave9HQHvDz7Fvodc/fw3tclXT4JeKez2XvCgOUM2zhvWagPkmfG5QSBDj
FOlNtHGywJgvNgpnQ+nkFKhMzmFvHsTYZZ+7iCGGvfKYPucYrg84JxlVYiaL
QMEQvZtMzEsccsDD4/ucgy2wQZ67sWraHiYi+j3z9Td5yiJGqlxC0R3C+ni6
fk1gib97A4tIYGuMozSyseeS04wSgQcZwyX3hSUd3OV/A6mswCMFf5wZDln8
AvX+2npX2+qx3r35Ne6YTDTeCostX2LLhk1gCBJRy1WEqwOLj0ZU9uLbC2IG
WAi06iEYTLGXZ1/TsZB71mEWRr2ExCVad2dYJqVQgoTzpVWpgjZf+4ZH1gYX
JnYF0ENtlEcVFFVs8zUOVpT1kaFym2aM1gSnNk7y1nPYhi2I4S+hi9ehn9Fd
PTr28VyqblAHi3o5D73oWHsr9Laf4+gmNWpCep++fAXvvdSgZC2b6Roea1We
ant1fbUiVUi4NELAXMQsYJiK+d6SjQb4v75EFJVVYmuGBtKgs47cG8IoEDCZ
9pAhEE5fn5/Rkv0lLBmD9g5P2+gOmOOBOBjxQEsmnRCsEoPtiPgWqu8ifwuc
G9P6kj8ZmDdzETIVTKLLe3PY4XFmeS53Bes2lJdjHmi7H1GmZKSOIGpI2pTI
LZhJ5Uz3ktodqraCYDlJpJ74X1kDxhxkts9jSaOKHD6SOVFSxyqpSZpvLOGh
aRatbiRBcDJmuLvJ5YDYyAbdqpVslcWc/JCdpKdKL2eT5OSHK/hAV5bLDZ38
0MBnES2ecZ7CTygmFRaNw1hKPOlXDd4cp/fOrE/Orq3J6d5avW3y0uJFRxc5
tPcNLn61dJgrhNbhgWkHZZm3IrhfKgjRmmJZaGcmCHaFkTdNxrDZMhq5wUZS
e7AJ2MBYu7lZ1fWHNFRCJpq7Bx/ek8CpuP6q5U/SVPDxPT51pcZ+lIhQNcg4
r43BfFnhfvg4NYhbcVO80iLKpKHok/1aOKqxx1X2IiqPG0riIAuCQvbIfkEn
aBlOEg3BbiMS2SAPLRNgsl3pzZ7F4yAW40Q3knCYGRxCE7AZy+44Yu05VxBs
rY6yh2DMxqJCnMiSJUGWRUeFFSDVXEqura7RZTwY8p3Z6gyK4LjyFf3Sg/wT
P9CvdjHjwoDGut+PtvE+ML33KXFZf0G8txqBn99S5oJrYXwuD2hlDC2sEYp7
jI8gHk3vb36X7oI/f/1Ddvbp7/49/cLPv9/5bv+Jf/+F5vvsHzJf2TVjUmEo
H/ibf/6v6feOd1ka+PqHq7Aiv1C//0SzGsoOdo4+v2vMN2FwE/71L/Drh9v7
vZuu+j+fQlf9n2h/h3M9MgPYbBXDfmjOfpHu/1HT/sR3adYvX+GsqURPVDuZ
g6Ooaq8vQOMxEMjI1a95i8UFTbAlUoZr2wzoP7rPp54D/BMZE6k+xY8u4jxx
2BChgAVKjASQEOQ+BQ/VXAaBX0Qo4m3RkQmSr8Z3+XV08QaNSmI8XI745coz
ZQtD6yG8BgVsBISb1fokAj/jiBkyPGmnNgqq+qNykgDSsm+CfEthNFdcy7nr
bxkNMSDb+b1zAyJkKQavvWN7/jzYHo6oiXaDRx0UqduqmgiYB0V/R6kiSYQC
6zYxvW0Tk7s28e1mDO8d1YF95MWNAUdQ2RCMF7SCsnI01C3HD8mIjqbHJemX
iPbHBRnQ2H7Q51N/pqLjkoQ8iGh0n3hmko9Z7mEvAxpm+pAwBl5DiplTizZ2
xxASpOqwsiwxewrnVBYrSjBLVCqtxG/jA6SjdTsTo3CvkpdU15UEEFedgVEX
xUmJMm5R7XMG1Zrnh1rmxFjQNGQWvSk0BvGrjuwz48JYfIysNo1t307wdS1S
Sc5R6O1Up0Gc+EzRPPH/P4bPj2+/c/kXR6M/gvu6UttCpxZtvgdpjxKDbFMQ
0FKoMRrLP7n3foy1sEeP2WD4/70GJgjvDoPfaR1pesEqisJDBk3GQEI11KsL
2hutFgzIlcdKaIcRvxkDO7nXSazzWURkxJbiGt+Y+f1OsBOZZnKyr7ASregc
nJXCNCgTEjaULdF/gvpZES6LgWfYirixxpn0TQK/rD5Ipao/RiWsm0gjpKOR
XueSeM0mkvT0JDtJQ3UlpO+TK/4kVpFPGv60Z2kRGwcGM7EjSowQ+Aib5SXj
165mdKRNJASOLUNkAA7uN9HbA5SATBLWUXHnMc6iywK3ROgRdkxZgr/UP/DJ
AHJv6tr/byX5fyvJsfJGPPXhdOyHVuS7N7+w0vgPVs5VWByd8a3K+Q0v1cTN
YBqI5sN/0Zj/kYr9LVr9nYr9TbjIp2GQH+7s9x+m4epZeDRKGcfOxi+h1/Py
vL79RNwy8r+135ROxP911J7R37tJiifkNosGL+DEzWgaDsv//YuP/v+v1hAF
V1DpVGXOEaX7VjtJwpoASGJOvf6R6t0TFKTBPruvPVePhf2BkabCDDpTayjh
/GCFCTNx33d1Mm4TMNhaDcpgfGWGhmFJqGfK6AO2H0ehZzkWIxp8nbOgJvb1
lnEjSOSZ1XwRqVgH0zLcKA/dKlLYj6N3wI+ahMfWlbAuNO/FITliEfF78vn4
9dLfqzfFthAs8NUkJL8dASXlEHRbBZSccZ4tZWr3xLFPWKIArZXYEqHuR2vU
HluMI/aMpGfP8OaKxOmIjvXqYvU5TW+xzkuE61yz7YxZFIn3P46+/KNCJwdh
vCAHb3LMotNhVncoEsgl6PqefwzxSXprGm3SVb23MqT+zQA+liyyncTqj5qM
OKW608rDH2mYSO4wTKQfbZhIKDZaLRK32Axa8jFmHEuNmQdmlPEhdT+O3kI/
ujzJIxazY9TijQu+xdjO8MXjfk7abaYGMzBgtMaqWE8lZW26k5c+fPj7jA++
BpTZH8Qi0dN2aUCjdajmTZ0tF1nbhfbSHy9/lA2G95uu5bpXUovnx2c/Sn6x
xaa4FDH28yNTY2AYu2EuX5/92DeMhsChcHNVwDh2tYKG+RERXpZiC2hccBI4
e3xJhbCefgmqZdwsMJUT4iong6iVJOBMhCjm0aRCdh5QvS2qsiXhHWQQMZv9
HWW3PiaUisyNI2DVEZhODxUNw06s6CXl+cAANH3FLcW9H319M9jne7g4iTd+
kh2ZnpQbm5ZzfuBQ0TF6EAOpjiWRqK4jp9+y55d7lxqGFHfaLzKmA09gD890
yvGp31tYkc1SOWhUMI5mpODvvTYwJFOqlYUJ4/OO14yVnQrQyn+lOD427hex
dKfwz9pwiIrxMUstCAgYVjQZTsWywY9GyQ1nhJTCs9cksywdlJUjAUqhZQw6
zA6X5mcvLcxcMzvjmBvLpqTqlVw31WrqUcgr4co1kmN7ZDVbisel1EaqNidC
QKYwdX7sR7ZRTZ1jrygjEJqz6nVcGgwLXIVI/CMZxQawLOZKfzq4Wb7fucnJ
Lf4aq8cQMgEJw6STqr+JUgyTFT5GiZgD613vJ7bOzUbsey40VvSYT7fvvY+u
Fv7kU+17Yr8T81345G+w7935wS32vY999+/pNx3RUwfvfoJ975Pme0lWBY7R
uJxOa/qXLF32PTpk/d+3WTQ+qe9n/5C1/vtsfGl6czk5Yt/7rxvzrY+OWPh+
sX7/Xhvf5WRUov4vWyuh0XtG1Jf/s71r52kYBsJ7fkVUhgwNTLCgwgBiYM3O
EAFCCAQFEjHQ8NtJ7+L4bN85Se3SCtGtkl9yzr7H950vA5nOUkOmMxRq8n9S
mM4vXEy8jBUzifojblp+nd38NYBhSl87TPZ1mh5wHlXbsHq+P5t5vbRZYzh1
xy6F96K8fXoA9PXwEoJsoUAyP+DOKL1HphumnCqj8o9tQqmHIyqswPEIdXBe
l+VbjUkgXQywtUo/y/c7aKBrUxAnjVgpLMDomBmcaNCeCYsxOpYGL2HaOEmI
XaFhRsfY4IahBoxfvkcIfeKFG8cNELwC/LFXw4j7Itoe8FDgr+4BfFbLaHDM
hKEVUKrv5BXYbXGsAug5Mpv4POIeTB9Aq67trYKw1Nb6XlK98/ErINhWQ1rs
xXmQ2hKClG8ATbWFKLxVD8oKS2B5PuMhHsjBTrQfDE836iwYzNgyg6UnJilr
hzq1C4mik15/bMJYkmE5Ut1Xg1Lw3pAORarwI6T+Ie7l6FY2bq3fK8Vn4uwE
23bHwxVqBGXqKlKbrzOoSF0lKh0M/4EJUqCr0JlT+ULwXxTfEWYWOy+6Tcfz
qH8aW4wx+0KcoZCvp+Ad39hQiPGtDesASUDNsIEQY2a2kWAakHVtU8rknrY5
EH3+YVNgPmJmkZe0nyd7UPWvAjJs0GtUTTqeRqLSOHq2RqUygkusXa0I2b1B
0NMt6hcoXUQb5QJSu0adezxeZpF4Eh5yl+jCIL8FIr8O0eUfOh8HnV8Vfuj8
B7kDEqFHowEA

-->
</rfc>