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

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

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-rats-tpm-based-network-device-attest-14" category="info"> number="9683" submissionType="IETF" category="info" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
<!-- [rfced] May we update the title as follows?

Current:
   TPM-based Network Device Remote Integrity Verification

Perhaps (expanding TPM per the Style Guide):
   Remote Integrity Verification of Network Devices
   Containing Trusted Platform Modules
-->
    <title abbrev="Network Device RIV">TPM-based Network Device Remote Integrity Verification</title>
    <seriesInfo name="RFC" value="9683"/>
    <author initials="G. C." surname="Fedorkow" fullname="Guy Fedorkow" role="editor">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>10 Technology Park Drive</street>
          <city>Westford</city>
          <region>Massachusetts</region>
          <code>01886</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <phone></phone>
        <phone/>
        <email>gfedorkow@juniper.net</email>
      </address>
    </author>
    <author initials="E." surname="Voit" fullname="Eric Voit">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <email>evoit@cisco.com</email>
      </address>
    </author>
    <author initials="J." surname="Fitzgerald-McKay" fullname="Jessica Fitzgerald-McKay">
      <organization>National Security Agency</organization>
      <address>
        <postal>
          <street>9800 Savage Road</street>
          <city>Ft. Meade</city>
          <region>Maryland</region>
          <code>20755</code>
          <country>US</country>
        </postal>
        <email>jmfitz2@nsa.gov</email>
      </address>
    </author>
    <date year="2022" month="March" day="22"/>

    <area>Security</area>
    <workgroup>RATS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2024" month="September"/>
    <area>sec</area>
    <workgroup>rats</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules <xref target="TPM1.2"/>, <xref target="TPM2.0"/>, (TPMs), as defined by
the Trusted Computing Group (TCG)), (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>There are many aspects to consider in fielding a trusted computing device,
from operating systems to applications.  Mechanisms to prove that
a device installed at a customer’s customer's site is authentic (i.e., not counterfeit) and has
been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects which that need to be considered concurrently to have confidence that a device is truly trustworthy.</t>
      <t>A generic architecture for remote attestation has been defined in <xref target="I-D.ietf-rats-architecture"/>. target="RFC9334" format="default"/>.  Additionally, use cases for remotely attesting networking devices are discussed within Section 6 5 of <xref target="I-D.richardson-rats-usecases"/>. target="I-D.richardson-rats-usecases" format="default"/>.  However, these documents do not provide sufficient guidance for network equipment vendors and operators to design, build, and deploy interoperable devices.</t>
      <t>The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem, problem and then identifies elements that are by identifying the necessary elements to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches switches, and firewalls.   An underlying assumption will be is the availability within the device of a cryptoprocessor that is compatible with the Trusted Platform Module specifications <xref target="TPM1.2"/>, target="TPM-1.2" format="default"/> <xref target="TPM2.0"/> compatible cryptoprocessor target="TPM-2.0" format="default"/> to enable the trustworthy trustworthy, remote assessment of the device’s device's software and hardware.</t>
      <section anchor="requirements-notation" title="Requirements notation">

<t>The numbered="true" toc="default">
        <name>Requirements Notation</name>
        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
“OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in
BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
      </section>
      <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>A number of terms are reused from <xref target="I-D.ietf-rats-architecture"/>. target="RFC9334" format="default"/>.  These include: include Appraisal Policy for Evidence, Attestation Result, Attester, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner.</t>
        <t>Additionally, this document defines the following term:</t>

<t>Attestation: the
        <dl>
          <dt>Attestation:</dt>
          <dd>The process of generating, conveying conveying, and appraising
claims, backed by evidence, about device trustworthiness characteristics, including supply chain trust,
identity, device provenance, software configuration, device
composition, compliance to test suites, functional and assurance evaluations, etc.</t> etc.</dd>
        </dl>
<!-- [rfced] Section 1.2. Does the following update improve readability?

Original:
   The goal of attestation is simply to assure an administrator or
   auditor that the device configuration and software that was launched
   when the device was last started is authentic and untampered-with.

Perhaps (rephrasing "untampered-with"):
   The goal of attestation is simply to assure an administrator or
   auditor that the device's configuration and software
   is authentic and has been unaltered since the device started.
-->
        <t>The goal of attestation is simply to assure an administrator or auditor that the device configuration and software
that was launched when the device was last started is authentic and untampered-with.
The determination of software authenticity is not prescribed in this document, but it’s it's typically taken to mean
a software image generated by an authority trusted by the administrator, such as the device manufacturer.</t>
        <t>Within the context of the Trusted Computing Group (TCG) context, (TCG), the scope of attestation is typically narrowed to describe the process by
which an independent Verifier can obtain cryptographic proof as to the identity
of the device in question, and evidence of the integrity of the device's software loaded on that device when it started up, was loaded upon
startup, and then verify verification that what’s there the current configuration matches the
intended configuration.  For network equipment, a Verifier capability can
be embedded in a Network Management Station (NMS), Station, a posture collection server,
or other network analytics tool (such as a software asset management solution,
or a threat detection and mitigation tool, etc.). While informally referred
to as attestation, this
This document focuses on a specific subset of attestation tasks, defined here as Remote
Integrity Verification (RIV). (RIV), and informally referred to as attestation.  RIV in this document takes a network-equipment-centric perspective
that includes a set of protocols and procedures for determining whether a
particular device was launched with authentic software, starting from Roots
of Trust.  While there are many ways to accomplish attestation, RIV sets
out a specific set of protocols and tools that work in environments commonly
found in network equipment.  RIV does not cover other device characteristics
that could be attested (e.g., geographic location, location or connectivity;
see <xref target="I-D.richardson-rats-usecases"/>), target="I-D.richardson-rats-usecases" format="default"/>), although it does provide evidence of a secure infrastructure
to increase the level of trust in other device characteristics attested
by other means (e.g., by Entity Attestation Tokens <xref target="I-D.ietf-rats-eat"/>).</t> target="I-D.ietf-rats-eat" format="default"/>).</t>
        <t>In line with definitions found in <xref target="I-D.ietf-rats-architecture"/> definitions, target="RFC9334" format="default"/>, this document uses the term Endorser to refer to the
role that signs identity and attestation certificates used by the Attester, while Reference Values are signed
by a Reference Value Provider.  Typically, the manufacturer of a network device would be accepted as
both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner.</t>
      </section>
      <section anchor="document-organization" title="Document Organization"> numbered="true" toc="default">
        <name>Document Organization</name>
        <t>The remainder of this document is organized into several sections:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The remainder of this section covers goals and requirements, plus a top-level description of RIV.</t>
  <t>The RIV.</li>
          <li>The Solution Overview section (<xref target="solution-overview" format="default"/>) outlines how Remote Integrity Verification works.</t>
  <t>The RIV works.</li>
          <li>The Standards Components section (<xref target="standards-components" format="default"/>) links components of RIV to normative standards.</t>
  <t>Privacy standards.</li>
          <li>The Privacy and Security Considerations sections (Sections <xref target="privacy-considerations" format="counter"/> and <xref target="security-cons" format="counter"/>) shows how specific features of RIV contribute to the trustworthiness of the Attestation Result.</t>
  <t>Supporting Result.</li>
          <li>Supporting material is in an appendix at the end.</t>
</list></t> (<xref target="appendix" format="default"/>).</li>
        </ul>
      </section>
      <section anchor="goals" title="Goals"> numbered="true" toc="default">
        <name>Goals</name>
        <t>Network operators benefit from a trustworthy attestation mechanism that provides
assurance that their network comprises authentic equipment, equipment and has loaded software
free of known vulnerabilities and unauthorized tampering.  In line with the overall goal of assuring integrity, attestation can be used to assist in asset management, vulnerability and compliance
assessment, plus configuration management.</t>
        <t>The RIV attestation workflow outlined in this document is intended to meet the following high-level goals:</t>

<t><list style="symbols">
  <t>Provable
        <ul spacing="normal">
          <li>Provable Device Identity - This specification requires that an Attester (i.e., the attesting device) includes
a cryptographic identifier unique to each device.  Effectively  Effectively, this means that the device’s device's TPM
must be so provisioned with this during the manufacturing cycle.</t>
  <t>Software cycle.</li>
          <li>Software Inventory - A key goal is Key goals are to identify the software release(s) installed
on the Attester, Attester and to provide evidence that the software stored within hasn’t hasn't
been altered without authorization.</t>
  <t>Verifiability authorization.</li>
          <li>Verifiability - Verification of the device's software and configuration of the device shows
that the software that the administrator authorized for use was actually launched.</t>
</list></t> launched.</li>
        </ul>
        <t>In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or ‘peer-to-peer’, "peer-to-peer", where network devices independently verify one another to establish a trust relationship. (See <xref target="peer-to-peer"/> below)</t> target="peer-to-peer" format="default"/>.)</t>
      </section>
      <section anchor="RIV-desc" title="Description numbered="true" toc="default">
        <name>Description of Remote Integrity Verification (RIV)"> (RIV)</name>
        <t>Attestation requires two interlocking mechanisms between the Attester network device and the Verifier:</t>

<t><list style="symbols">
  <t>Device Identity,
        <ul spacing="normal">
          <li>Device Identity is the mechanism providing that provides trusted identity, which can reassure network
managers that the specific devices they ordered from authorized manufacturers for
attachment to their network are those that were installed, installed and that they continue to
be present in their network. As part of the mechanism for Device Identity,
cryptographic proof of the manufacturer's identity of the manufacturer is also provided.</t>
  <t>Software provided.</li>
          <li>Software Measurement is the mechanism that reports the state of mutable software components
on the device, device and that can assure administrators that they have known, authentic
software configured to run in their network.</t>
</list></t>

<t>Using network.</li>
        </ul>
        <t>By using these two interlocking mechanisms, RIV RIV, which is a component in a chain of procedures that procedures, can assure a network operator that the equipment in
their network can be reliably identified, identified and that authentic software of
a known version is installed on each device.  Equipment in the network includes
devices that make up the network itself, such as routers, switches switches, and firewalls.</t>
<!-- [rfced] Section 1.5. In the following passage, it is unclear which component is doing the measuring:

Original:
   Software used to boot a device can be identified by a chain of
   measurements, anchored at the start by a Root of Trust for
   Measurement (see Section 9.2), each measuring the next stage and
   recording the result in tamper-resistant storage, normally ending
   when the system software is fully loaded.

Perhaps (stating that the Attester measures at each stage):
   Software used to boot a device can be identified by a chain of
   measurements, anchored at the start by a Root of Trust for
   Measurement (RTM) (see Appendix A.2). An Attester measures at each stage and
   records the result in tamper-resistant storage. The Attester normally
   stops measuring when the system software is fully loaded.
-->
        <t>Software used to boot a device can be identified by a chain
of measurements, anchored at the start by a Root of Trust for Measurement (RTM) (see <xref target="root-of-trust"/>), target="root-of-trust" format="default"/>), each measuring the next stage and recording the result in tamper-resistant storage,
normally ending when the system software is fully loaded.
A measurement signifies the identity, integrity integrity, and version of each
software component registered with an Attester’s Attester's TPM <xref target="TPM1.2"/>, target="TPM-1.2" format="default"/> <xref target="TPM2.0"/>, target="TPM-2.0" format="default"/> so that a
subsequent verification stage can determine if the software
installed is authentic, up-to-date, and free of tampering.</t>
        <t>RIV includes several major processes, which are split between the Attester and Verifier:</t>

<t><list style="numbers">
  <t>Generation
        <ol spacing="normal" type="1"><li>Generation of Evidence is the process whereby an Attester generates cryptographic
proof (Evidence) of claims about device properties. In particular, the
device identity and its software configuration are both of critical importance.</t>
  <t>Device importance.</li>
          <li>Device Identification refers to the mechanism assuring the
Relying Party (ultimately, a network administrator) of the identity identities of devices devices, and the identities of their manufacturers, that make up their network,
and that their manufacturers are known.</t>
  <t>Conveyance network.</li>
          <li>Conveyance of Evidence
 reliably transports the collected Evidence from the Attester to a Verifier to allow a management station to perform
 a meaningful appraisal in Step 4. The transport
 is typically carried out via a management network.
 While
 Although not required for reliable attestation, an encrypted channel may be used to
 provide integrity, authenticity, or confidentiality once attestation is complete.
 It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not
 dependent on encyption encryption carried out as part of a reliable transport.</t>
  <t>Finally, transport.</li>
          <li>Finally, Appraisal of Evidence occurs.  This is the process of verifying the Evidence received by
  a Verifier from the Attester, Attester and using an Appraisal Policy to develop an
  Attestation Result, which is used to inform decision-making.  In practice, this means comparing
  the Attester’s Attester's measurements reported as Evidence with the device configuration expected
  by the Verifier.  Subsequently, the Appraisal Policy for Evidence might
  match Evidence found against Reference Values (aka Golden Measurements), which represent
  the intended configured state of the connected device.</t>
</list></t> device.</li>
        </ol>
        <t>All implementations supporting this RIV specification require the support of the following three technologies:</t>

<t><list style="numbers">
  <t>Identity:
        <ol spacing="normal" type="1"><li>Identity: Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID) defined by IEEE Std 802.1AR <xref target="IEEE-802-1AR"/>, target="IEEE-802-1AR" format="default"/>,
coupled with careful supply-chain management by the manufacturer.  The
Initial DevID (IDevID) certificate contains a statement by the manufacturer that establishes
the identity of the device as it left the factory.  Some applications with
a more-complex more complex post-manufacture supply chain (e.g., Value Added Resellers), value added resellers),
or with different privacy concerns, may want to use alternative mechanisms for platform
authentication (for example, TCG Platform Certificates <xref target="Platform-Certificates"/>, target="PLATFORM-CERTS" format="default"/> or
post-manufacture installation of Local Device ID (LDevID)).</t>
  <t>Platform DevID (LDevID)).</li>
          <li>Platform Attestation provides evidence of configuration of software elements
present in the device.  This form of attestation can be implemented
with TPM Platform Configuration Registers (PCRs), (PCRs) and  Quote and Log mechanisms, which provide cryptographically authenticated evidence
to report what software was started on the device through the boot cycle.  Successful attestation requires an
unbroken chain from a boot-time root Root of trust Trust through all layers of software needed to bring the device to an
operational state, in which each stage computes the hash of components of the next stage, then updates the attestation log and
the TPM.  The TPM can then report the hashes of all the measured hashes as signed evidence called a
Quote (see <xref target="using-tpm"/> target="using-tpm" format="default"/> for an overview of TPM operation, operation or <xref target="TPM1.2"/> target="TPM-1.2" format="default"/> and <xref target="TPM2.0"/> target="TPM-2.0" format="default"/> for many more details).</t>
  <t>Signed details).</li>
          <li>Signed Reference Values (aka Reference Integrity Measurements) must be conveyed from the Reference Value Provider (the entity accepted as the software authority,
often the manufacturer of the network device) to the Verifier.</t>
</list></t> Verifier.</li>
        </ol>
      </section>
      <section anchor="solution-requirements" title="Solution Requirements">

<t>Remote Integrity Verification numbered="true" toc="default">
        <name>Solution Requirements</name>
        <t>RIV must address the “Lying Endpoint” "Lying Endpoint"
problem, in which malicious software on an endpoint may subvert the
intended function, function and also prevent the endpoint from reporting its compromised
status.  (See <xref target="security-cons"/> target="security-cons" format="default"/> for further Security Considerations.)</t>
        <t>RIV attestation is designed to be simple
to deploy at scale. RIV should work “out "out of the box” box" as far as possible,
that is, with the fewest possible provisioning steps or configuration databases
needed at the end-user’s end user's site.  Network equipment is often required to “self-configure”, "self-configure",
to reliably reach out without manual intervention to prove its identity and
operating posture, then download its own configuration, a process which precludes pre-installation configuration. See <xref target="RFC8572"/> target="RFC8572" format="default"/> for an
example of Secure Zero Touch Provisioning.</t> Provisioning (SZTP).</t>
      </section>
      <section anchor="scope" title="Scope"> numbered="true" toc="default">
        <name>Scope</name>
        <t>The need for assurance of software integrity, addressed by Remote Attestation, is a very general problem that could apply to most network-connected computing devices.  However, this document includes several assumptions that limit the scope to network equipment (e.g., routers, switches switches, and firewalls):</t>

<t><list style="symbols">
  <t>This
        <ul spacing="normal">
          <li>This solution is for use in non-privacy-preserving applications (for example,
networking, Industrial IoT), avoiding
networking or industrial Internet of Things (IoT) applications), which avoids the need for a Privacy Certificate Certification
Authority (also called an Attestation CA) for attestation keys Attestation Keys (AKs) <xref target="AK-Enrollment"/> target="AIK-ENROLL" format="default"/> or TCG Platform
Certificates <xref target="Platform-Certificates"/>.</t>
  <t>This target="PLATFORM-CERTS" format="default"/>.</li>
          <li>This document assumes network protocols that are common in network equipment such as YANG <xref target="RFC7950"/> target="RFC7950" format="default"/> and NETCONF Network Configuration Protocol (NETCONF) <xref target="RFC6241"/>, target="RFC6241" format="default"/>,
but not generally used in other applications.</t>
  <t>The applications.</li>
          <li>The approach outlined in this document mandates the use of a TPM <xref target="TPM1.2"/>, target="TPM-1.2" format="default"/> <xref target="TPM2.0"/>, target="TPM-2.0" format="default"/> or a compatible cryptoprocessor.</t>
</list></t> cryptoprocessor.</li>
        </ul>
        <section anchor="out-of-scope" title="Out of Scope">

<t><list style="symbols">
  <t>Run-Time Attestation: The numbered="true" toc="default">
          <name>Out of Scope</name>
          <dl spacing="normal">
            <dt>Run-Time Attestation:</dt><dd>The Linux Integrity Measurement Architecture <xref target="IMA"/> target="IMA" format="default"/> attests each process launched
after a device is started (and is in scope for RIV in general), but continuous run-time attestation of Linux or
other multi-threaded operating system processes after the OS has started considerably expands the scope of the problem.
Many researchers are working on that problem, but this document defers the problem of continuous, in-memory
run-time attestation.</t>
  <t>Multi-Vendor attestation.</dd>
            <dt>Multi-Vendor Embedded Systems: Systems:</dt><dd> Additional coordination would be needed for
devices that themselves comprise hardware and software from multiple vendors, vendors and are
integrated by the end user.  Although out of scope for this document, these
issues are accommodated in <xref target="I-D.ietf-rats-architecture"/>.</t>
  <t>Processor target="RFC9334" format="default"/>.</dd>
            <dt>Processor Sleep Modes: Network Modes:</dt><dd>Network equipment typically does not “sleep”, "sleep", so
sleep and hibernate modes are not considered.  Although out of scope
for RIV in this document, Trusted Computing Group TCG specifications do encompass sleep and hibernate
states, which could be incorporated into remote attestation for network equipment in the future, given a compelling need.</t>
  <t>Virtualization need.</dd>
            <dt>Virtualization and Containerization: Containerization:</dt><dd> In a non-virtualized system, the host OS is
responsible for measuring each User Space user-space file or process throughout the operational lifetime
of the system.  For virtualized systems, the host OS must verify the hypervisor,
but then the hypervisor must manage its own chain of trust through the virtual machine.  Virtualization
and containerization technologies are increasingly used in network equipment, but
are not considered in this document.</t>
</list></t> document.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="solution-overview" title="Solution Overview"> numbered="true" toc="default">
      <name>Solution Overview</name>
      <section anchor="riv-software-configuration-attestation-using-tpm" title="RIV numbered="true" toc="default">
        <name>RIV Software Configuration Attestation using TPM"> Using TPM</name>
        <t>RIV Attestation is a process which that can be used to determine the identity of software running
on a specifically-identified specifically identified device.  The Remote Attestation steps of <xref target="RIV-desc"/> target="RIV-desc" format="default"/> are broken split into two
phases,
phases as shown in Figure 1:</t>

<t><list style="symbols">
  <t>During <xref target="RIV-Attestation-Model" format="default"/>:</t>
        <ul spacing="normal">
          <li>During system startup, or boot phase, Boot Phase, each distinct software object is “measured” "measured" by the Attester.
The object’s object's identity, hash (i.e., cryptographic digest) digest), and version information are recorded in a log.
Hashes are also extended into the TPM (see <xref target="using-tpm"/> target="using-tpm" format="default"/> for more on ‘extending hashes’), extending hashes) in a way that can be used to validate the log entries.  The measurement process generally
follows the layered chain-of-trust model used in Measured Boot, where each stage
of the system measures the next one, and extends its measurement into the TPM,
before launching it.  See <xref target="I-D.ietf-rats-architecture"/>, section “Layered target="RFC9334" sectionFormat="of" section="3.2"/>, "Layered Attestation Environments,” Environments", for an architectural definition
of this model.</t>
  <t>Once model.</li>
          <li>Once the device is running and has operational network connectivity, verification can take place.  A separate
 Verifier, running in its own trusted environment, will interrogate the network
device to retrieve the logs and a copy of the digests collected by hashing
each software object, signed by an attestation private key secured by, but never released by,
the TPM.  The YANG model described in <xref target="I-D.ietf-rats-yang-tpm-charra"/> target="RFC9684" format="default"/> facilitates this operation.</t>
</list></t> operation.</li>
        </ul>
<!-- [rfced] Section 2.1. We're having difficulty parsing the following. Does the Verifier validate both the software and the logs, or does it validate the software with the logs?

Original:
   The result is that the Verifier can verify the device's identity by
   checking the subject [RFC5280] and signature of the certificate
   containing the TPM's attestation public key, and can validate the
   software that was launched by verifying the correctness of the logs
   by comparing with the signed digests from the TPM, and comparing
   digests in the log with Reference Values.

Perhaps (splitting the passage into two sentences and rephrasing the second sentence):
   The result is that the Verifier can verify the device's identity by
   checking the subject [RFC5280] and signature of the certificate
   containing the TPM's attestation public key. The Verifier can also
   validate the launched software and verify log correctness by
   comparing the log with the signed digests from the TPM and by
   comparing the digests in the log with Reference Values.
-->
        <t>The result is that the Verifier can verify the device’s device's identity by checking
the subject<xref target="RFC5280"/> subject <xref target="RFC5280" format="default"/> and signature of the certificate containing the TPM’s TPM's attestation public key, and can
validate the software that was launched by verifying the correctness of the logs by comparing with the
signed digests from the TPM, and comparing digests in the log with
Reference Values.</t>
        <t>It should be noted that attestation and identity are inextricably linked;
signed Evidence that a particular version of software was loaded is of little
value without cryptographic proof of the identity of the Attester producing
the Evidence.</t>
        <figure title="Layered anchor="RIV-Attestation-Model">
          <name>Layered RIV Attestation Model" anchor="RIV-Attestation-Model"><artwork align="left"><![CDATA[ Model</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
    +-------------------------------------------------------+
    | +---------+    +--------+   +--------+    +---------+ |
    | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
    | +---------+    +--------+   +--------+    +---------+ |
    |     |            |           |                        |
    |     |            |           |                        |
    |     +------------+-----------+-+                      |
    |                    Boot Phase  |                      |
    |                                V                      |
    |                            +--------+                 |
    |                            |  TPM   |                 |
    |                            +--------+                 |
    |   Router                       |                      |
    +--------------------------------|----------------------+
                                     |
                                     |  Verification Phase
                                     |    +-----------+
                                     +--->| Verifier  |
                                          +-----------+

    Reset---------------flow-of-time-during-boot...--------->
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In the Boot phase, Phase, measurements are “extended”, "extended", or hashed, into the TPM as processes start,
with the
which result that in the TPM ends up containing hashes of all the measured hashes. Later, once the system is operational, during the Verification phase, signed
digests are retrieved from the TPM during the Verification Phase for off-box analysis.</t>
        <section anchor="what-does-riv-attest" title="What numbered="true" toc="default">
          <name>What Does RIV Attest?"> Attest?</name>
          <t>TPM attestation is focused on Platform Configuration Registers (PCRs), PCRs, but those registers are only vehicles for certifying
accompanying Evidence, Evidence conveyed in log entries.  It is the hashes in log entries that are extended into PCRs, where the final PCR values
can be retrieved in the form of a structure called a Quote, which is signed by an Attestation key AK known only to the TPM.  The use of multiple PCRs serves only to
provide some independence between different classes of object, object so that one class of objects can be updated without changing the
extended hash for other classes.  Although PCRs can be used for any purpose, this section outlines the objects within the
scope of this document which that may be extended into the TPM.</t>
          <t>In general, assignment of measurements to PCRs is a policy choice made by the device manufacturer, selected to independently attest three classes of object:</t>

<t><list style="symbols">
  <t>Code, (i.e., instructions)
          <dl>
            <dt>Code:</dt>
            <dd>Instructions to be executed by a CPU.</t>
  <t>Configuration - Many CPU.</dd>
            <dt>Configuration:</dt>
            <dd>Many devices offer numerous options controlled by non-volatile configuration variables which that can impact the device’s device's security posture.  These settings may have vendor defaults, but often can be changed by administrators, who may want to verify via attestation that the operational state of the settings match their intended state.</t>
  <t>Credentials - Administrators state.</dd>
            <dt>Credentials:</dt>
            <dd>Administrators may wish to verify via attestation that public keys and credentials outside the Root of Trust have not been subject to unauthorized tampering.  (By definition, keys protecting the root Root of trust can’t Trust can't be verified independently.)</t>
</list></t> independently.)</dd>
          </dl>
          <t>The TCG "TCG PC Client Specific Platform Firmware Profile Specification Specification" <xref target="PC-Client-BIOS-TPM-2.0"/> gives considerable detail on target="PC-CLIENT-BIOS-TPM-2.0" format="default"/> details what is to be
measured during the boot phase Boot Phase of platform startup using a UEFI Unified Extensible Firmware Interface (UEFI) BIOS (www.uefi.org), (<eref target="www.uefi.org" brackets="angle"/>), but the goal is simply to measure every bit of
code executed in the process of starting the device, along with any configuration information related to security posture, leaving
no gap for unmeasured code to remain undetected, undetected and potentially subverting the chain.</t>
          <t>For devices using a UEFI BIOS, <xref target="PC-Client-BIOS-TPM-2.0"/> target="PC-CLIENT-BIOS-TPM-2.0" format="default"/> and <xref target="PC-Client-EFI-TPM-1.2"/> target="PC-CLIENT-EFI-TPM-1.2" format="default"/> give detailed normative requirements for PCR usage.  For other
platform architectures, where TCG normative requirements currently do not exist, the table in <xref target="Attested-Objects"/> target="Attested-Objects" format="default"/> gives non-normative guidance for PCR assignment that generalizes the specific
details of <xref target="PC-Client-BIOS-TPM-2.0"/>.</t> target="PC-CLIENT-BIOS-TPM-2.0" format="default"/>.</t>
          <t>By convention, most PCRs are assigned in pairs, which with the even-numbered PCR used to measure executable code, code and
the odd-numbered PCR used to measure whatever data and configuration are associated with that code.  It is important
to note that each PCR may contain results from dozens (or even thousands) of individual measurements.</t>

<figure title="Attested Objects" anchor="Attested-Objects"><artwork align="left"><![CDATA[
+------------------------------------------------------------------+
<!-- [rfced] Section 2.1.1. Please review the numbers in Table 2. Should Vendor-Specific Measurements and Measurements made by OS have the same Code and Configuration number? Is Secure Boot Policy missing a PCR Code?

Original:

   +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
   |                                            |    Assigned PCR #   |
   | Function                                   | Code | Configuration|
--------------------------------------------------------------------
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | Firmware Static Root of Trust, (i.e.,      |  0   |    1         |
   | initial boot firmware and drivers)         |      |              |
--------------------------------------------------------------------
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | Drivers and initialization for optional    |  2   |    3         |
   | or add-in devices                          |      |              |
--------------------------------------------------------------------
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | OS Loader code and configuration, (i.e.,   |  4   |    5         |
   | the code launched by firmware) to load an  |      |              |
   | operating system kernel. These PCRs record |      |              |
   | each boot attempt, and an identifier for   |      |              |
   | where the loader was found                 |      |              |
--------------------------------------------------------------------
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | Vendor Specific Measurements during boot   |  6   |    6         |
--------------------------------------------------------------------
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | Secure Boot Policy.  This PCR records keys |      |    7         |
   | and configuration used to validate the OS  |      |              |
   | loader                                     |      |              |
--------------------------------------------------------------------
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | Measurements made by the OS Loader         |  8   |    9         |
   | (e.g. GRUB2 for Linux)                     |      |              |
--------------------------------------------------------------------
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   | Measurements made by OS (e.g., Linux IMA)  |  10  |    10        |
+------------------------------------------------------------------+
]]></artwork></figure>
   + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
-->
<table anchor="Attested-Objects">
    <name>Attested Objects</name>
	      <thead>
		<tr>
		  <th></th>
		<th rowspan="" colspan="2"> Assigned PCR #</th>
	      </tr>
	      <tr>
		<th>Function</th>
		<th>Code</th>
		<th>Configuration</th>
	      </tr>
	      </thead>
	      <tbody>
		<tr>
		  <td>Firmware Static Root of Trust (i.e., initial boot firmware and drivers)</td>
		  <td>0</td>
		  <td>1</td>
		</tr>
		<tr>
		  <td>Drivers and initialization for optional or add-in devices</td>
		  <td>2</td>
		  <td>3</td>
		</tr>
		<tr>
		  <td>OS loader code and configuration (i.e., the code launched by firmware) to load an  operating system kernel. These PCRs record each boot attempt, and an identifier for where the loader was found</td>
		  <td>4</td>
		  <td>5</td>
		</tr>
		<tr>
		  <td>Vendor-specific measurements during boot</td>
		  <td>6</td>
		  <td>6</td>
		</tr>
		<tr>
		  <td>Secure Boot Policy.  This PCR records keys and configuration used to validate the OS loader</td>
		  <td></td>
		  <td>7</td>
		</tr>
		<tr>
		  <td> Measurements made by the OS loader (e.g., GRUB2 for Linux)</td>
		  <td>8</td>
		  <td>9</td>
		</tr>
		<tr>
		  <td>Measurements made by OS (e.g., Linux IMA)</td>
		  <td>10</td>
		  <td>10</td>
		</tr>
	      </tbody>
	    </table>

        </section>
        <section anchor="notes-on-pcr-allocations" title="Notes numbered="true" toc="default">
          <name>Notes on PCR Allocations"> Allocations</name>
          <t>It is important to recognize that PCR[0] is critical.  The first measurement into PCR[0] is taken by the Root of Trust for
Measurement, which is code which, that, by definition, cannot be verified by measurement.  This measurement
establishes the chain of trust for all subsequent measurements.  If the PCR[0] measurement cannot be trusted, the
validity of the entire chain is put called into question.</t>
          <t>Distinctions Between between PCR[0], PCR[2], PCR[4] PCR[4], and PCR[8] are summarized below:</t>

<t><list style="symbols">
  <t>PCR[0] typically
          <dl spacing="normal">
            <dt>PCR[0]</dt><dd>typically represents a consistent view of rarely-changed Host Platform rarely changed boot components, allowing components of the host platform, which allows Attestation policies to be defined using the less changeable components of the transitive trust chain. This PCR
typically provides a consistent view of the platform regardless of user selected options.</t>
  <t>PCR[2] is user-selected options.</dd>
            <dt>PCR[2]</dt><dd>is intended to represent a “user configurable” "user-configurable" environment where the user has the ability to alter the
components that are measured into PCR[2]. This is typically done by adding adapter cards, etc., into user-accessible
PCI
Peripheral Component Interconnect (PCI) or other slots.  In UEFI systems systems, these devices may be configured by Option ROMs measured into PCR[2] and
executed by the UEFI BIOS.</t>
  <t>PCR[4] is BIOS.</dd>
            <dt>PCR[4]</dt><dd>is intended to represent the software that manages the transition between the platform’s Pre-Operating System platform's pre-OS
start and the state of a system with the Operating System OS present.  This PCR, along with PCR[5], identifies the initial
operating system
OS loader (e.g., GRUB for Linux).</t>
  <t>PCR[8] is Linux).</dd>
            <dt>PCR[8]</dt><dd>is used by the OS loader (e.g. (e.g., GRUB) to record measurements of the various components of the operating system.</t>
</list></t> system.</dd>
          </dl>
          <t>Although the TCG PC Client document <xref target="PC-CLIENT-BIOS-TPM-2.0" format="default"/> specifies the use of the first eight PCRs very carefully to ensure interoperability
among multiple
UEFI BIOS vendors, it should be noted that embedded software vendors may have considerably more flexibility.  Verifiers
typically need to know which log entries are consequential and which are not (possibly controlled by local policies) policies), but
the Verifier may not need to know what each log entry means or why it was assigned to a particular PCR.   Designers must
recognize that some PCRs may cover log entries that a particular Verifier considers critical and other log entries that
are not considered important, so differing PCR values may not on their own constitute a check for authenticity.  For example, in a UEFI system, some administrators may consider booting an image from a removable drive, something recorded in a PCR, to be a security violation, while others might consider that operation to be an authorized recovery procedure.</t>
          <t>Designers may allocate particular events to specific PCRs in order to achieve a particular objective with local
attestation,
attestation (e.g., allowing a procedure to execute, or releasing a particular decryption key, only if a given PCR is in a given state).  It may also be important
to designers to consider whether streaming notification of PCR updates is required (see <xref target="I-D.birkholz-rats-network-device-subscription"/>). target="I-D.ietf-rats-network-device-subscription" format="default"/>).  Specific
log entries can only be validated if the Verifier receives every log entry affecting the relevant PCR, so (for example)
a designer might want to separate rare, high-value events events, such as configuration changes, from high-volume, routine
measurements such as IMA logs <xref target="IMA"/> logs.</t> target="IMA" format="default"/>.</t>
        </section>
      </section>
      <section anchor="riv-keying" title="RIV Keying"> numbered="true" toc="default">
        <name>RIV Keying</name>
        <t>RIV attestation relies on two credentials:</t>

<t><list style="symbols">
  <t>An
        <ul spacing="normal">
          <li>An identity key pair and matching certificate is required to certify the identity of the Attester itself.
RIV specifies the use of an IEEE 802.1AR Device Identity (DevID) DevID <xref target="IEEE-802-1AR"/>, target="IEEE-802-1AR" format="default"/> that is
signed by the device manufacturer, containing manufacturer and contains the device serial number.  This requirement goes slightly
beyond 802.1AR; see <xref target="riv-simplify"/> target="riv-simplify" format="default"/> for notes.</t>
  <t>An notes.</li>
          <li>An Attestation key pair and matching certificate is required to sign the Quote generated by the TPM to report evidence
of software configuration.</t>
</list></t> configuration.</li>
        </ul>
        <t>In a TPM application, both the Attestation private key and the DevID private key MUST <bcp14>MUST</bcp14> be protected by the TPM.
Depending on other TPM configuration procedures,
the two keys are likely to be different; some of the considerations are outlined in TCG
“TPM the
"TPM 2.0 Keys for Device Identity and Attestation” Attestation" document <xref target="Platform-DevID-TPM-2.0"/>.</t> target="PLATFORM-DEVID-TPM-2.0" format="default"/>.</t>
        <t>The TCG TPM "TPM 2.0 Keys for Device Identity and Attestation" document <xref target="Platform-DevID-TPM-2.0"/> target="PLATFORM-DEVID-TPM-2.0" format="default"/> specifies further conventions for these keys:</t>

<t><list style="symbols">
  <t>When
        <ul spacing="normal">
<!-- [rfced] Section 2.2. In the following sentence, it is unclear what is examing the certificate. Does the suggestion correctly clarify the actor?

Original:
      This allows a quote from the device, signed by an AK, to be
      linked directly to the device that provided it, by examining
      the corresponding AK certificate.

Perhaps:
      By examining the corresponding AK certificate, the Verifier
      can directly link a device's quote, which was signed by an
      AK, to the device that provided it.
-->
          <li>When separate Identity and Attestation keys are used, the Attestation
Key (AK)
AK and its X.509 certificate should parallel the DevID, with the same unique
device identification as the DevID certificate (that is, the same subject and subjectAltName (if present), even though the key pairs are different).  This allows
a quote from the device, signed by an AK, to be linked directly to the
device that provided it, by examining the corresponding AK certificate.  If the
subject in the AK certificate doesn’t doesn't match the corresponding DevID certificate, or
they’re
if they're  signed by differing authorities different authorities, the Verifier may signal the detection of an Asokan-style person-in-the-middle attack (see <xref target="pitm"/>).</t>
  <t>Network target="pitm" format="default"/>).</li>
          <li>Network devices that are expected to use secure zero touch provisioning SZTP as
specified in <xref target="RFC8572"/>
MUST target="RFC8572" format="default"/>
<bcp14>MUST</bcp14> be shipped by the manufacturer with pre-provisioned keys (Initial DevID and Initial AK,
called IDevID and IAK). IAK, respectively).  IDevID and IAK certificates MUST <bcp14>MUST</bcp14> both be signed by the Endorser
(typically the device manufacturer).  Inclusion of an IDevID and IAK by a vendor does not
preclude a mechanism whereby an administrator can define Local Identity LDevID and
Local Attestation Keys (LDevID and LAK) (LAK) if desired.</t>
</list></t> desired.</li>
        </ul>
      </section>
      <section anchor="RIV-flow" title="RIV numbered="true" toc="default">
        <name>RIV Information Flow"> Flow</name>
        <t>RIV workflow for network equipment is organized around a simple use case
where a network operator wishes to verify the integrity of software installed
in specific, fielded devices.  A normative taxonomy of terms is given in <xref target="I-D.ietf-rats-architecture"/>, target="RFC9334" format="default"/>,
but as a reminder, this use case implies several roles and objects:</t>

<t><list style="numbers">
  <t>The Attester, the
        <dl spacing="normal">
          <dt>Attester:</dt>
          <dd>The device which that the network operator wants to examine.</t>
  <t>A Verifier (which examine.</dd>
          <dt>Verifier:</dt>
          <dd>Which might be a network management station) somewhere Network Management Station and is somewhat separate
  from the Device that will retrieve the signed evidence and measurement logs, and analyze them to pass
  judgment on the security posture of the device.</t>
  <t>A Relying Party, which can device.</dd>
          <dt>Relying Party:</dt>
          <dd>Can act on Attestation Results.  Interaction between the Relying Party and the
  Verifier is considered out of scope for RIV.</t>
  <t>Signed RIV.</dd>
          <dt>Signed Reference Integrity Manifests (RIMs), containing (RIMs):</dt>
          <dd>Contains Reference Values, Values. RIMs can
  either be created by the device manufacturer
  and shipped along with the device as part of its software image, or alternatively,
  could be obtained several other ways (direct to the Verifier from the
  manufacturer, from a third party, from the owner’s observation owner's concept
  of what’s
  thought to be a “known "known good system”, system", etc.).  Retrieving RIMs from the device
  itself allows attestation to be done in systems that may not have access
  to the public internet, Internet, or by other devices that are not management stations
  per se (e.g., a peer device; see <xref target="RIM-policy"/>). target="RIM-policy" format="default"/>).  If Reference Values are obtained from
  multiple sources, the Verifier may need to evaluate the relative level of
  trust to be placed in each source in case of a discrepancy.</t>
</list></t> discrepancy.</dd>
        </dl>
        <t>These components are illustrated in <xref target="RIV-Reference-Configuration"/>.</t> target="RIV-Reference-Configuration" format="default"/>.</t>
        <figure title="RIV anchor="RIV-Reference-Configuration">
          <name>RIV Reference Configuration for Network Equipment" anchor="RIV-Reference-Configuration"><artwork align="left"><![CDATA[ Equipment</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
+----------------+        +-------------+        +---------+--------+
|Reference Value |        | Attester    | Step 1 | Verifier|        |
|Provider        |        | (Device     |<-------| (Network| Relying|
|(Device         |        | under       |------->| Mngmt Mgmt    | Party  |
|Manufacturer    |        | attestation)| Step 2 | Station)|        |
|or other        |        |             |        |         |        |
|authority)      |        |             |        |         |        |
+----------------+        +-------------+        +---------+--------+
       |                                             /\
       |                  Step 0                      |
       -----------------------------------------------

]]></artwork></figure>

<t><list style="symbols">
  <t>In Step 0, The
]]></artwork>
        </figure>
        <ol spacing="normal" type="Step %d:" start="0"  indent="9">
          <li>The Reference Value Provider (the device manufacturer or other authority) makes
one or more Reference Integrity Manifests (RIMs), corresponding RIMs, which correspond to the software image expected to be found on the device, device and are signed by the Reference Value Provider, available to the Verifier
(see Verifier.
(See <xref target="RIM-policy"/> target="RIM-policy" format="default"/> for “in-band” "in-band" and “out "out of band” band" ways to make this happen).</t>
  <t>In Step 1,
the Verifier (Network Management Station), on happen.)</li>
          <li>On behalf of a Relying Party, the Verifier (Network Management Station) requests Identity, DevID,
Measurement Values, and possibly RIMs, RIMs from the Attester.</t>
  <t>In Step 2, the Attester.</li>
          <li>The
Attester responds to the request by providing a DevID, quotes (measured values, values that are signed by the Attester),
and optionally RIMs.</t>
</list></t>

<t>Use RIMs.</li>
        </ol>
        <t>The use of the following standards components allows for interoperability:</t>

<t><list style="numbers">
  <t>TPM Keys MUST
        <ol spacing="normal" type="1"><li>TPM keys <bcp14>MUST</bcp14> be configured according to <xref target="Platform-DevID-TPM-2.0"/>, target="PLATFORM-DEVID-TPM-2.0" format="default"/> or <xref target="Platform-ID-TPM-1.2"/>.</t>
  <t>For target="PLATFORM-ID-TPM-1.2" format="default"/>.</li>
          <li>For devices using UEFI and Linux, measurements of firmware and bootable modules MUST <bcp14>MUST</bcp14> be taken according to TCG PC Client "TCG EFI Platform Specification" <xref target="PC-Client-EFI-TPM-1.2"/> target="PC-CLIENT-EFI-TPM-1.2" format="default"/> or "TCG PC Client Specific Platform Firmware Profile Specification" <xref target="PC-Client-BIOS-TPM-2.0"/>, target="PC-CLIENT-BIOS-TPM-2.0" format="default"/>, and Linux IMA <xref target="IMA"/>.</t>
  <t>Device Identity MUST target="IMA" format="default"/>.</li>
          <li>DevID <bcp14>MUST</bcp14> be managed as DevID certificates as specified in IEEE Std 802.1AR Device Identity certificates <xref target="IEEE-802-1AR"/>, target="IEEE-802-1AR" format="default"/>, with keys protected by TPMs.</t>
  <t>Attestation TPMs.</li>
          <li>Attestation logs from Linux-based systems MUST <bcp14>MUST</bcp14> be formatted according to the Canonical "Canonical Event Log format Format" <xref target="Canonical-Event-Log"/>. target="CEL" format="default"/>.  UEFI-based systems MUST <bcp14>MUST</bcp14> use the TCG UEFI BIOS event log <xref target="PC-Client-EFI-TPM-1.2"/> target="PC-CLIENT-EFI-TPM-1.2" format="default"/> for TPM1.2 systems, TPM 1.2 systems and TCG the "TCG PC Client Specific Platform Firmware Profile Profile" <xref target="PC-Client-BIOS-TPM-2.0"/> target="PC-CLIENT-BIOS-TPM-2.0" format="default"/> for TPM2.0.</t>
  <t>Quotes MUST TPM 2.0 systems.</li>
          <li>Quotes <bcp14>MUST</bcp14> be retrieved from the TPM according to the TCG TAP Trusted Attestation Protocol Information Model (TAP IM) <xref target="TAP"/> target="TAP" format="default"/> and the CHARRA Challenge-Response-based Remote Attestation (CHARRA) YANG model <xref target="I-D.ietf-rats-yang-tpm-charra"/>. target="RFC9684" format="default"/>.  While the TAP IM gives a protocol-independent description of the data elements involved, it’s it's important to note that quotes from the TPM are signed inside the TPM, TPM and MUST <bcp14>MUST</bcp14> be retrieved in a way that does not invalidate the signature, to preserve the trust model.  The CHARRA YANG model <xref target="I-D.ietf-rats-yang-tpm-charra"/> target="RFC9684" format="default"/> is used for this purpose.  (See <xref target="security-cons"/> target="security-cons" format="default"/>, Security Considerations).</t>
  <t>Reference Considerations).</li>
<!-- [rfced] Section 2.3. Are Reference Values encoded in two ways (SWID and CoSWID) or three ways (SWID, NIST interoperable SWID tags, and COSWID)?

Original:
   6.  Reference Values MUST be encoded as defined in the TCG RIM
       document <xref target="RIM"/>, [RIM], typically using SWID [SWID], [NIST-IR-8060] or
       CoSWID tags [I-D.ietf-sacm-coswid].

Perhaps (encoding is done in one of two ways):
   6.  Reference Values MUST be encoded as defined in the TCG RIM
       document [RIM], typically using SWID tags [SWID] [NIST-IR-8060] or
       CoSWID tags [RFC9393].
-->

          <li>Reference Values <bcp14>MUST</bcp14> be encoded  as defined in
  the TCG RIM document <xref target="SWID"/>, target="RIM" format="default"/>, typically using Software Identification (SWID) <xref target="SWID" format="default"/>, <xref target="NIST-IR-8060"/> target="NIST-IR-8060" format="default"/>, or CoSWID Concise SWID (CoSWID) tags <xref target="I-D.ietf-sacm-coswid"/>.</t>
</list></t> target="RFC9393" format="default"/>.</li>
        </ol>
      </section>
      <section anchor="riv-simplify" title="RIV numbered="true" toc="default">
        <name>RIV Simplifying Assumptions"> Assumptions</name>
        <t>This document makes the following simplifying assumptions to reduce complexity:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The product to be attested MUST <bcp14>MUST</bcp14> be shipped by the equipment vendor with both an a DevID as specified by IEEE Std 802.1AR Device Identity and an Initial
Attestation Key (IAK), IAK, with certificates in place.  The IAK certificate must contain the same identity
information as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer).  The IAK is a type of key that can be
used to sign a TPM Quote, but not other objects (i.e., it’s it's marked as a TCG “Restricted” "Restricted" key;
this convention is described in
“TPM
"TPM 2.0 Keys for Device Identity and Attestation” Attestation" <xref target="Platform-DevID-TPM-2.0"/>). target="PLATFORM-DEVID-TPM-2.0" format="default"/>). For network equipment, which is generally non-privacy-sensitive, not privacy sensitive, shipping
a device with both an IDevID and an IAK already provisioned substantially
simplifies initial startup.</t> startup.</li>
          <li>
            <t>IEEE Std 802.1AR does not require a product serial number as part of the subject, but RIV-compliant
devices MUST <bcp14>MUST</bcp14> include their serial numbers in the DevID/IAK certificates to simplify tracking logistics
for network equipment users.  All other optional
802.1AR fields remain optional in RIV.<vspace /> RIV.</t>
            <t>
It should be noted that 802.1AR the use of X.509 certificate fields as specified by IEEE Std 802.1AR
is not identical to those descsribed that described in <xref target="RFC6125"/> target="RFC9525" format="default"/> for representation of application service identity.</t>
  <t>The
          </li>
          <li>The product MUST <bcp14>MUST</bcp14> be equipped with an RTM, a Root of Trust
for Measurement (RTM), Root of Trust
for Storage Storage, and a Root of Trust for Reporting (as defined in <xref target="SP800-155"/>) target="SP800-155" format="default"/>), which together are
capable of conforming to the TCG Trusted Attestation Protocol Information Model TAP IM <xref target="TAP"/>.</t>
  <t>The target="TAP" format="default"/>.</li>
          <li>The authorized software supplier MUST <bcp14>MUST</bcp14> make available Reference Values
in the form of signed SWID or CoSWID tags.</t>
</list></t> tags.</li>
        </ul>
        <section anchor="RIM-section" title="Reference numbered="true" toc="default">
          <name>Reference Integrity Manifests (RIMs)"> (RIMs)</name>
          <t><xref target="I-D.ietf-rats-yang-tpm-charra"/> target="RFC9684" format="default"/> focuses on collecting and transmitting evidence in
the form of PCR measurements and attestation logs.  But the critical part
of the process is enabling the Verifier to decide whether the measurements
are “the "the right ones” ones" or not.</t>
          <t>While it must be up to network administrators to decide what they want on
their networks, the software supplier should supply the Reference Values, in
signed Reference Integrity Manifests, RIMs, that
may be used by a Verifier to determine if evidence shows known good, known
bad
bad, or unknown software configurations.</t>
          <t>In general, there are two kinds of reference measurements:</t>

<t><list style="numbers">
  <t>Measurements
          <ol spacing="normal" type="1"><li>Measurements of early system startup (e.g., BIOS, boot loader, OS kernel)
are essentially single-threaded, single threaded and executed exactly once, in a known sequence,
before any results could can be reported.  In this case, while the method for
computing the hash and extending relevant PCRs may be complicated, the net
result is that the software (more likely, firmware) vendor will have one
known good PCR value that “should” "should" be present in the relevant PCRs after the box has
booted.  In this case, the signed reference measurement could simply list the
expected hashes for the given version.  However, a RIM that contains the
intermediate hashes can be useful in debugging cases where the expected final hash
is not the one reported.</t>
  <t>Measurements reported.</li>
            <li>Measurements taken later in operation of the system, once an OS has started
(for example, Linux IMA <xref target="IMA"/>), target="IMA" format="default"/>), may be more complex, with unpredictable “final” "final"
PCR values.  In this case, the Verifier must have enough information to reconstruct
the expected PCR values from logs and signed reference measurements from
a trusted authority.</t>
</list></t> authority.</li>
          </ol>
          <t>In both cases, the expected values can be expressed as signed SWID or CoSWID tags,
but the SWID structure in the second case is somewhat more complex, as reconstruction of the extended hash in a PCR may involve thousands of files and other objects.</t>
          <t>TCG has published an information model defining elements of Reference Integrity
Manifests RIMs
under the title TCG "TCG Reference Integrity Manifest (RIM) Information Model Model" <xref target="RIM"/>. target="RIM" format="default"/>.  This information model outlines how SWID tags should be structured to allow attestation, and it defines “bundles” "bundles" of SWID tags that may be needed to describe a complete software release.  The RIM contains metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested.</t>
          <t>Many network equipment vendors use a UEFI BIOS to launch their network operating system.  These vendors may want to
also use the TCG "TCG PC Client Reference Integrity Measurement specification Manifest Specification" <xref target="PC-Client-RIM"/>, target="PC-CLIENT-RIM" format="default"/>, which focuses specifically on a SWID-compatible format suitable for expressing measurement values expected from a UEFI BIOS.</t>
        </section>
        <section anchor="attestation-logs" title="Attestation Logs"> numbered="true" toc="default">
          <name>Attestation Logs</name>
          <t>Quotes from a TPM can provide evidence of the state of a device up to the time
the evidence was recorded, but recorded. However, to make sense of the quote in cases where several events are extended into one PCR PCR, an
event log that identifies which software modules contributed which values to the quote
during startup must also be provided.  When required, the log MUST <bcp14>MUST</bcp14> contain enough information
to demonstrate its integrity by allowing exact reconstruction of the digest
conveyed in the signed quote (that is, calculating the hash of all the hashes in the
log should produce the same values as contained in the PCRs; if they don’t don't match, the log
may have been tampered with.  See <xref target="using-tpm"/>).</t> target="using-tpm" format="default"/>).</t>
          <t>There are multiple event log formats which that may be supported as viable formats of Evidence between the Attester and Verifier,
but Verifier;
however, to simplify interoperability, RIV focuses on just three:</t>

<t><list style="symbols">
  <t>TCG
          <ol spacing="normal" type="1">
            <li>TCG UEFI BIOS event log for TPM 2.0 (TCG ("TCG PC Client Specific Platform Firmware Profile) Profile Specification") <xref target="PC-Client-BIOS-TPM-2.0"/></t>
  <t>TCG target="PC-CLIENT-BIOS-TPM-2.0" format="default"/></li>
            <li>TCG UEFI BIOS event log for TPM 1.2 (TCG ("TCG EFI Platform Specification Specification" for TPM Family 1.1 or
1.2, Section 7) <xref target="PC-Client-EFI-TPM-1.2"/></t>
  <t>TCG Canonical target="PC-CLIENT-EFI-TPM-1.2" format="default"/></li>
            <li>TCG "Canonical Event Log Format" <xref target="Canonical-Event-Log"/></t>
</list></t> target="CEL" format="default"/></li>
          </ol>
        </section>
      </section>
    </section>
    <section anchor="standards-components" title="Standards Components"> numbered="true" toc="default">
      <name>Standards Components</name>
      <section anchor="prerequisites-for-riv" title="Prerequisites numbered="true" toc="default">
        <name>Prerequisites for RIV"> RIV</name>
        <t>The Reference Interaction Model for Challenge-Response-based Remote Attestation (<xref target="I-D.birkholz-rats-reference-interaction-model"/>) target="I-D.ietf-rats-reference-interaction-models" format="default"/>)
is based on the standard roles defined in <xref target="I-D.ietf-rats-architecture"/>. target="RFC9334" format="default"/>.  However, additional prerequisites have been established to allow for interoperable implementations of RIV use case implementations. cases.  These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester.</t>
        <section anchor="unique-device-identity" title="Unique numbered="true" toc="default">
          <name>Unique Device Identity"> Identity</name>
          <t>A secure Device Identity (DevID) DevID in the form of an IEEE 802.1AR a DevID certificate as specified by IEEE Std 802.1AR <xref target="IEEE-802-1AR"/> target="IEEE-802-1AR" format="default"/> must be provisioned in the Attester’s Attester's TPMs.</t>
        </section>
        <section anchor="keys" title="Keys"> numbered="true" toc="default">
          <name>Keys</name>
          <t>The Attestation Key (AK) AK and certificate must also be provisioned on the Attester according to <xref target="Platform-DevID-TPM-2.0"/>, target="PLATFORM-DEVID-TPM-2.0" format="default"/> or <xref target="Platform-ID-TPM-1.2"/>.</t> target="PLATFORM-ID-TPM-1.2" format="default"/>.</t>
          <t>It MUST <bcp14>MUST</bcp14> be possible for the Verifier to determine that the Attester’s Attestation keys Attester's AKs are resident in the same TPM as its DevID keys (see <xref target="riv-keying"/> target="riv-keying" format="default"/> and <xref target="security-cons"/> target="security-cons" format="default"/>, Security Considerations).</t>
        </section>
        <section anchor="RIM-policy" title="Appraisal numbered="true" toc="default">
          <name>Appraisal Policy for Evidence"> Evidence</name>
          <t>As noted in <xref target="RIV-flow"/>, target="RIV-flow" format="default"/>, the Verifier may obtain Reference Values from several sources.  In addition, administrators may make authorized, site-specific changes (e.g. (e.g., keys in key databases) that could impact attestation results.  As such, there could be conflicts, omissions omissions, or ambiguities between some Reference Values and collected Evidence.</t>
          <t>The Verifier MUST <bcp14>MUST</bcp14> have an Appraisal Policy for Evidence to evaluate the significance of any discrepancies between different reference sources, or between reference values Reference Values and evidence from logs and quotes.
While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party.</t>
        </section>
      </section>
      <section anchor="reference-model-for-challenge-response" title="Reference numbered="true" toc="default">
        <name>Reference Model for Challenge-Response"> Challenge-Response</name>
        <t>Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester.  The following diagram  <xref target="IETF-Attestation-Information-Flow" format="default"/> illustrates a RIV information flow between a Verifier and an Attester,
derived from Section 7.1 of <xref target="I-D.birkholz-rats-reference-interaction-model"/>. target="I-D.ietf-rats-reference-interaction-models" format="default"/>.  In this diagram, each event with its
input and output parameters is shown as “Event(input-params)=&gt;(outputs)”.
Event "Event(input-params)=&gt;(outputs)".
The event times shown correspond to the time types described within Appendix A of <xref target="I-D.ietf-rats-architecture"/>:</t> target="RFC9334" section="A" sectionFormat="of" format="default"/>:</t>
        <figure title="IETF anchor="IETF-Attestation-Information-Flow">
          <name>IETF Attestation Information Flow" anchor="IETF-Attestation-Information-Flow"><artwork align="left"><![CDATA[ Flow</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
.----------.                               .-----------------------.
| Attester |                              | Relying Party/Verifier |
'----------'                              '------------------------'
  time(VG)                                                      |
generateClaims(attestingEnvironment)                            |
   | => claims, eventLogs                                       |
   |                                                            |
   |                                                        time(NS)
   | <-- requestAttestation(handle, authSecIDs, claimSelection) |
   |                                                            |
 time(EG)                                                       |
collectClaims(claims, claimSelection)                           |
   | => collectedClaims                                         |
   |                                                            |
generateEvidence(handle, authSecIDs, collectedClaims)           |
   | => evidence                                                |
   |                                                    time(RG,RA)
   | evidence, eventLogs -------------------------------------> |
   |                                                            |
   |               appraiseEvidence(evidence, eventLogs, refValues)
   |                                       attestationResult <= |
   |                                                            |
   ~                                                            ~
   |                                                       time(RX)
]]></artwork></figure>

<t><list style="symbols">
  <t>Step
]]></artwork>
        </figure>
        <dl spacing="normal">
          <dt>Step 1 (time(VG)): One (time(VG)):</dt><dd>One or more Attesting Network Device attesting network device PCRs are extended with measurements.  RIV provides no direct link between
the time at which the event takes place and the time that it’s it's attested, although streaming attestation as described in <xref target="I-D.birkholz-rats-network-device-subscription"/> could.</t>
  <t>Step target="I-D.ietf-rats-network-device-subscription" format="default"/> could.</dd>
<!-- [rfced] Section 3.2. FYI, we will update the title of RFC 9684 when it is finalized. -->
          <dt>Step 2 (time(NS)): The (time(NS)):</dt><dd>The Verifier generates a unique random nonce (“number ("number used once”), once") and makes a request for one or more PCRs from an Attester.  For interoperability, this must be accomplished as specified in the "A YANG Data Model for Challenge-Response-based Challenge-Response-Based Remote Attestation (CHARRA) Procedures using TPMs Using Trusted Platform Modules (TPMs)" <xref target="I-D.ietf-rats-yang-tpm-charra"/>.  TPM1.2 target="RFC9684" format="default"/>.  Both TPM 1.2 and TPM2.0 both TPM 2.0 allow nonces as large as the operative digest size (i.e., 20 or 32 bytes; see <xref target="TPM1.2"></xref> target="TPM-1.2" format="default"/> Part 2, Section 5.5 5.5, and <xref target="TPM2.0"></xref> target="TPM-2.0" format="default"/> Part 2, Section 10.4.4).</t>
  <t>Step 10.4.4).</dd>
          <dt>Step 3 (time(EG)): On (time(EG)):</dt><dd>On the Attester, measured values are retrieved from the Attester’s Attester's TPM. This requested PCR evidence, evidence
along with the Verifier’s nonce, Verifier's nonce is called a Quote, Quote and is signed by the Attestation Key (AK) AK associated with the DevID.  Quotes are retrieved according to the CHARRA YANG model <xref target="I-D.ietf-rats-yang-tpm-charra"/>. target="RFC9684" format="default"/>.  At the same time, the Attester collects log evidence showing the values have been extended into that PCR.  <xref target="using-tpm"/> target="using-tpm" format="default"/> gives more detail on how this works, including works and includes references to the structure and contents of quotes in TPM documents.</t>
  <t>Step 4: Collected documents.</dd>
          <dt>Step 4:</dt><dd>The collected Evidence is passed from the Attester to the Verifier</t>
  <t>Step Verifier.</dd>

            <dt>Step 5 (time(RG,RA)): The (time(RG,RA)):</dt><dd><t>The Verifier reviews the Evidence and takes action as needed.  As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step.  <list style="symbols">
      <t>If step.</t>
            <ul spacing="normal">
              <li>If the signature covering TPM Evidence is not correct, the device SHOULD NOT <bcp14>SHOULD NOT</bcp14> be trusted.</t>
      <t>If trusted.</li>
              <li>If the nonce in the response doesn’t doesn't match the Verifier’s Verifier's nonce, the response may be a replay, and the device SHOULD NOT <bcp14>SHOULD NOT</bcp14> be trusted.</t>
      <t>If trusted.</li>
              <li>If the signed PCR values do not match the set of log entries which that have extended a particular PCR, the device SHOULD NOT <bcp14>SHOULD NOT</bcp14> be trusted.</t>
      <t>If trusted.</li>
              <li>If the log entries that the Verifier considers important do not match known good values, the device SHOULD NOT <bcp14>SHOULD NOT</bcp14> be trusted.  We note that the process of collecting and analyzing the log can be omitted if the value in the relevant PCR is already a known-good value.</t>
      <t>If value.</li>
              <li>If the set of log entries are not seen as acceptable by the Appraisal Policy for Evidence, the device SHOULD NOT <bcp14>SHOULD NOT</bcp14> be trusted.</t>
      <t>If trusted.</li>
              <li>If time(RG)-time(NS) is greater than the Appraisal Policy for Evidence’s Evidence's threshold for assessing freshness, the Evidence is considered stale and SHOULD NOT <bcp14>SHOULD NOT</bcp14> be trusted.</t>
    </list></t>
</list></t> trusted.</li>
	    </ul>
	  </dd>
        </dl>
        <section anchor="transport-and-encoding" title="Transport numbered="true" toc="default">
          <name>Transport and Encoding"> Encoding</name>
          <t>Network Management systems may retrieve signed PCR based PCR-based Evidence using NETCONF or RESTCONF with <xref target="I-D.ietf-rats-yang-tpm-charra"/>. target="RFC9684" format="default"/>.
In either case, implementatations implementations must do so using a secure tunnel.</t>
          <t>Log Evidence MUST <bcp14>MUST</bcp14> be retrieved via log interfaces specified in <xref target="I-D.ietf-rats-yang-tpm-charra"/>.</t> target="RFC9684" format="default"/>.</t>
        </section>
      </section>
      <section anchor="peer-to-peer" title="Centralized vs Peer-to-Peer"> numbered="true" toc="default">
        <name>Centralized vs. Peer-to-Peer</name>
        <t><xref target="IETF-Attestation-Information-Flow"/> above target="IETF-Attestation-Information-Flow" format="default"/> assumes that the Verifier is trusted, while the Attester is not.  In a Peer-to-Peer peer-to-peer application such as two routers negotiating a trust relationship, the two peers can each ask the other to prove software integrity.  In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier.  Each device issues a challenge, and each device responds to the other’s other's challenge, as shown in <xref target="Peer-to-peer-Information-Flow"/>. target="Peer-to-peer-Information-Flow" format="default"/>.  Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs).  Devices may also have to carry an Appraisal Policy for Evidence for each possible peer device so that each device has everything needed for remote attestation, without having to resort to a central authority.</t>
        <figure title="Peer-to-Peer anchor="Peer-to-peer-Information-Flow">
          <name>Peer-to-Peer Attestation Information Flow" anchor="Peer-to-peer-Information-Flow"><artwork align="left"><![CDATA[ Flow</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
+---------------+                            +---------------+
| RefVal        |                            | RefVal        |
| Provider A    |                            | Provider B    |
| Firmware      |                            | Firmware      |
| Configuration |                            | Configuration |
| Authority     |                            | Authority     |
|               |                            |               |
+---------------+                            +---------------+
      |                                             |
      |                                             |Step 0B
      |       +------------+        +------------+  |
      |       |            | Step 1 |            |  |   \
      |       | Attester   |<------>| Verifier   |  |   |
      |       |            |<------>|            |  |   |  Router B
      +------>|            | Step 2 |            |  |   |- Challenges
       Step 0A|            |        |            |  |   |  Router A
              |            |------->|            |  |   |
              |- Router A -| Step 3 |- Router B -|  |   /
              |            |        |            |  |
              |            |        |            |  |
              |            | Step 1 |            |  |   \
              | Verifier   |<------>| Attester   |<-+   |  Router A
              |            |<------>|            |      |- Challenges
              |            | Step 2 |            |      |  Router B
              |            |        |            |      |
              |            |<-------|            |      |
              +------------+ Step 3 +------------+      /

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In this application, each device may need to be equipped with signed RIMs to act as an Attester, and also to allow each device to act as a Verifier, each may need to be equipped with an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates, to allow the device to act as a Verifier. certificates also.   An existing link layer protocol such as 802.1X <xref target="IEEE-802.1X"/> target="IEEE-802.1X" format="default"/> or 802.1AE <xref target="IEEE-802.1AE"/>, target="IEEE-802.1AE" format="default"/>, with Evidence being enclosed over a variant of EAP the Extensible Authentication Protocol (EAP) <xref target="RFC3748"/> target="RFC3748" format="default"/> or LLDP Link Layer Discovery Protocol (LLDP) <xref target="LLDP"/> target="LLDP" format="default"/>, are suitable methods for such an exchange.
Details of peer-to-peer operation are out of scope for this document.</t>
      </section>
    </section>
    <section anchor="privacy-considerations" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>Network equipment, such as routers, switches switches, and firewalls, has a key role to play in guarding the privacy of individuals using the network.  Network equipment generally adheres to several rules to protect privacy:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>Packets passing through the device must not be sent to unauthorized destinations.  For example:  <list style="symbols">
      <t>Routers  </t>
          <ul spacing="normal">
            <li>Routers often act as Policy Enforcement Points, where individual subscribers may be checked for
authorization to access a network.  Subscriber login information must not be released to unauthorized parties.</t>
      <t>Network parties.</li>
            <li>Network equipment is often called upon to block access to protected resources from unauthorized users.</t>
    </list></t>
  <t>Routing users.</li>
          </ul>
        </li>
        <li>Routing information, such as the identity of a router’s router's peers, must not be leaked to unauthorized neighbors.</t>
  <t>If neighbors.</li>
        <li>If configured, encryption and decryption of traffic must be carried out reliably, while protecting keys and credentials.</t>
</list></t> credentials.</li>
      </ul>
      <t>Functions that protect privacy are implemented as part of each layer of hardware and software that
makes up the networking device.
In light of these requirements for protecting the privacy of users of the network, the network equipment
must identify itself, and its boot configuration and measured device state (for example, PCR values),
to the equipment’s administrator, equipment's administrator so there’s there's no uncertainty as to what about the device's function each device and
configuration is configured to carry out.
configuration. Attestation is a component that allows the administrator to ensure that the network
provides individual and peer privacy guarantees, even though the device itself may not have a
right to keep its identity secret.</t>
      <t>See <xref target="NetEq"/> target="NET-EQ" format="default"/> for more context on privacy in networking devices.</t>
      <t>While attestation information from network devices is not likely to contain privacy-sensitive content regarding
network users, administrators may want to keep attestation records confidential to avoid disclosing versions of
software loaded on the device, information which is information that could facilitate attacks against known vulnerabilities.</t>
    </section>
    <section anchor="security-cons" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Specifications such as TLS <xref target="RFC8446"/> (TLS) target="RFC8446" format="default"/> and YANG <xref target="RFC7950"/> (YANG) target="RFC7950" format="default"/> contain considerable advice on keeping
network-connected systems secure.  This section outlines specific risks and mitigations related to attestation.</t>
      <t>Attestation Evidence obtained by the RIV procedure is subject to a number of attacks:</t>

<t><list style="symbols">
  <t>Keys
      <ul spacing="normal">
        <li>Keys may be compromised.</t>
  <t>A compromised.</li>
        <li>A counterfeit device may attempt to impersonate (spoof) a known authentic device.</t>
  <t>Person-in-the-middle device.</li>
        <li>Person-in-the-middle attacks may be used by a compromised device to attempt to deliver
responses that originate in an authentic device.</t>
  <t>Replay device.</li>
        <li>Replay attacks may be attempted by a compromised device.</t>
</list></t> device.</li>
      </ul>
      <section anchor="keys-used-in-riv" title="Keys numbered="true" toc="default">
        <name>Keys Used in RIV"> RIV</name>
        <t>Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity
and attestation reports.  RIV takes full advantage of TPM capabilities to ensure that evidence can be trusted.</t>
        <t>Two sets of key-pairs key pairs are relevant to RIV attestation:</t>

<t><list style="symbols">
  <t>A
<!-- [rfced] Section 5.1. Is the AK used to certify the device identity or is it the AK key pair?

Original:
   *  A DevID key-pair is used to certify the identity of the device in
      which the TPM is installed.</t>
  <t>An installed.

   *  An Attestation Key-pair (AK) key is used to certify attestation
      Evidence (called ‘quotes’ 'quotes' in TCG documents), used to provide
      evidence for integrity of the software on the device</t>
</list></t> device

Perhaps:
   *  A DevID key pair is used to certify the identity of the device in
      which the TPM is installed.

   *  An AK key pair is used to certify attestation
      Evidence (i.e., quotes) and to provide
      evidence for the integrity of the device software.
-->
        <ul spacing="normal">
          <li>A DevID key pair is used to certify the identity of the device in which the TPM is installed.</li>
          <li>An Attestation Key pair (AK) key is used to certify attestation Evidence (called "quotes" in TCG documents),
used to provide evidence for integrity of the software on the device</li>
        </ul>
        <t>TPM practices usually require that these keys be different, as a way of ensuring different to ensure that a general-purpose
signing key cannot be used to spoof an attestation quote.</t>
        <t>In each case, the private half of the key is known only to the TPM, TPM and cannot be
retrieved externally, even by a trusted party.  To ensure that’s that's the case,
specification-compliant private/public key-pairs key pairs are generated inside the TPM, where they are never
exposed,
exposed and cannot be extracted (See (see <xref target="Platform-DevID-TPM-2.0"/>).</t> target="PLATFORM-DEVID-TPM-2.0" format="default"/>).</t>
        <t>Keeping keys safe is a critical enabler of trustworthiness, but it’s it's just part of attestation security; knowing which keys are bound
to the device in question is just as important in an environment where private keys are never exposed.</t>
        <t>While there are many ways to manage keys in a TPM (see <xref target="Platform-DevID-TPM-2.0"/>), target="PLATFORM-DEVID-TPM-2.0" format="default"/>), RIV includes
support for “zero touch” "zero touch" provisioning (also known as zero-touch zero touch onboarding) of fielded
devices (e.g., Secure ZTP, SZTP <xref target="RFC8572"/>), target="RFC8572" format="default"/>), where keys which that have predictable trust properties are
provisioned by the device vendor.</t>
        <t>Device identity in RIV is based on DevID defined by IEEE 802.1AR Device Identity (DevID). Std 802.1AR. This specification provides several elements:</t>

<t><list style="symbols">
  <t>A
        <ul spacing="normal">
          <li>A DevID requires a unique key pair for each device, accompanied by an X.509 certificate,</t>
  <t>The certificate.</li>
          <li>The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5 of <xref target="IEEE-802-1AR"/>)</t>
</list></t> target="IEEE-802-1AR" format="default"/>).</li>
        </ul>
        <t>The X.509 certificate contains several components:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The public part of the unique DevID key assigned to that device allows a challenge of identity.</t>
  <t>An identity.</li>
          <li>An identifying string that’s that's unique to the manufacturer of the device.  This is normally the
serial number of the unit, which might also be printed on a label on the device.</t>
  <t>The device.</li>
          <li>The certificate must be signed by a key traceable to the manufacturer’s manufacturer's root key.</t>
</list></t> key.</li>
        </ul>
        <t>With these elements, the device’s device's manufacturer and serial number can be identified by analyzing the
DevID certificate plus the chain of intermediate certificates leading back to the manufacturer’s manufacturer's root
certificate.  As is conventional in TLS or SSH connections, a random nonce must be signed by the device
in response to a challenge,
proving possession of its DevID private key.</t>
        <t>RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins.  Security of
this process derives from TLS or SSH security, with the DevID, containing which contains a device serial number, providing proof that the session terminates on
the intended device. See <xref target="RFC8446"/>, target="RFC8446" format="default"/> <xref target="RFC4253"/>.</t> target="RFC4253" format="default"/>.</t>
        <t>Evidence of software integrity is delivered in the form of a quote that is signed by the TPM
itself,
itself and accompanied by an IAK certificate containing the same identity information as the DevID.  Because the contents of the quote are signed inside the TPM, any external
modification (including reformatting to a different data format) after measurements have been taken will be detected
as tampering.  An unbroken chain of trust is essential to for ensuring that blocks of code that are taking
measurements have been verified before execution (see <xref target="RIV-Attestation-Model"/>).</t>

<t>Requiring target="RIV-Attestation-Model" format="default"/>).</t>
<!-- [rfced] Section 5.1. Does splitting the sentence below into two and reorganizing the later half of it improve readability?

Original:
   Requiring measurements of the operating software to be signed by a
   key known only to the TPM also removes the need to trust the device’s device's
   operating software (beyond the first measurement in the RTM; see
   below); any changes to the quote, generated and signed by the TPM
   itself, made by malicious device software, or in the path back to the
   Verifier, will invalidate the signature on the quote.

Perhaps:
   Requiring measurements of the operating software to be signed by a
   key known only to the TPM also removes the need to trust the device's
   operating software (beyond the first measurement in the RTM; see
   below).  If malicious device software makes any changes to a quote
   or in the path back to the Verifier, the signature on the quote will
   be invalidated.
-->
        <t>Requiring measurements of the operating software to be signed by a key known only to the TPM also
removes the need to trust the device's operating software (beyond the first measurement in the RTM; see below). Any
changes to the quote, generated and signed by the TPM itself, made by malicious device software, or in
the path back to the Verifier, will invalidate the signature on the quote.</t>
<!-- [rfced] Section 5.1. Does "compress out" in the following mean to "remove" or to "reduce"?

Original:
   While alternate methods of conveying TPM quotes could compress out
   redundant information,
-->
        <t>A critical feature of the YANG model described in <xref target="I-D.ietf-rats-yang-tpm-charra"/> target="RFC9684" format="default"/> is the ability to carry TPM data structures in their TCG-defined format, without requiring any changes to the structures as they were signed and delivered by the TPM.  While alternate methods of conveying TPM quotes could compress out redundant information, or add another layer of signing using external keys, the implementation MUST <bcp14>MUST</bcp14> preserve the TPM signing, signing so that tampering anywhere in the path between the TPM itself and the Verifier can be detected.</t>
      </section>
      <section anchor="pitm" title="Prevention numbered="true" toc="default">
        <name>Prevention of Spoofing and Person-in-the-Middle Attacks"> Attacks</name>
        <t>Prevention of spoofing attacks against attestation systems is also important.  There are several cases to consider:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The entire device could be spoofed. If the Verifier goes to appraise a specific Attester, it might be redirected to a different Attester.</t>
  <t>A Attester.</li>
          <li>A compromised device could have a valid DevID, but substitute a quote from a knonwn-good device, known-good device instead of returning its own, as described in <xref target="RFC6813"/>.</t>
  <t>A target="RFC6813" format="default"/>.</li>
          <li>A device with a compromised OS could return a fabricated quote providing spoofed attestation Evidence.</t>
</list></t> Evidence.</li>
        </ul>
        <t>Use of the 802.1AR Device Identity (DevID) DevID in the TPM provides protection against the case of a spoofed device, device by ensuring that the Verifier’s Verifier's TLS or SSH session is in fact terminating on the right device.</t>
        <t>Protection against spoofed quotes from a device with valid identity is a bit more complex.
An identity key must be available to sign any kind of nonce or hash offered by the Verifier,
and consequently, could be used to sign a fabricated quote.  To block a spoofed Attestation
Result, the quote generated inside the TPM must be signed by
a key that’s key, known as an AK, that's different from the DevID, called an Attestation Key (AK).</t> DevID.</t>
        <t>Given separate Attestation and DevID keys, the
binding between the AK and the same device must also be proven to
prevent a person-in-the-middle attack (e.g., the ‘Asokan Attack’ "Asokan Attack" <xref target="RFC6813"/>).</t> target="RFC6813" format="default"/>).</t>
        <t>This is accomplished in RIV through use of an AK certificate with the same elements as the DevID
(same manufacturer’s manufacturer's serial number, number and signed by the same manufacturer’s manufacturer's key), but containing
the device’s device's unique AK public key instead of the DevID public key.
This binding between DevID and AK certificates is critical to reliable attestation.</t>
        <t>The TCG document TPM "TPM 2.0 Keys for Device Identity and Attestation Attestation" <xref target="Platform-DevID-TPM-2.0"/> target="PLATFORM-DEVID-TPM-2.0" format="default"/> specifies
OIDs for Attestation Certificates that allow the CA to mark a key as specifically known to be
an Attestation key.</t> AK.</t>
        <t>These two key-pairs key pairs and certificates are used together:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The DevID is used to validate a TLS connection terminating on the device with a known serial number.</t>
  <t>The number.</li>
          <li>The AK is used to sign attestation quotes, providing which provides proof that the attestation
evidence comes from the same device.</t>
</list></t> device.</li>
        </ul>
      </section>
      <section anchor="replay-attacks" title="Replay Attacks"> numbered="true" toc="default">
        <name>Replay Attacks</name>
        <t>Replay attacks, where the results of a previous attestation are submitted in response to subsequent requests,
are usually prevented by the inclusion of a random nonce in the request to the TPM
for a quote.  Each request from the Verifier includes a new random number (a nonce). The resulting
quote signed by the TPM contains the same nonce, allowing which allows the Verifier to determine
freshness,
freshness (i.e., that the resulting quote was generated in response to the Verifier’s Verifier's specific request).
Time-Based Uni-directional Attestation
"Time-Based Uni-Directional Attestation" <xref target="I-D.birkholz-rats-tuda"/> target="I-D.birkholz-rats-tuda" format="default"/> provides an alternate mechanism
to verify freshness without requiring a request/response cycle.</t>
      </section>
      <section anchor="owner-signed-keys" title="Owner-Signed Keys"> numbered="true" toc="default">
        <name>Owner-Signed Keys</name>
        <t>Although device manufacturers must pre-provision devices with easily verified DevID and AK certificates
if zero-touch provisioning SZTP such as described in <xref target="RFC8572"/> target="RFC8572" format="default"/> is to be supported,
use of those credentials is not mandatory.  IEEE Std 802.1AR incorporates the idea of an Initial Device ID
(IDevID),
IDevID, which is provisioned by the manufacturer, and a Local Device ID (LDevID) LDevID, which is provisioned by the owner of
the device.  RIV and <xref target="Platform-DevID-TPM-2.0"/> extends target="PLATFORM-DEVID-TPM-2.0" format="default"/> extend that concept by defining an Initial Attestation Key (IAK) IAK and Local Attestation
Key (LAK)
LAK with the same properties.</t>
        <t>Device owners can use any method to provision the Local local credentials.</t>

<t><list style="symbols">
  <t>TCG
        <ul spacing="normal">
          <li>The TCG document <xref target="Platform-DevID-TPM-2.0"/> target="PLATFORM-DEVID-TPM-2.0" format="default"/> shows how the initial Attestation
keys IAKs
can be used to certify LDevID and LAK keys.  Use  The use of the LDevID and LAK allows the device owner
to use a uniform identity structure across device types from multiple manufacturers (in the same way
that an “Asset Tag” "Asset Tag" is used by many enterprises to identify devices they own).  The TCG document
<xref target="Provisioning-TPM-2.0"/> target="PROV-TPM-2.0" format="default"/> also contains guidance on provisioning Local local identity keys in TPM 2.0.
Owners should follow the same practice of binding Local DevID LDevID and Local AK LAK as the manufacturer would for IDevID and IAK.
See Section <xref target="riv-keying"/>.</t>
  <t>Device target="riv-keying" format="default"/>.</li>
          <li>Device owners, however, can use any other mechanism they want want, including physical inspection and programming in a secure location, to assure themselves that local identity
certificates are inserted into the intended device, including physical inspection and programming
in a secure location, device
if they prefer to avoid placing trust in the manufacturer-provided keys.</t>
</list></t> keys.</li>
        </ul>
        <t>Clearly, local keys can’t can't be used for secure Zero Touch provisioning; SZTP; installation of the local keys
can only be done by some process that runs before the device is installed for network operation,
or by using procedures such as those outlined in Bootstrapping Remote Secure Key Infrastructure (BRSKI) <xref target="RFC8995"/>.</t> target="RFC8995" format="default"/>.</t>
        <t>On the other end of the device life cycle, lifecycle, provision should be made to wipe local keys when a device
is decommissioned, decommissioned to indicate that the device is no longer owned by the enterprise.  The manufacturer’s
Initial manufacturer's
initial identity keys must be preserved, as they contain no information that’s that's not already printed on
the device’s device's serial number plate.</t>
      </section>
      <section anchor="other-factors-for-trustworthy-operation" title="Other numbered="true" toc="default">
        <name>Other Factors for Trustworthy Operation"> Operation</name>
        <t>In addition to the trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation.</t>

<t><list style="symbols">
  <t>Secure
        <ul spacing="normal">
          <li>Secure identity depends on mechanisms to prevent per-device secret keys from being compromised.  The TPM
provides this capability as a Root of Trust for Storage.</t>
  <t>Attestation Storage.</li>
          <li>Attestation depends on an unbroken chain of measurements, starting from the very first
measurement.  See <xref target="using-tpm"/> target="using-tpm" format="default"/> for background on TPM practices.</t>
  <t>That practices.</li>
          <li>That first measurement is made by code called the Root of Trust for Measurement, RTM, typically done by trusted
firmware stored in boot flash.  Mechanisms for maintaining the trustworthiness of the RTM are out of
scope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware
verification technique.    See <xref target="root-of-trust"/> target="root-of-trust" format="default"/> for background on roots Roots of trust.</t>
  <t>The Trust.</li>
          <li>The device owner SHOULD <bcp14>SHOULD</bcp14> provide some level of physical defense for the device.  If a TPM that has already been programmed
with an authentic DevID is stolen and is inserted into a counterfeit device, attestation of that counterfeit
device may become indistinguishable from an authentic device.</t>
</list></t> device.</li>
        </ul>
        <t>RIV also depends on reliable Reference Values, as expressed by the RIM <xref target="RIM"/>. target="RIM" format="default"/>.  The definition of
trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate
a set of reference measurements.  It should also be noted that, while RIV can provide a reliable indication that a known software package is in use by the device, device and that the package has not been tampered, tampered with, it is the device owner’s owner's responsibility to determine that it’s it's the correct package for the application.</t>
        <t>RIMs may be conveyed either out-of-band or in-band, in-band as part of the attestation
process (see <xref target="RIM-policy"/>).  But target="RIM-policy" format="default"/>).  However, for network devices, where software is usually shipped as a self-contained
package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner.</t>
        <t>The validity of RIV attestation results is also influenced by procedures used to create Reference Values:</t>

<t><list style="symbols">
  <t>While
        <ul spacing="normal">
          <li>While the RIM itself is signed, supply-chains SHOULD supply chains <bcp14>SHOULD</bcp14> be carefully scrutinized to ensure that the values are
not subject to unexpected manipulation prior to signing.  Insider-attacks  Insider attacks against code bases and build chains
are particularly hard to spot.</t>
  <t>Designers SHOULD spot.</li>
          <li>Designers <bcp14>SHOULD</bcp14> guard against hash collision attacks.  Reference Integrity Manifests  RIMs often give hashes for large objects
of indeterminate size; if size. If one of the measured objects can be replaced with an implant engineered to produce
the same hash, RIV will be unable to detect the substitution.  TPM1.2  TPM 1.2 only uses SHA-1 hashes only, hashes, which have been
shown to be susceptible to collision attack.  TPM2.0  TPM 2.0 will produce quotes with SHA-256, which so far has resisted
such attacks.  Consequently, RIV implementations SHOULD <bcp14>SHOULD</bcp14> use TPM2.0.</t>
</list></t> TPM 2.0.</li>
        </ul>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="conclusion" title="Conclusion"> numbered="true" toc="default">
      <name>Conclusion</name>
      <t>TCG technologies can play an important part in the implementation of Remote
Integrity Verification. RIV.
Standards for many of the components needed for
implementation of RIV already exist:</t>

<t><list style="symbols">
  <t>Platform
      <ul spacing="normal">
        <li>Platform identity can be based on IEEE 802.1AR Device Identity, DevID, coupled with
careful supply-chain management by the manufacturer.</t>
  <t>Complex manufacturer.</li>
        <li>Complex supply chains can be certified using TCG Platform Certificates <xref target="Platform-Certificates"/>.</t>
  <t>The target="PLATFORM-CERTS" format="default"/>.</li>
        <li>The TCG TAP mechanism coupled with <xref target="I-D.ietf-rats-yang-tpm-charra"/> target="RFC9684" format="default"/> can be used to retrieve attestation evidence.</t>
  <t>Reference evidence.</li>
        <li>Reference Values must be conveyed from the software authority (e.g.,
the manufacturer) in Reference Integrity Manifests, RIMs to the system in which verification will take place.  IETF and TCG
SWID and CoSWID work (<xref target="I-D.ietf-sacm-coswid"/>, target="RFC9393" format="default"/> <xref target="RIM"/>) target="RIM" format="default"/>) forms the basis for this function.</t>
</list></t> function.</li>
      </ul>
    </section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>The authors wish
 </middle>
  <back>

<displayreference target="I-D.ietf-rats-reference-interaction-models" to="RATS-INTERACTION-MODELS"/>
<displayreference target="I-D.richardson-rats-usecases" to="RATS-USECASES"/>
<displayreference target="I-D.birkholz-rats-tuda" to="RATS-TUDA"/>
<displayreference target="I-D.ietf-rats-network-device-subscription" to="RATS-NET-DEV-SUB"/>
<displayreference target="I-D.ietf-rats-eat" to="RATS-EAT"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>

<!-- [I-D.ietf-rats-yang-tpm-charra] companion document RFC 9684 -->

<reference anchor='RFC9684' target='https://www.rfc-editor.org/info/rfc9684'>
  <front>
    <title>A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)</title>
    <author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
      <organization />
    </author>
    <author initials='M' surname='Eckel' fullname='Michael Eckel'>
      <organization />
    </author>
    <author initials='S' surname='Bhandari' fullname='Shwetha Bhandari'>
      <organization />
    </author>
    <author initials='E' surname='Voit' fullname='Eric Voit'>
      <organization />
    </author>
    <author initials='B' surname='Sulzen' fullname='Bill Sulzen'>
      <organization />
    </author>
    <author initials='L' surname='Xia' fullname='Liang Xia'>
      <organization />
    </author>
    <author initials='T' surname='Laffey' fullname='Tom Laffey'>
      <organization />
    </author>
    <author initials='G' surname='Fedorkow' fullname='Guy Fedorkow'>
      <organization />
    </author>
    <date year='2024' month='October'/>
  </front>
  <seriesInfo name="RFC" value="9684"/>
  <seriesInfo name="DOI" value="10.17487/RFC9684"/>
</reference>

<!-- [rfced] Normative References. FYI, [I-D.ietf-sacm-coswid] has been published as RFC 9393. The reference entry and in-text citations have been updated accordingly. -->

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

<!-- [rfced] Normative References. FYI [I-D.ietf-rats-architecture] has been published as RFC 9334. The reference entry and in-text citations have been updated accordingly.  -->

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

        <reference anchor="IEEE-802-1AR" >
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2018" month="August"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1AR-2018"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
        </reference>

        <reference anchor="TAP" target="https://trustedcomputinggroup.org/wp-content/uploads/TNC_TAP_Information_Model_v1.00_r0.36-FINAL.pdf">
          <front>
            <title>TCG Trusted Attestation Protocol (TAP) Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2018" month="October"/>
          </front>
	  <refcontent>Version 1.0, Revision 0.36</refcontent>
        </reference>

        <reference anchor="CEL" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p41_pub.pdf">
          <front>
            <title>Canonical Event Log Format</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2022" month="February"/>
          </front>
	  <refcontent>Version 1.0, Revision 0.41</refcontent>
        </reference>

        <reference anchor="PC-CLIENT-BIOS-TPM-2.0" target="https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/">
          <front>
            <title>TCG PC Client Specific Platform Firmware Profile Specification</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2021" month="May"/>
          </front>
	  <refcontent>Family "2.0", Level 00, Version 1.05, Revision 23</refcontent>
        </reference>

        <reference anchor="PC-CLIENT-EFI-TPM-1.2" target="https://trustedcomputinggroup.org/resource/tcg-efi-platform-specification/">
          <front>
            <title>TCG EFI Platform Specification</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2014" month="January"/>
          </front>
	  <refcontent>For TPM Family 1.1 or 1.2, Version 1.22, Revision 15</refcontent>
        </reference>

        <reference anchor="RIM" target="https://trustedcomputinggroup.org/resource/tcg-reference-integrity-manifest-rim-information-model/">
          <front>
            <title>TCG Reference Integrity Manifest (RIM) Information Model</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2020" month="November"/>
          </front>
	  <refcontent>Version 1.01, Revision 0.16</refcontent>
        </reference>

        <reference anchor="PC-CLIENT-RIM" target="https://trustedcomputinggroup.org/resource/tcg-pc-client-reference-integrity-manifest-specification/">
          <front>
            <title>TCG PC Client Reference Integrity Manifest Specification</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2020" month="November"/>
          </front>
          <refcontent>Version 1.04</refcontent>
        </reference>

        <reference anchor="PLATFORM-DEVID-TPM-2.0" target="https://trustedcomputinggroup.org/resource/tpm-2-0-keys-for-device-identity-and-attestation/">
          <front>
            <title>TPM 2.0 Keys for Device Identity and Attestation</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2021" month="October"/>
          </front>
          <refcontent>Version 1.00, Revision 12</refcontent>
        </reference>

        <reference anchor="PLATFORM-ID-TPM-1.2" target="https://trustedcomputinggroup.org/resource/tpm-keys-for-platform-identity-for-tpm-1-2-2/">
          <front>
            <title>TCG Infrastructure WG TPM Keys for Platform Identity for TPM 1.2</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <refcontent>Specification Version 1.0, Revision 3</refcontent>
        </reference>

        <reference anchor="SWID" target="https://www.iso.org/standard/65666.html">
          <front>
            <title>Information technology - IT asset management - Part 2: Software identification tag</title>
            <author>
              <organization>ISO/IEC</organization>
            </author>
            <date year="2015" month="October"/>
          </front>
          <seriesInfo name="ISO/IEC" value="19770-2:2015"/>
        </reference>

<!-- [rfced] Normative References. FYI, we have updated the [IMA] reference to thank numerous reviewers match our style guide and also link to the most recent dated version. Please let us know if any changes are needed:

Original:
   [IMA]      dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn,
              "Integrity Measurement Architecture", June 2019,
              <https://sourceforge.net/p/linux-ima/wiki/Home/>.

Current:
   [IMA]      "Integrity Measurement Architecture (IMA) Wiki", October
              2018, <https://sourceforge.net/p/linux-ima/wiki/
              Home/?version=31>.
-->

        <reference anchor="IMA" target="https://sourceforge.net/p/linux-ima/wiki/Home/?version=31">
          <front>
            <title>Integrity Measurement Architecture (IMA) Wiki</title>
            <author/>
            <date year="2018" month="October"/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>

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

<!-- [rfced] Informative References. FYI, RFC 6125 has been obsoleted by RFC 9525.  We have replaced RFC 6125 with RFC 9525. Please let us know any objections.

Original:
      It should be noted that 802.1AR use of X.509 certificate fields is
      not identical to those descsribed in [RFC6125] for generous assistance, including William Bellingrath, Mark Baushke, Ned Smith,
Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, Bill Sulzen, Willard (Monty) Wiseman,
Kathleen Moriarty, Nancy Cam-Winget representation
      of application service identity.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and Shwetha Bhandari</t>

</section>
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

Current:
      It should be noted that the use of X.509 certificate fields as
      specified by IEEE Std 802.1AR is not identical to that described
      in [RFC9525] for representation of application service identity.

   [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
              RFC 9525, DOI 10.17487/RFC9525, November 2023,
              <https://www.rfc-editor.org/info/rfc9525>.
-->

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

<!-- [I-D.birkholz-rats-reference-interaction-model] replaced by [I-D.ietf-rats-reference-interaction-models] IESG state Expired -->

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

<!-- [I-D.richardson-rats-usecases] IESG state Expired -->

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

<!-- [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-network-device-subscription] Replaced by [I-D.ietf-rats-network-device-subscription] IESG state I-D Exists -->

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

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

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

        <reference anchor="TPM-1.2" target="https://trustedcomputinggroup.org/resource/tpm-main-specification/">
          <front>
            <title>TPM 1.2 Main Specification</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2011" month="March"/>
          </front>
          <refcontent>Level 2, Version 1.2, Revision 116</refcontent>
        </reference>

<!-- [rfced] Informative References. [TPM-2.0] has been updated to Revision 1.83. May we update [TPM-2.0] to use the latest revision number?

Original:
   [TPM2.0]   Trusted Computing Group, "Trusted Platform Module
              Library", Family "2.0", Level 00, Revision 01.59, November
              2019, <https://trustedcomputinggroup.org/resource/tpm-
              library-specification/>.

Perhaps:
   [TPM-2.0]  Trusted Computing Group, "Trusted Platform Module
              Library", Family "2.0", Level 00, Revision 01.83, March
              2024, <https://trustedcomputinggroup.org/resource/tpm-
              library-specification/>.
-->

        <reference anchor="TPM-2.0" target="https://trustedcomputinggroup.org/resource/tpm-library-specification/">
          <front>
            <title>Trusted Platform Module Library</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2019" month="November"/>
          </front>
          <refcontent>Family "2.0", Level 00, Revision 01.59</refcontent>
        </reference>

        <reference anchor="PLATFORM-CERTS" target="https://trustedcomputinggroup.org/resource/tcg-platform-attribute-credential-profile/">
          <front>
            <title>TCG Platform Attribute Credential Profile</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2018" month="January"/>
          </front>
          <refcontent>Specification Version 1.0, Revision 16</refcontent>
        </reference>

        <reference anchor="PROV-TPM-2.0" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf">
          <front>
            <title>TCG TPM v2.0 Provisioning Guidance</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2017" month="March"/>
          </front>
          <refcontent>Version 1.0, Revision 1.0</refcontent>
        </reference>

        <reference anchor="IEEE-802.1X">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks - Port-Based Network Access Control</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2020" month="February"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1X-2020"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/>
        </reference>

        <reference anchor="IEEE-802.1AE">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Security</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1AE-2018"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421" />
        </reference>

        <reference anchor="LLDP">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2016" month="March"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1AB-2016"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/>
        </reference>

        <reference anchor="TCG-RT" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf">
          <front>
            <title>TCG Roots of Trust Specification</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2018" month="July"/>
          </front>
          <refcontent>(Draft), Family "1.0", Level 00, Revision 0.20</refcontent>
        </reference>

        <reference anchor="SP800-193" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf">
          <front>
            <title>Platform Firmware Resiliency Guidelines</title>
            <author>
              <organization>NIST</organization>
            </author>
            <date year="2018" month="May"/>
          </front>
          <seriesInfo name="NIST SP" value="800-193"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-193"/>
        </reference>

        <reference anchor="SP800-155" target="https://csrc.nist.gov/files/pubs/sp/800/155/ipd/docs/draft-sp800-155_dec2011.pdf">
          <front>
            <title>BIOS Integrity Measurement Guidelines (Draft)</title>
            <author>
              <organization>NIST</organization>
            </author>
            <date year="2011" month="December"/>
          </front>
          <seriesInfo name="NIST SP" value="800-155 (Draft)"/>
        </reference>

        <reference anchor="NET-EQ" target="https://trustedcomputinggroup.org/resource/tcg-guidance-securing-network-equipment/">
          <front>
            <title>TCG Guidance for Securing Network Equipment Using TCG Technology</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2018" month="January"/>
          </front>
          <refcontent>Version 1.0, Revision 29</refcontent>
        </reference>

        <reference anchor="NIST-IR-8060" target="https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf">
          <front>
            <title>Guidelines for the Creation of Interoperable Software Identification (SWID) Tags</title>
            <author initials="D" surname="Waltermire" fullname="David Waltermire"></author>
            <author initials="B. A." surname="Cheikes" fullname="Brant A. Cheikes"></author>
            <author initials="L" surname="Feldman" fullname="Larry Feldman"></author>
            <author initials="G" surname="Witte" fullname="Greg Witte"></author>
            <date year="2016" month="April"/>
          </front>
          <seriesInfo name="NIST NISTIR" value="8060"/>
          <seriesInfo name="DOI" value="10.6028/NIST.IR.8060"/>
        </reference>

        <reference anchor="AIK-ENROLL" target="https://trustedcomputinggroup.org/resource/tcg-infrastructure-working-group-a-cmc-profile-for-aik-certificate-enrollment/">
          <front>
            <title>TCG Infrastructure Working Group A CMC Profile for AIK Certificate Enrollment</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2011" month="March"/>
          </front>
          <refcontent>Version 1.0, Revision 7</refcontent>
        </reference>

        <reference anchor="SWID-GEN" target="https://github.com/Labs64/swid-maven-plugin">
          <front>
            <title>SoftWare IDentification (SWID) Tags Generator (Maven Plugin)</title>
            <author>
              <organization>Labs64</organization>
            </author>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="appendix" title="Appendix"> numbered="true" toc="default">
      <name>Supporting Materials</name>
      <section anchor="using-tpm" title="Using numbered="true" toc="default">
        <name>Using a TPM for Attestation"> Attestation</name>
        <t>The Trusted Platform Module TPM and surrounding ecosystem provide three interlocking capabilities to enable secure collection
of evidence from a remote device, Platform Configuration Registers (PCRs), device: PCRs, a Quote mechanism, and a standardized Event Log.</t>
        <t>Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large
enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can
be used, depending on TPM version).  PCRs can’t can't be accessed directly from outside the chip, but the TPM
interface provides a way to “extend” "extend" a new security measurement hash into any PCR, a process by which the existing value
in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR.  The result
is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset.</t>
        <t>Every time a PCR is extended, an entry should be added to the corresponding Event Log.  Logs contain the security
measurement hash plus informative fields offering hints as to which event generated the security measurement.
The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident – any tamper-evident:  Any
verification process can read the security measurement hash from the log events, compute the composite value value,
and compare that to what ended up is in the PCR.   If there’s there's no discrepancy, the logs do provide an accurate
view of what was placed into the PCR.</t>
        <t>Note that the composite hash-of-hashes recorded in PCRs is order-dependent, resulting in different PCR values for different
ordering of the same set of events (e.g. (e.g., Event A followed by Event B yields a different PCR value than B followed by A).
For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values.  However, operating system code is usually
non-deterministic,
nondeterministic, meaning that there may never be a single “known good” "known good" PCR value.  In this case, the Verifier may have
to verify that the log is correct, and then analyze each item in the log to determine if it represents an authorized event.</t>
        <t>In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted
device code (called the Root of Trust for Measurement, RTM).  That first measurement should cover the segment of
code that is run immediately after the RTM, which then measures the next code segment before running it, and so on,
forming an unbroken chain of trust.  See <xref target="TCGRoT"/> target="TCG-RT" format="default"/> for more on Mutable vs vs. Immutable roots Roots of trust.</t> Trust.</t>
        <t>The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them,
along with the Verifier’s Verifier's nonce, into a TPM-specific data structure signed by an Attestation private key, known
only to the TPM.</t>

<t>As noted above in <xref target="security-cons"/> Security Considerations, it’s
        <t>It's important to note that the Quote data structure is signed inside the TPM. TPM (see <xref target="security-cons" format="default"/>, Security Considerations).  The trust model is preserved by retrieving the Quote in a way that does not invalidate the signature,
as specified in <xref target="I-D.ietf-rats-yang-tpm-charra"/>. target="RFC9684" format="default"/>.  The structure of the command and response for a quote, including its signature, as generated by the TPM, can be seen in <xref target="TPM1.2"></xref> Part 3, Section 16.5, and of <xref target="TPM2.0"></xref> target="TPM-1.2" format="default"/> and Section 18.4.2.</t> 18.4.2 of <xref target="TPM-2.0" format="default"/>.</t>
        <t>The Verifier uses the Quote and Log together.  The Quote contains the composite hash of the complete sequence
of security measurement hashes, signed by the TPM’s TPM's private Attestation Key. AK.  The Log contains a record of each
measurement extended into the TPM’s TPM's PCRs.  By computing the composite hash of all the measurements, the Verifier
can verify the integrity of the Event Log, even though the Event Log itself is not signed.  Each hash in the validated
Event Log can then be compared to corresponding expected values in the set of Reference Values to
validate overall system integrity.</t>
        <t>A summary of information exchanged in obtaining quotes from TPM1.2 TPM 1.2 and TPM2.0 TPM 2.0 can be found in <xref target="TAP"/>, target="TAP" format="default"/>, Section 4.
Detailed information about PCRs and Quote data structures can be found in <xref target="TPM1.2"/>, target="TPM-1.2" format="default"/>, <xref target="TPM2.0"/>. target="TPM-2.0" format="default"/>.  Recommended log
formats include <xref target="PC-Client-BIOS-TPM-2.0"/>, target="PC-CLIENT-BIOS-TPM-2.0" format="default"/>, and <xref target="Canonical-Event-Log"/>.</t> target="CEL" format="default"/>.</t>
      </section>
      <section anchor="root-of-trust" title="Root numbered="true" toc="default">
        <name>Root of Trust for Measurement"> Measurement (RTM)</name>
        <t>The measurements needed for attestation require that the device being attested
is equipped with a Root of Trust for Measurement, an RTM, that is, some trustworthy
mechanism that can compute the first measurement in the chain of trust required
to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e.,
the TPM PCRs) to record the results, and a Root of Trust
for Reporting to report the results.</t>
        <t>While there are many complex aspects of Roots of Trust ( <xref target="TCGRoT"/>, (<xref target="TCG-RT" format="default"/> <xref target="SP800-155"/>, target="SP800-155" format="default"/> <xref target="SP800-193"/>), target="SP800-193" format="default"/>), two aspects that

are important in the case of attestation are:</t>

<t><list style="symbols">
  <t>The
        <ul spacing="normal">
          <li>The first measurement computed by the Root of Trust for Measurement, RTM and stored
in the TPM’s TPM's Root of Trust for Storage, Storage must be assumed to be correct.</t>
  <t>There correct.</li>
          <li>There must not be a way to reset the Root of Trust for Storage without re-entering
the Root of Trust for Measurement code.</t>
</list></t> RTM code.</li>
        </ul>
        <t>The first measurement must be computed by code that is implicitly trusted; if that
first measurement can be subverted, none of the remaining measurements can
be trusted. (See <xref target="SP800-155"/>)</t>

<t>It’s target="SP800-155" format="default"/>.)</t>
        <t>It's important to note that the trustworthiness of the RTM code cannot be assured by
the TPM or TPM supplier – -- code or procedures external to the TPM must guarantee the
security of the RTM.</t>
      </section>
      <section anchor="layering-model-for-network-equipment-attester-and-verifier" title="Layering numbered="true" toc="default">
        <name>Layering Model for Network Equipment Attester and Verifier"> Verifier</name>
        <t>Retrieval of identity and attestation state uses one protocol stack, while
retrieval of Reference Values uses a different set of protocols.  Figure
5
<xref target="RIV-Protocol-Stacks" format="default"/> shows the components involved.</t>
<!-- [rfced] Section A.3. In Figure 5, is the following a label? Should its contents be moved to the figure caption?

Original:

********************************************************************
*         IETF Attestation Reference Interaction Diagram           *
********************************************************************

-->
<!-- [rfced] Section A.3. In Figure 5, what does "PTS2.0" mean?

Original:

    .........................          .........................
    . Reference Integrity   .          .  TAP (PTS2.0) Info    .
    .      Manifest         .          . Model and Canonical   .
    .                       .          .     Log Format        .
    .........................          .........................

-->
        <figure title="RIV anchor="RIV-Protocol-Stacks">
          <name>RIV Protocol Stacks" anchor="RIV-Protocol-Stacks"><artwork align="left"><![CDATA[ Stacks</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
+-----------------------+              +-------------------------+
|                       |              |                         |
|       Attester        |<-------------|        Verifier         |
|       (Device)        |------------->|   (Management Station)  |
|                       |      |       |                         |
+-----------------------+      |       +-------------------------+
                               |
           -------------------- --------------------
           |                                        |
-------------------------------    ---------------------------------
|Reference
|      Reference Values       |    |          Attestation          |
-------------------------------    ---------------------------------

********************************************************************
*         IETF Attestation Reference Interaction Diagram           *
********************************************************************

    .........................          .........................
    .  Reference Integrity  .          .   TAP (PTS2.0) Info   .
    .       Manifest        .          .  Model and Canonical  .
    .                       .          .      Log Format       .
    .........................          .........................

    *************************          *************************
    *    YANG SWID Module   *          *    YANG Attestation   *
    * I-D.ietf-sacm-coswid       RFC9393         *          *        Module         *
    *                       *          * I-D.ietf-rats-        RFC9684        *
    *                       *          * yang-tpm-charra                       *
    *************************          *************************

    *************************          *************************
    * XML, JSON, CBOR (etc) CBOR, etc. *          * XML, JSON, CBOR (etc) CBOR, etc. *
    *************************          *************************

    *************************          *************************
    *   RESTCONF/NETCONF    *          *   RESTCONF/NETCONF    *
    *************************          *************************

    *************************          *************************
    *       TLS, SSH        *          *       TLS, SSH        *
    *************************          *************************

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>IETF documents are captured in boxes surrounded by asterisks. TCG documents
are shown in boxes surrounded by dots.</t>
      </section>
      <section anchor="implementation-notes" title="Implementation Notes"> numbered="true" toc="default">
        <name>Implementation Notes</name>
        <t><xref target="Component-Status"/> target="Component-Status" format="default"/> summarizes many of the actions needed to complete an Attestation
system, with links to relevant documents.  While documents are controlled
by several standards organizations, the implied actions required for
implementation are all the responsibility of the manufacturer of the device,
unless otherwise noted.</t>
        <t>As noted, SWID tags can be generated many ways, but one possible tool is <xref target="SWID-Gen"></xref></t>

<figure title="Component Status" anchor="Component-Status"><artwork align="left"><![CDATA[
+------------------------------------------------------------------+
|             Component                           |  Controlling   |
|                                                 | Specification  |
--------------------------------------------------------------------
| Make target="SWID-GEN" format="default"/>.</t>

<!-- [rfced] Appendix A.4, Table 2.

a) Please review the format of Table 2, which has been converted to an RFCXML table. In particular, please review the use of rowspan in the second column. Are the contents in the second column supposed to align with bullet points in the first column?

b) We added citation tags to the contents of Table 2. Please review and let us know if any changes are necessary.

c) FYI, there is an issue with xml2rfc that is cutting off text in Table 2 in the txt output. We have asked the Tools Team to fix this issue <https://github.com/ietf-tools/xml2rfc/issues/1155>
-->
<table anchor="Component-Status">
  <name>Component Status</name>
  <thead>
    <tr>
      <th>Component</th>
      <th>Controlling Specification</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <t>Make a Secure execution environment             |   TCG RoT      |
|   o Attestation environment:</t>
        <ul>
          <li>Attestation depends on a secure root of     |   UEFI.org     |
|     trust for measurement RTM outside the TPM, as   |                |
| well as roots Roots for storage Storage and reporting     |                |
| Reporting inside the TPM.                             |                |
|   o  Refer TPM.</li>
          <li>Refer to TCG Root "TCG Roots of Trust for Measurement.|                |
|   o  NIST SP 800-193 Specification" <xref target="TCG-RT" format="default"/>.</li>
          <li><xref target="SP800-193" format="default"/> also provides guidelines   |                |
| on Roots of Trust                          |                |
--------------------------------------------------------------------
| Provision Trust.</li>
        </ul>
      </td>
      <td>
        <t><xref target="TCG-RT" format="default"/></t>
        <t><eref target="www.uefi.org" brackets="angle"/></t>
      </td>
    </tr>
    <tr>
      <td>Provision the TPM as described in       |[Platform-DevID-TPM-2.0]|
|   TCG documents.                                | the TCG Platform   |
|                                                 |   Certificate  |
--------------------------------------------------------------------
| Put documents.</td>
      <td>
        <t><xref target="PLATFORM-DEVID-TPM-2.0" format="default"/></t>
        <t><xref target="PLATFORM-CERTS" format="default"/></t>
      </td>
    </tr>
    <tr>
      <td rowspan="2" colspan="">
        <t>Put a DevID or Platform Cert Certificate in the TPM         | TCG TPM DevID  |
|    o Install TPM:</t>
        <ul>
          <li>Install an Initial Attestation Key IAK at the  | TCG Platform   |
| same time so that Attestation can work out |   Certificate  |
| of the box                                 |-----------------
|    o Equipment box.</li>
          <li>Equipment suppliers and owners may want to | IEEE 802.1AR   |
| implement Local Device ID LDevID as well as       |                |
|      Initial Device ID                          |                |
--------------------------------------------------------------------
| Connect IDevID.</li>
        </ul>
      </td>
      <td>
        <t><xref target="PLATFORM-DEVID-TPM-2.0" format="default"/></t>
        <t><xref target="PLATFORM-CERTS" format="default"/></t>
      </td>
    </tr>
    <tr>
      <td><xref target="IEEE-802-1AR" format="default"/></td>
    </tr>
    <tr>
      <td>
        <t>Connect the TPM to the TLS stack                | Vendor TLS     |
|    o  Use stack:</t>
        <ul>
          <li>Use the DevID in the TPM to authenticate  | stack (This    |
| TAP connections, identifying the device   | device</li>
        </ul>
      </td>
      <td>Vendor TLS stack (This action is      |
|                                                 | configuring TLS|
|                                               | configures TLS to use the DevID |
|                                               | as its client    |
|                                               | certificate)     |
--------------------------------------------------------------------
| Make certificate)</td>
    </tr>
    <tr>
      <td>
        <t>Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID    |
|    o  Add objects:</t>
        <ul>
          <li>Add reference measurements into SWID tags | ISO/IEC 19770-2|
|    o  Manufacturer tags.</li>
          <li>Manufacturer should sign the SWID tags    | NIST IR 8060   |
|    o  The tags.</li>
          <li>The TCG RIM-IM <xref target="RIM" format="default"/> identifies further         |                |
| procedures to create signed RIM           |                |
| documents that provide the necessary      |                |
| reference information                     |                |
--------------------------------------------------------------------
|  Package information.</li>
        </ul>
      </td>
      <td>
        <t><xref target="RFC9393" format="default"/></t>
        <t><xref target="SWID" format="default"/></t>
        <t><xref target="NIST-IR-8060" format="default"/></t>
      </td>
    </tr>
    <tr>
      <td rowspan="2">
        <t>Package the SWID tags with a vendor software   | Retrieve tags  |
|  release                                        | with           |
|    o  A release:</t>
        <ul>
          <li>A tag-generator plugin such          | I-D.ietf-sacm-coswid|
| as [SWID-Gen] <xref target="SWID-GEN" format="default"/>  can be used                   |----------------|
|                                                 | TCG PC Client  |
|                                                 | RIM            |
--------------------------------------------------------------------
|  Use used.</li>
        </ul>
      </td>
      <td>Retrieve tags with <xref target="RFC9393" format="default"/>.</td>
    </tr>
    <tr>
      <td><xref target="PC-CLIENT-RIM" format="default"/></td>
    </tr>
    <tr>
      <td>Use PC Client measurement definitions          | TCG PC Client  |
| to define the use of PCRs                      | BIOS           |
| (although Windows OS is rare on Networking    |                |
| Equipment, UEFI BIOS is not)                   |                |
--------------------------------------------------------------------
|  Use not).</td>
      <td><xref target="PC-CLIENT-BIOS-TPM-2.0" format="default"/></td>
    </tr>
    <tr>
      <td>
        <t>Use TAP to retrieve measurements               |                |
|    o  Map measurements:</t>
        <ul>
          <li><t>Map to YANG                               | YANG Module for|
|  Use YANG.</t></li>
        </ul>
        <t>Use Canonical Log Format                       |   Basic        |
|                                                 |   Attestation  |
|                                                 | TCG Canonical  |
|                                                 |   Log Format   |
--------------------------------------------------------------------
| Format.</t>
      </td>
      <td>
        <t><xref target="RFC9684" format="default"/></t>
        <t><xref target="CEL" format="default"/></t>
      </td>
    </tr>
    <tr>
<!-- [rfced] Appendix A.4. Table 2. Please provide a reference for the following and let us know if it should be an informative or normative reference:

Original:
   Posture Collection Server (as described in IETF |                |
| SACMs ECP)
   should request the                  |                |
| attestation and analyze the result             |                |
| result.
-->
      <td>
        <t>A Posture Collection Server (as described in IETF SACMs ECP) should request the attestation and analyze the result. The Management application might be broken down |                |
| to several more components:                    |                |
|    o  A components:</t>
        <ul>
          <li>A Posture Manager Server                  |                |
|       which that collects reports and stores them in |                |
| a database                                |                |
|    o  One database.</li>
          <li>One or more Analyzers that can look at the|                |
| the results and figure out what it means.     |                |
--------------------------------------------------------------------
]]></artwork></figure> means.</li>
        </ul>
      </td>
      <td>
      </td>
    </tr>
  </tbody>
</table>
      </section>
    </section>

  </middle>

  <back>

    <references title='Normative References'>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used

    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors wish to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices thank numerous reviewers for the Internet Community, and requests discussion and suggestions generous assistance, including <contact fullname="William Bellingrath"/>, <contact fullname="Mark Baushke"/>, <contact fullname="Ned Smith"/>,
<contact fullname="Henk Birkholz"/>, <contact fullname="Tom Laffey"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Wei Pan"/>, <contact fullname="Michael Eckel"/>, <contact fullname="Thomas Hardjono"/>, <contact fullname="Bill Sulzen"/>, <contact fullname="Willard (Monty) Wiseman"/>,
<contact fullname="Kathleen Moriarty"/>, <contact fullname="Nancy Cam-Winget"/>, and <contact fullname="Shwetha Bhandari"/>.</t>
    </section>
  </back>
<!-- [rfced] Terminology

a) During AUTH48 for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<date month='August' year='2018'/>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over RFC 9393, the Internet in a way authors decided that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>

<reference anchor='RFC4253' target='https://www.rfc-editor.org/info/rfc4253'>
<front>
<title>The Secure Shell (SSH) Transport Layer Protocol</title>
<author fullname='T. Ylonen' initials='T.' surname='Ylonen'><organization/></author>
<author fullname='C. Lonvick' initials='C.' role='editor' surname='Lonvick'><organization/></author>
<date month='January' year='2006'/>
<abstract><t>The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</t><t>This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP.  The protocol can phrase "Reference Integrity Manifests (RIMs)" should be used as a basis for a number of secure network services.  It provides strong encryption, server authentication, and not "reference integrity protection.  It may also provide compression.</t><t>Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.</t><t>This document also describes the Diffie-Hellman key exchange method and the minimal set measurements (RIM)" or "reference measurements (RIMs)". We note one instance of algorithms that are needed to implement the SSH transport layer protocol.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4253'/>
<seriesInfo name='DOI' value='10.17487/RFC4253'/>
</reference>

<reference anchor='RFC6241' target='https://www.rfc-editor.org/info/rfc6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname='R. Enns' initials='R.' role='editor' surname='Enns'><organization/></author>
<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'><organization/></author>
<author fullname='J. Schoenwaelder' initials='J.' role='editor' surname='Schoenwaelder'><organization/></author>
<author fullname='A. Bierman' initials='A.' role='editor' surname='Bierman'><organization/></author>
<date month='June' year='2011'/>
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, "Reference Integrity Measurements" and delete the configuration five instances of network devices.  It uses an Extensible Markup Language (XML)-based data encoding "reference measurements". Please let us know if we should update these.

b) We have added expansions for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6241'/>
<seriesInfo name='DOI' value='10.17487/RFC6241'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity following abbreviations per Section 3.6 of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used 7322 ("RFC Style Guide"). Please review each expansion in protocol  specifications.  This the document aims carefully to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

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

<reference anchor='I-D.ietf-rats-yang-tpm-charra'>
   <front>
      <title>A YANG Data Model for ensure correctness.

   CHARRA - Challenge-Response-based Remote Attestation Procedures using TPMs</title>
      <author fullname='Henk Birkholz'>
	 <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Michael Eckel'>
	 <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Shwetha Bhandari'>
	 <organization>ThoughtSpot</organization>
      </author>
      <author fullname='Eric Voit'>
	 <organization>Cisco Systems</organization>
      </author>
      <author fullname='Bill Sulzen'>
	 <organization>Cisco Systems</organization>
      </author>
      <author fullname='Liang Xia (Frank)'>
	 <organization>Huawei Technologies</organization>
      </author>
      <author fullname='Tom Laffey'>
	 <organization>Hewlett Packard Enterprise</organization>
      </author>
      <author fullname='Guy C. Fedorkow'>
	 <organization>Juniper Networks</organization>
      </author>
      <date day='20' month='March' year='2022'/>
      <abstract>
	 <t>   This document defines YANG RPCs and a few configuration nodes
   required to retrieve attestation evidence about integrity
   measurements from a device, following the operational context defined
   in TPM-based Network Device Remote Integrity Verification.
   Complementary measurement logs are also provided by the YANG RPCs,
   originating from one or more roots of trust for measurement (RTMs).
   The module defined requires at least one TPM 1.2 or TPM 2.0 as well
   as a corresponding TPM Software Stack (TSS), or equivalent hardware
   implementations that include the protected capabilities as provided
   by TPMs as well as a corresponding software stack, included in the
   device components of the composite device the YANG server is running
   on.

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

<reference anchor='I-D.ietf-sacm-coswid'>
   <front>
      <title>Concise Software Identification Tags</title>
      <author fullname='Henk Birkholz'>
	 <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Jessica Fitzgerald-McKay'>
	 <organization>National Security Agency</organization>
      </author>
      <author fullname='Charles Schmidt'>
	 <organization>The MITRE Corporation</organization>
      </author>
      <author fullname='David Waltermire'>
	 <organization>National Institute of Standards and Technology</organization>
      </author>
      <date day='7' month='March' year='2022'/>
      <abstract>
	 <t>   ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
   extensible XML-based structure to identify and describe individual
   software components, patches, and installation bundles.  SWID tag
   representations can be too large for devices with network and storage
   constraints.  This document defines a concise representation of SWID
   tags:
   CoSWID - Concise SWID (CoSWID) tags.  CoSWID supports a similar set
   EAP - Extensible Authentication Protocol
   IoT - Internet of
   semantics and features as Things
   LLDP - Link Layer Discovery Protocol
   NETCONF - Network Configuration Protocol
   PCI - Peripheral Component Interconnect
   SWID tags, as well as new semantics that
   allow CoSWIDs to describe additional types of information, all in a
   more memory efficient format.

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

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

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

<reference anchor="IEEE-802-1AR" >
  <front>
    <title>802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks Software Identification
   SZTP - Secure Device Identity, IEEE Computer Society</title>
    <author initials="M." surname="Seaman">
      <organization>IEEE Computer Society</organization>
    </author>
    <date year="2018" month="August"/>
  </front>
</reference>
<reference anchor="TAP" target="https://trustedcomputinggroup.org/resource/tcg-tap-information-model/">
  <front>
    <title>TCG Zero Touch Provisioning
   TAP IM - Trusted Attestation Protocol (TAP) Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0, Version 1.0, Revision 0.36</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2018" month="October"/>
  </front>
</reference>
<reference anchor="Canonical-Event-Log" target="https://trustedcomputinggroup.org/resource/canonical-event-log-format/">
  <front>
    <title>Canonical Event Log Format Version 1.0 Revision .41, February 25, 2022</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2020" month="December"/>
  </front>
</reference>
<reference anchor="PC-Client-BIOS-TPM-2.0" target="https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/">
  <front>
    <title>PC Client Specific Platform
   UEFI - Unified Extensible Firmware Profile Specification Family "2.0", Level 00 Revision 1.05 Revision 23, May 7, 2021</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2021" month="May"/>
  </front>
</reference>
<reference anchor="PC-Client-EFI-TPM-1.2" target="https://trustedcomputinggroup.org/resource/tcg-efi-platform-specification/">
  <front>
    <title>TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Specification Version 1.22, Revision 15</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2014" month="January"/>
  </front>
</reference>
<reference anchor="RIM" target="https://trustedcomputinggroup.org/resource/tcg-reference-integrity-manifest-rim-information-model/">
  <front>
    <title>TCG Reference Integrity Manifest (RIM) Information Model, v1.0, Revision 0.16, Nov 12, 2020</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2019" month="June"/>
  </front>
</reference>
<reference anchor="PC-Client-RIM" target="https://trustedcomputinggroup.org/resource/tcg-pc-client-reference-integrity-manifest-specification/">
  <front>
    <title>TCG PC Client Reference Integrity Manifest Specification, v1.04, Nov 4, 2020</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2019" month="December"/>
  </front>
</reference>
<reference anchor="Platform-DevID-TPM-2.0" target="https://trustedcomputinggroup.org/resource/tpm-2-0-keys-for-device-identity-and-attestation/">
  <front>
    <title>TPM 2.0 Keys for Device Identity and Attestation, Specification Version 1.0, Revision 2</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2020" month="September"/>
  </front>
</reference>
<reference anchor="Platform-ID-TPM-1.2" target="https://trustedcomputinggroup.org/resource/tpm-keys-for-platform-identity-for-tpm-1-2-2/">
  <front>
    <title>TPM Keys for Platform Identity for TPM 1.2, Specification Version 1.0, Revision 3</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2015" month="August"/>
  </front>
</reference>
<reference anchor="SWID" target="https://www.iso.org/standard/65666.html">
  <front>
    <title>Information Technology Software Asset Management Part 2: Software Identification Tag, ISO/IEC 19770-2</title>
    <author >
      <organization>The International Organization for Standardization/International Electrotechnical Commission</organization>
    </author>
    <date year="2015" month="October"/>
  </front>
</reference>
<reference anchor="IMA" target="https://sourceforge.net/p/linux-ima/wiki/Home/">
  <front>
    <title>Integrity Measurement Architecture</title>
    <author surname="dsafford">
      <organization>dsafford</organization>
    </author>
    <author surname="kds_etu">
      <organization>kds_etu</organization>
    </author>
    <author surname="mzohar">
      <organization>mzohar</organization>
    </author>
    <author surname="reinersailer">
      <organization>reinersailer</organization>
    </author>
    <author surname="serge_hallyn">
      <organization>serge_hallyn</organization>
    </author>
    <date year="2019" month="June"/>
  </front>
</reference>

    </references>

    <references title='Informative References'>

<reference anchor='RFC6813' target='https://www.rfc-editor.org/info/rfc6813'>
<front>
<title>The Network Endpoint Assessment (NEA) Asokan Attack Analysis</title>
<author fullname='J. Salowey' initials='J.' surname='Salowey'><organization/></author>
<author fullname='S. Hanna' initials='S.' surname='Hanna'><organization/></author>
<date month='December' year='2012'/>
<abstract><t>The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This document describes Interface

c) FYI, we have used abbreviations after the attack and countermeasures that may be mounted.  This document is not an Internet Standards Track specification; it is published abbreviated forms were introduced for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6813'/>
<seriesInfo name='DOI' value='10.17487/RFC6813'/>
</reference>

<reference anchor='RFC3748' target='https://www.rfc-editor.org/info/rfc3748'>
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author fullname='B. Aboba' initials='B.' surname='Aboba'><organization/></author>
<author fullname='L. Blunk' initials='L.' surname='Blunk'><organization/></author>
<author fullname='J. Vollbrecht' initials='J.' surname='Vollbrecht'><organization/></author>
<author fullname='J. Carlson' initials='J.' surname='Carlson'><organization/></author>
<author fullname='H. Levkowetz' initials='H.' role='editor' surname='Levkowetz'><organization/></author>
<date month='June' year='2004'/>
<abstract><t>This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods.  EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.  Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.  This document obsoletes RFC 2284.  A summary of following terms per the changes between this document and RFC 2284 is available in Appendix A.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3748'/>
<seriesInfo name='DOI' value='10.17487/RFC3748'/>
</reference>

<reference anchor='RFC6125' target='https://www.rfc-editor.org/info/rfc6125'>
<front>
<title>Representation and Verification online portion of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
<author fullname='P. Saint-Andre' initials='P.' surname='Saint-Andre'><organization/></author>
<author fullname='J. Hodges' initials='J.' surname='Hodges'><organization/></author>
<date month='March' year='2011'/>
<abstract><t>Many application technologies enable secure communication between two entities by means of Internet Public Style Guide <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>:

   Attestation Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6125'/>
<seriesInfo name='DOI' value='10.17487/RFC6125'/>
</reference>

<reference anchor='RFC8995' target='https://www.rfc-editor.org/info/rfc8995'>
<front>
<title>Bootstrapping Remote Secure / AK
   Device Identity / DevID
   Initial DevID / Initial Device Identity / IDevID
   Initial Attestation Key Infrastructure (BRSKI)</title>
<author fullname='M. Pritikin' initials='M.' surname='Pritikin'><organization/></author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organization/></author>
<author fullname='T. Eckert' initials='T.' surname='Eckert'><organization/></author>
<author fullname='M. Behringer' initials='M.' surname='Behringer'><organization/></author>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></author>
<date month='May' year='2021'/>
<abstract><t>This document specifies automated bootstrapping of an Autonomic Control Plane.  To do this, a Secure / IAK
   Local Attestation Key Infrastructure is bootstrapped.  This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline.  We call this process the Bootstrapping / LAK
   Local Device ID / Local DevID / LDevID
   Platform Configuration Register / PCR
   Reference Integrity Manifests / RIMs
   Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity Integrity Verification / RIV
   Root of the new key infrastructure is successfully deployed to the device.  The established secure connection can be used to deploy a locally issued certificate to the device as well.</t></abstract>
</front>
<seriesInfo name='RFC' value='8995'/>
<seriesInfo name='DOI' value='10.17487/RFC8995'/>
</reference>

<reference anchor='RFC7950' target='https://www.rfc-editor.org/info/rfc7950'>
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'><organization/></author>
<date month='August' year='2016'/>
<abstract><t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications Trust for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in Measurement / RTM
   Trusted Platform Modules / TPMs

-->
<!-- [rfced] Please review the original specification.  There are a small number "Inclusive Language" portion of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t></abstract>
</front>
<seriesInfo name='RFC' value='7950'/>
<seriesInfo name='DOI' value='10.17487/RFC7950'/>
</reference>

<reference anchor='RFC8572' target='https://www.rfc-editor.org/info/rfc8572'>
<front>
<title>Secure Zero Touch Provisioning (SZTP)</title>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></author>
<author fullname='I. Farrer' initials='I.' surname='Farrer'><organization/></author>
<author fullname='M. Abrahamsson' initials='M.' surname='Abrahamsson'><organization/></author>
<date month='April' year='2019'/>
<abstract><t>This document presents a technique to securely provision a networking device when it is booting in a factory-default state.  Variations in the solution enable it to be used on both public online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and private networks.  The provisioning steps let us know if any changes are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs.  The updated device is subsequently able to establish secure connections with other systems.  For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.</t></abstract>
</front>
<seriesInfo name='RFC' value='8572'/>
<seriesInfo name='DOI' value='10.17487/RFC8572'/>
</reference>

<reference anchor='I-D.birkholz-rats-reference-interaction-model'>
   <front>
      <title>Reference Interaction Models for Remote Attestation Procedures</title>
      <author fullname='Henk Birkholz'>
	 <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Michael Eckel'>
	 <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Christopher Newton'>
	 <organization>University of Surrey</organization>
      </author>
      <author fullname='Liqun Chen'>
	 <organization>University needed.  Updates of Surrey</organization>
      </author>
      <date day='7' month='July' year='2020'/>
      <abstract>
	 <t>   This document describes interaction models for remote attestation
   procedures (RATS).  Three conveying mechanisms - Challenge/Response,
   Uni-Directional, and Streaming Remote Attestation - are illustrated
   and defined.  Analogously, a general overview about the information
   elements this nature typically used by corresponding conveyance protocols are
   highlighted.  Privacy preserving conveyance of Evidence via Direct
   Anonymous Attestation is elaborated on for each interaction model,
   individually.

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

<reference anchor='I-D.richardson-rats-usecases'>
   <front>
      <title>Use cases for Remote Attestation common encodings</title>
      <author fullname='Michael Richardson'>
	 <organization>Sandelman Software Works</organization>
      </author>
      <author fullname='Carl Wallace'>
	 <organization>Red Hound Software</organization>
      </author>
      <author fullname='Wei Pan'>
	 <organization>Huawei Technologies</organization>
      </author>
      <date day='2' month='November' year='2020'/>
      <abstract>
	 <t>   This document details mechanisms created for performing Remote
   Attestation that have been used in a number of industries.  The
   document initially focuses on existing industry verticals, mapping
   terminology used result in those specifications to the more abstract
   terminology used by the IETF RATS Working Group.

   The document aspires to describe possible future use cases that would
   be enabled by common formats.

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

<reference anchor='I-D.birkholz-rats-tuda'>
   <front>
      <title>Time-Based Uni-Directional Attestation</title>
      <author fullname='Andreas Fuchs'>
	 <organization>Fraunhofer Institute for Secure Information Technology</organization>
      </author>
      <author fullname='Henk Birkholz'>
	 <organization>Fraunhofer Institute for Secure Information Technology</organization>
      </author>
      <author fullname='Ira E McDonald'>
	 <organization>High North Inc</organization>
      </author>
      <author fullname='Carsten Bormann'>
	 <organization>Universität Bremen TZI</organization>
      </author>
      <date day='12' month='January' 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 precise language, 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 the RATS entities.  RATS require an Attesting Environment helpful for readers.

Note that generates believable Evidence.  While a TPM is used as the
   corresponding root of trust in this specification, our script did not flag any other type of
   root of trust can be used with TUDA.

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

<reference anchor='I-D.birkholz-rats-network-device-subscription'>
   <front>
      <title>Attestation Event Stream Subscription</title>
      <author fullname='Henk Birkholz'>
	 <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Eric Voit'>
	 <organization>Cisco Systems, Inc.</organization>
      </author>
      <author fullname='Wei Pan'>
	 <organization>Huawei Technologies</organization>
      </author>
      <date day='17' month='August' year='2021'/>
      <abstract>
	 <t>   This memo defines how to subscribe to YANG Event Streams for Remote
   Attestation Procedures (RATS).  In RATS, Conceptional Messages, are
   defined.  Analogously, the YANG module defined words in particular, but this memo augments
   the YANG module for TPM-based Challenge-Response based Remote
   Attestation (CHARRA) to allow for subscription to remote attestation
   Evidence.  Additionally, this memo provides the methods and means to
   define additional Event Streams for other Conceptual Message should still be reviewed as
   illustrated in the RATS Architecture, e.g.  Attestation Results,
   Endorsements, or Event Logs.

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

<reference anchor='I-D.ietf-rats-eat'>
   <front>
      <title>The Entity Attestation Token (EAT)</title>
      <author fullname='Laurence Lundblade'>
	 <organization>Security Theory LLC</organization>
      </author>
      <author fullname='Giridhar Mandyam'>
	 <organization>Qualcomm Technologies Inc.</organization>
      </author>
      <author fullname='Jeremy O&#39;Donoghue'>
	 <organization>Qualcomm Technologies Inc.</organization>
      </author>
      <date day='24' month='February' year='2022'/>
      <abstract>
	 <t>   An Entity Attestation Token (EAT) provides an attested claims set
   that describes state and characteristics of an entity, a device like
   a phone, IoT device, network equipment or such.  This claims set is
   used by a relying party, server or service to determine how much it
   wishes to trust the entity.

   An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims.  To a large degree, all this document
   does is extend CWT and JWT.

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

<reference anchor="TPM1.2" target="https://trustedcomputinggroup.org/resource/tpm-main-specification/">
  <front>
    <title>TPM Main Specification Level 2 Version 1.2, Revision 116</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2011" month="March"/>
  </front>
</reference>
<reference anchor="TPM2.0" target="https://trustedcomputinggroup.org/resource/tpm-library-specification/">
  <front>
    <title>Trusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.59</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2019" month="November"/>
  </front>
</reference>
<reference anchor="Platform-Certificates" target="https://trustedcomputinggroup.org/resource/tcg-platform-attribute-credential-profile/">
  <front>
    <title>TCG Platform Attribute Credential Profile, Specification Version 1.0, Revision 16</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2018" month="January"/>
  </front>
</reference>
<reference anchor="Provisioning-TPM-2.0" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf">
  <front>
    <title>TCG TPM v2.0 Provisioning Guidance, Version 1.0, Revision 1.0</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2015" month="March"/>
  </front>
</reference>
<reference anchor="IEEE-802.1X" target="https://standards.ieee.org/standard/802_1X-2020.html">
  <front>
    <title>802.1X-2020 - IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control</title>
    <author >
      <organization>IEEE Computer Society</organization>
    </author>
    <date year="2020" month="February"/>
  </front>
</reference>
<reference anchor="IEEE-802.1AE" target="https://1.ieee802.org/security/802-1ae/">
  <front>
    <title>802.1AE MAC Security (MACsec)</title>
    <author initials="M." surname="Seaman">
      <organization>IEEE Computer Society</organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="LLDP" target="https://standards.ieee.org/standard/802_1AB-2016.html">
  <front>
    <title>802.1AB-2016 - IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery</title>
    <author >
      <organization>IEEE Computer Society</organization>
    </author>
    <date year="2016" month="March"/>
  </front>
</reference>
<reference anchor="TCGRoT" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf">
  <front>
    <title>DRAFT: TCG Roots of Trust Specification</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2018" month="October"/>
  </front>
</reference>
<reference anchor="SP800-193" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf">
  <front>
    <title>NIST Special Publication 800-193: Platform Firmware Resiliency Guidelines</title>
    <author >
      <organization>National Institute for Standards and Technology</organization>
    </author>
    <date year="2018" month="April"/>
  </front>
</reference>
<reference anchor="SP800-155" target="https://csrc.nist.gov/csrc/media/publications/sp/800-155/draft/documents/draft-sp800-155_dec2011.pdf">
  <front>
    <title>BIOS Integrity Measurement Guidelines (Draft)</title>
    <author >
      <organization>National Institute of Standards and Technology</organization>
    </author>
    <date year="2011" month="December"/>
  </front>
</reference>
<reference anchor="NetEq" target="https://trustedcomputinggroup.org/resource/tcg-guidance-securing-network-equipment/">
  <front>
    <title>TCG Guidance for Securing Network Equipment, Version 1.0, Revision 29</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2018" month="January"/>
  </front>
</reference>
<reference anchor="NIST-IR-8060" target="https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf">
  <front>
    <title>Guidelines for the Creation of Interoperable Software Identification (SWID) Tags</title>
    <author >
      <organization>National Institute for Standards and Technology</organization>
    </author>
    <date year="2016" month="April"/>
  </front>
</reference>
<reference anchor="AK-Enrollment" target="https://trustedcomputinggroup.org/resource/tcg-infrastructure-working-group-a-cmc-profile-for-aik-certificate-enrollment/">
  <front>
    <title>TCG Infrastructure Working Group - A CMC Profile for AIK Certificate Enrollment Version 1.0, Revision 7</title>
    <author >
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2011" month="March"/>
  </front>
</reference>
<reference anchor="SWID-Gen" target="https://github.com/Labs64/swid-maven-plugin">
  <front>
    <title>SoftWare IDentification (SWID) Tags Generator (Maven Plugin)</title>
    <author >
      <organization>Labs64, Munich, Germany</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>

    </references>

  </back>

<!-- ##markdown-source:
H4sIAAy3OWIAA82963bbVpYu+h9PgaH8kJgQ1CW247i66jQty4k6lq2WlKT2
rq6RAZGghDIJsABQMhOnR73D/rXH2Ofl6knOvK41FwBK8qXOOR7dFYkiFtZl
rnmf30ySJKqbtJj+ks7LInsWN9Uqi/JlRT/VzcHe3rd7B9G0nBTpAv48rdJZ
k+RZM0uqtKmTZrlILtM6myZF1tyW1dtkmt3kkyxJmyarm2T/UTRJm2dxXszK
aJk/i+K4KSfP4u11Vm/zL9Ns2VzDJ4/w93q9qLJZ7b9Ql1UTfjIpF8t00piv
rC79Z0W5HTV5M4e5Xpye8Nzi1zy3+AXNLT7LFmWTxcdFk11VebOOf8qqfJbD
RPOyiNLLyyq7edZ56PinKK2y9Fl8nk1W+Fh0e/UsPhtfnMc/w/fy4ir+ripX
y+jt7TMau4ItSV7ghkXpqrkuq2dRElclTi2b5k1ZwdzzAlb23Sg+HMUvsykM
U97Cp7zX363W9sOygtf9x6rIl1mlk6uH8KbJCDcBdimDDdjfiy+yyXVRzsur
dXya4gKq/CbDjYM5P4t/hmOZldWUdnIKr9ne23/69AluZJVdwQY8i0/Suk4n
16s6a5qavrcqmgqe/fEcflteE6Fs4xPZIs3nz+KrmUzz3//G8xvB0mGxtLqj
UfxTmTduWUdVPtFPaE2HeT0p4/N13WQLfJ0eAH3uX5LdwDP/PsEPR3DeOvx/
wM7lza9XWZXOp8nJ5Id07V71H1ldw7H2fYHe/JpOPJ27I43HV1kxWZv93P72
6d5efJ7epFdAA2U63XY7uf2yGcUnWTrNtv1mHux98/ix3cztk7Raz+GGbXd2
Uhb2t8UM5nfw70Wdjq7KmwjI/Vn82+9RUVYLmOBNhrfm7OXhwf7+t/Lj00eP
nsiPjw4efy0/Pjl4tK9f2P/mkfz4+ODpHv54nLwY+Yu7Tosrur2T67SqgKrp
U/7FfhkIAb5T1rf5tDtIWk2u8yabNKsqkxHwI/ze0dFR8nTvINkfn+FzcNP5
UsJnI/gsOQCqixP6XnyODCitpjHQZfyqnMCBwAewtU1VLst5Dn+Ox3D1HNXH
CQ0Z87llekWPp1kBr1kPedhDYAoruIbxeTmBOa/pGb2J+LNQ0MkIxkkXaSGD
EmlsHmGaNrAOnH+y9xQ+uRifygrT6gpJ5rpplvWz3V1ioNl0QoMAe7hC7jCC
0XerrC5X1STbbSZwCOkyQfZIh10WyQIIab5r92z74vC7+IJHi8fEWOmr8WlV
AgMt5/EOTGIArMCNEp/gKLShwAZlYS/TRT7PszreHx3QDh+M9ui/L44Pj/iv
a/jb3hAZYo2j0C9nsLv0297oa+IT7V2kDdP5HepyhRu2tmx/Dz45TIuygIs5
T45u4MiSV+VVQCTb7gsxfQGI4ip+SWuzU/MzGz3aHwKvvKxWcNnig8dDeNnB
wfbHHsvEzS+j+QEvTXhrd+NPWf/BXrJ/AJ+cHiaHcBAw8vPjN+cJCio4io+m
ouUkmfBw9TKboCRLlvMUufwimeXV4hbkVrKsylk+z9xXiEwCMjs9jHlW8bl8
Jz6VYYCD8jBIcjiM+wpTm9DOFqxiayjU9gr2bh7vmVOCI3vsfzv4egiSZh1/
Q4e1/0n7up/sPQ729ejlMW0rUPonXc5slvu93Lx1eEHhlX6/wu2Ra+iv2D6s
DW/hMPyi7Jwn8YMDc/32H3/S3XuU7OEmnx2fPOswl7NsllUg+axSdJIW+QxY
TbwDj/Qwl2F802YP+0+G8evyJt4/oDPd++gLiFtf6ZyAO8qckoXMKanyxSam
+bH7822y9ySgIb9TH7cAfy3vXMpmqqKj8bfyzkMK6IiP5hEfxiN7Fh+/Ocy4
9CqAxD1+0WJcOmkgdBQsP2Trmii/JZ1J4hgp1roDG2TPxzNzVHIOkr3kLcwH
ubhaKLnMJ4H5iLlijuDjOfzet3ajZJc+iQ/BAtzkHTNy08dP8Sv7sMqDkCvB
SbhTcKzJnYNypS4fCs5AmJI7ia8/iZAes9J0/vPxi/4Nub29HeV1SVtQi2K4
++TxkydPRtfNYh6QmuVJxuo5L2cNCatxDSYM3hFQ3hd4hcAeauKDZ/4bvBkt
/nuRXoEKef5m9/joMN7/9ptv9pKDzdfnOhNrT42JN9UV3MpfPetX/VY+2w2/
fjQHBRoUOZw/6hwyiRj3cZHXtc7LbCEpUccn4+DiGaaQpTWoxbTisVHRe/eb
iQymeZWh1ba73J3nxepdki/S3dv8bb77fbnI+u4EvEJ8AnU6E4sS/9GubOuH
2+1vv53Wv2TNKviyfNb57uLXEgyS4Kv8UeebVZYXQLNgT2Xh9+0fOk/VGaz6
l+t0Pl8Hyv+2/cN2j5hwoscZZ0+e7qsZ9vU3j57qp/sHj9Ui+/Zb/fGbbx/v
6aePvzlQu+oyr95el/Nf2bYKZUaVTryc0wfAkIa9mNbwOT0CBvskrbO6f8Bm
NU37/9Jy3dSry3pS5Ut8Ydfmy9IGP0TD5/TkU9kaGMDFnQIQ2NMJfKfFnli1
PLCKktWT9j/RSgFt8mte36do5bi+eX5ZgUVy5xJlRo4/g3K1AgX7FT/aFuyB
pu10bKuF7Y8ef/vJwn7fyrDDrBIeybT18RqRjgjitsovwbROJlVGLBhsLbFQ
elQg3ZqxPhYfusfUItkgwuRah8rEpxLIU1al4c08IHztY42422UyKeGCF83u
ajkv02m9C0um0W5guCR4x3erfJoiSzhdXc7z+jqbJjf71f5oOZ21rRG8OThA
MMlYB9hk4cNvnyrdv46M+2e0/+eu9+fPCepJH+38SZLTsgLLOfDsjieTrK5h
cgU8Nu8XdPKiGphZloX6BczrF5mX1zLsJjzYK4QK4EGwA+OjHgfYUXwyPvRu
xx34DZj3oHfi+zRhfI7mLM/sknct7RXNn+bWwgN89erFac+0n6Pf7sk9R7ew
R4cu87hwfjt8hq4nn/E0T1tHh/8tQF3Jb3BfXqC39yar1h93ojLfTzzS/SdC
1XCvzsqLz3PDfzkry6b+pZz9Qhfrl4B5/XKztzzY++X0x+evjg9/OTv66fjo
5/Yl335xNn55wZedxorLGV/SkBF+Fofd+enTvb1k/9uv+xdf3MyXoDSMirxu
0IW9iz/gJ7s0lXRO/IrnU+++Pj6/GJ2fjmTIzsLw77E8GJsnY51Dj1vqLKvR
tVlM1sTjMtBhOTjUu3Tn9z8uangrChSrp9dEnd6g6DD/R35LHj/u35JJXU38
fuBvuwsk992l3Yp6uSuj7FJkbXdaTlaot9f8OygO8vdfptkEVZP2bqEDcYPq
7zci3qEw1OAD9gOI6WHbsc+eAWDER3//JOXgSoUbczgQd6qXZn9f5UtcUsfn
pvKMj0+ec0LhSJ/bJO4Ovv0cagDSa3J8Btz+yQbxv/l+5NUuMhi+E8dnIxyj
fcTmHHGZzTWpP3wl4JjImiyXYCJcol+237KNd9DiHqBpW/9LbsUTvhXjH5Kj
Atj4HLf9k8gBTKwqreHLZLomtxxiTejbSZpMFhPn0kYPSJq/TSZeT00yN4sO
0RwHI4fBW9iLcXx4cuj83LgD4+MfYqMDx36FIkj6qeubTzdCxFOSfJcV/Zt5
lTfXq0uMh+6+Si/rJ492MVIHdtVNVoC6vbrKC7t8pI6fiTpebKKOGN4FtNTA
undOcBjgtjjMRubB7x3GJ6sC7NEhPA+WcbGOkiSJ4U8Nmq5RdHGd17Fyt3ia
oYV5CRSdxniys3l5S1tdcWjeuOOQxJHknecUP9CoBpFkLSQPVjk8M5/DzsJj
wjxiNmprGCNtYhTEaE5uMLrq+Lff2Kr9/fch/wwqNP6cwuSzGdzBaXy5jiOc
0IZTjHeAxgaDIXr4kXHdpHNcMRrqNON8sZwTf2YRwPPKi8l8Nc1ooUvyBeHI
k3SZXoJYa/KspiksUZef8hxgbvUool1e5NPpPIuiL5AXVLAS8hXgnme4RfD/
eCAwAMhU0BOaEvehhoEqeDHsZTaf4vTTWK5m7O6m7N4wmlXlIiYmQx/XHKzH
odLl0smzUQwCaHKdAnvjP+KEM1pilMpYsT8lWHgaT+CV5SKrtuu4zuHogUyQ
yJA8J/FOPspGw7goGw6dZ9Usy5sBHft1WkeXGdAnLGaWX8FVnsa3cB2ERvNf
M08asHvzOe0gOgCBgPxa6xUsYB3DrHMwr3Gz/oY6VBrPslulvWD7bq+BzIG8
4FlY4WXmNpM2rgAZVMHkYUj46zVcIJ7flBz3dNh+J2qcBX4T5wLU2lyv4UjH
8RVeQVi+ja9vuh6wDTFtg9InHOlvv22O0//+O5zSeDrNmdnP18N4VcMk0XFk
3gGz4rfgcctd8gRR00ZNQTtf1bXsO3ppMqK8+AluHE9ik4+KpvF9eZuBdj/E
TYY5OOUHfqIzF3qHM5oBq6IgyJWV+HrHnYIQA7+alhWLKiZX/A1OAjhOfgUH
fLnK59Mh/X2agTq+Jsbi5aesb0S3h/5WNEwGln/ljrp5ekAQOrFRfAz8rSSO
A1+Dm1quGpDeuHlIS3cmH2Gs7acBDgxzWfA08S7EuUhzGDZj9iGcA88B7CWw
oNBZBJMC8UDvwTs8zxog/RoMM1qbJRt4xSSbIl3pydLdgafgLpLmbQ59yUyl
5pUCwQGjg00DpgTSpplcZ7zhwJWzWyAp5APxuIhXBdyK+Zp4S12vFuRRhPfA
VbxkXpfepPmcedxaiQg/lwtCF3WTg6yfVXN6WJPjeifVetmUtNK6Rs2pjLOC
dgLfYS6du1dAzHW9cEeuE0HepHoVsx5m5kAlX3xxhtRXyZkA1aaO+cZvszVu
L6hOWyc/nl9sDfm/8es39PPZ0X/+eHx29AJ/Pv9+/OqV+4G/EcEvb358JX/H
n/yTh29OTo5ev+CH4dO49dHJ+H9sEf1EW29OL47fvB6/2oppdy0d44KYidEt
WFYZ7jQJOxbQyE6i54en8f4j2GRJQoJdpp8xyQh+vgUCZVItC2Ab/Cts3hpl
Q5aSkAGqiECc5cD5WZTV1+UtMK9MNhH0ymqRi2IJHLBYLS5BPOEpwB+Y3VTZ
CnkNiaJ7OdwFcRSRq8/i8XJZpXmNBmUJ4oqDX0c3zJaHQVINmJKreaOfIXfy
3/Mh2J/S+Yo+YPrGwNJ6KHcZn8Ht0N/iN7fAz5GzB2y3aalEM1LxkepmoF6W
t8QxYPXP4EE/v2eqJJDXBDboivU1+PYQRc1NxhcO3p/youHXaDJP8wXs/GU6
ecv6Q+YWlV7CbdYr528FzqZGuYgKHKwERMEERuAtJSXASE5+bhjlLgVLxiMN
oGCfo7tDKrHFp81fjfDmlnXOnxH7yonTA4Hi6uF9cMIwg9mqmIilQqsE1lLR
FzPQtVasiQzjrJnAjtM1vCrhq8hLzCnnqG4sliymaQi82nE6BSrMUWlFBRj+
L11RqiYzW8OagiWEaih99RZofJ7CTK9RPCILNw/zH3FJoM/jjQuUHhwMdJ10
sUSdIkG2OKJ1TLOGbonTiz1T0oeRj+a1CE9zh0NiQzEIQqwBvtaslxh0xH1I
3+Isy3iRpQWoa27wfIG5j0JmTDy4U6xlNWunScHnxNPtFg6dyDDLB3VqNUvp
ruKt+Nnz/Tt1atLes3cNMReQaiCze07VL6hIqwoUjKmIf9qL4PJcriNW5mA5
OciqJSgPeBXdvZ3AH8pLshhYllxV6RKewBHwzaQFkHEiZB8FYgP3/e8r1KFK
YZB66XqNGrfh6CQkI4ZJSYmG9ABPM6ul0Q9ucMprptJb+J9t2nDS/Fk+49si
UmemrKd66gVu+bJPmYLh7VYsVU7DroDiHWfAoadTpi7nnbfBdnX17rw+OR/g
YHC7SZOdAHsTTbHOKlQAI7xsOGE3CxhmvkaOA1uMCY5KRoYuU4ruL/wL63K+
or3G4UDDv0YvCd2aibulC+AvVzwvHJj5xGAU/3yN1r7EdZF6KP4K9y8i/mCp
rM25Z/ADKs/4hlgjfZiVjtNrEWiT1pi0rbo6G2i1KIXRXUrhCFO3fuqKcLy2
uC0dZ1kygf9BKwLYCJkumAVurU3aTJ7iUhJJWY9zuiEbBMp2SEm8zuiY0ggt
qXyymqdVyNWU5aklxjzNG2JEvjgUyXHyXEfquYY18jk0oeV6m67Z1pywWKiv
w/PAjYGVwECrJjiDvtXhsYvyTJQGO5oVN3lVFqzCoQqMikw0A4uTqLtzM+Qs
SMtn2/QmUwJW+RDKzUjcD6v5FLUtnj1s0042ugID9ypzrGVeaqh3YiIhf4ij
Osvutanwms2BL6+urpFV0ATVSrG8Bw+eMqdDLxvSOhAHXJuaOeWc4svIrCiw
AHtx1yLdsiK0euiLKEtqXSV8esSpR1bfuihB7tQdjQ6uLqwHxMNxEaPzkynq
br2P71UuGkB4T+iKkt4PxAzzQDMxI5uAbrpy8ggLNJg60GCsHWtnXcPM23gb
65g0UxGAXnG8JWJuKY2szOLg8AjuVNr+BsdswXZCPVbF2VA9EU508kGGfi4g
aSWxySRbijYfXcJp0PNu3biaTa81RESW5HUp3grQi0EZIOcACGXZsY6Wi+r8
C912mwzF2liFZQ9oGfaa1SV/n8QKvKBG/wBobzWz8Bp04S/j/lHkK3wZa1L6
+MJXxkAbxsv5Chkf2IUJUzerBkvVqeBij/Ql5yJQ4jcw5E2e3bqXsE0PZwlm
zD0mPUU+/ZDOm446TlkQy9FRYci3xID0Dzwf3GlXDBL7qCeOeVrlN+mEqdOF
k9G44qk5VjiD+0QcXYZEXUpyKeQc25q/qChd04jeew7Kf8mMHCmiQo8BHALq
AgXZfcU0fxeLzgy/CF18h6cSRaoteBfNJaiXM2BZJBXSwDi3l26h7kW+osLb
6sgbAaqo516XwA0FFpVZJdtqOexMVLXL6fGzKiNm+bZAU/VmNUcFWP2xoqUb
XyMr7LAhcGsDnoU7UBIZz70pgvPFzXMa4DBkLrCLcImJrbCBkjP/bSs9w2Bi
TAfedoq8R0MoP7Rb/Dji8ELSsPNwznkh+K4twacueiVZD+KA8kbsdX51LZeN
buUzJtzyhnwx7fTgJKZYQZAypXdYnV6FY7LqIibLwzksmRkOnKYTxehpDlR4
51Gr4BhzUNPJPZSClskPwykezWasNqF1hHNiadYyBUHV5hKbBYpIOLRaPIMY
BII9mfJBh9wbP5msJ/OML5ML2hVYb1JWa4pDofuICIbdjTJjFjJOC66yOYrr
nXrgPeswmbJoySJWfbragFuNG7GGCXifLtyMYhsDXeRkBsGQ6R9J2RL6Z0MC
18K8T8kxCXlhYLMWLTsk9LkxE4P3difoPgmtdXMXUW1FrzaqpLjfpNGrbso6
RSq+GNYe81o8xEzEzJdgl3LSYsjCIXU6ndP4RmH0Fi6rvPo9ayDjfPmq1cGy
WXF3rq5WyIpCSNvLLKuSpkzwv9uoUmTk8Q2DW8Z6hYWKMQjUB29jPQxpG4jj
knVnUeeAdNhbcp0vgdx3zknDtC8Eleoyg1s8iKLfnsVfwE4lKC5/JxHfkpv3
+7UDP5a50rclux9B9SV388LHkC5hoVkW0nJb5REj2CkixF46JYF0/5z04GtA
91JcDt5zhbwXVWDyCcm78HrTAVbm/jvh6mOMcGPLimNBLMk8TVrVjQwrZEpN
AxyH7biyJbWY0sta6P02q0zsTE1/nsmaxHleEBOjq0reH+LORTjsKB77KFi4
Jz21Gpj83+f5UPeF8mwfJ/PaKfq05rXjONOQ09lElbxuzYTWVWWoYPCfkGZI
Fi9WDQkN40pUZckzPQla8lVLC+fes9yiNptHUTqS8kOvIURx11/JzKFaFd1t
jaIfa2HzeGKbSdrxm9TPXRgMOVLZXlX7m81GswZHHqo6eXL0UbAcPUeBBsTq
BFx44MzAIZzws4TUtdZhMlGq+o/kOJC4N3H2lsg0c6BJ6QycJA7i8Yv0bUam
hP1mU2fz2fDBsaYockSl6tJlWZowqyzer5k8mLzd6HpYeFLE2ATICJJ/esnR
X8FPoLPCZ9nhdbFUvMMGOtyPJilnCfEVsshph/glqggU2Tty5F1lYqFMgGvo
HyvSsmkDSaVM4IMctf6GRDM8NOTacBRqqGezX4b3myPzxnkLrGZF0o+021E0
tuslM5TDivY+D41jEuenZw9rx8VE3dtH5e611w2sisYK0sbUiroU8ovIZQaa
GMVxjfDgjcJjVFcUTHUW6AQm98P60odAXCjLMKuGKV2Veq+tRxH71cQnphbn
Iv0bHLC4ilEY16BTN/0CyQZ7QPrsjzSJRjZNA0jK6dQBTcKc3eluLPWz1yHj
jZjx7uhQAxyXozphAGdJsWw0UUZohng3HYnASD3T1quRN/WG2AwJIXIe4NuA
HqgmO18gZ6ZgdxQdjEKhYVT2WVY5D7ln7s70wekE8bN4xzsYhobVBYx70Cd8
NjEVzwKHkRWY8HkojnGdxOdgRV+PMAn5Jlun4i3TPY88A4W5FLWXT+LRBupz
R03i350q2nDeU4K/oXEEn1n3tfqIS3TZoiM6wi+AzQE7BJdY43l4AkV83mTL
+NGInApuNlEYAZmkVYX8DsnjJk/D1znJJT5XdGSKTjaVRBBabBb6WlN0lxJp
YhwBzrTI8LKsjbkaOSvDWrcmREWarabFYBEHHSPuWiuYo0kMMMnjBi0CcW7B
XDM5TUeV9tEsOAWKLAEHopjfVaECAM0rlm0Ut4Zthy8xl+AQWhT7mFBJy14v
xTr3+xokFbktcycC9PQIEUok5uvj0JYtlJPJqqopao3iNWQS8EVW6FU+uMdA
bGRgneJyyMB19OVWHZp/q5ojw91oOEXIwM4tlzHVC/TFw1W4cowEvj8hCzeB
6+acHkuqU0Pdy9jLlJGBN56MuczKBSt6ReFjj6Vbo/Og9MZds3dLunao864D
IwDmc+7EiXpP78wCiBf51XVDij6oGeYiUxggvUpRxHSduTvp2zT+rpzDl606
UA+GkikGyxJdXNbficKh00kVXOYm5PhH3wHrVWA4zeedzMHau+BotykK0uc1
YUnJ39Z3mBSDaxSJjeb15ljjhSJMbYBnyt8dwwXuIzoswyvBm6iKQrBdOh6d
HaoWH6Dz3sDCgOzHNNJJuVrOVWuAi5Uhp+PUgoQ1YsOz5JCDADLleuBIx+j5
h7Olt8U7x/JW46fX/E+KfOGObxqUWYuzmMmB1GvxqAlaY7hlns3E9QXDlNUa
abBcZEGKJK0TRwNeDGpmwhzuHcVGEzOFMLtCAijsph9T1BWuZQZCpwJCi6iW
hXdwms+IQNE3yp5hzEnMKgyIIJe+TdnWRO8IOXMK9iobmxsvhVbqRZLzS5xb
THn8e/YuxXkP46A+zxYKwmn3FhCiygcD4MCdNYsS5/QmrilScoIzfcVnOmC9
w9YF2sQ2cgkH8a6On8mpO5pNR/MJbGZv1BBXphe1orlqWejFJEbE54Dyxu9L
8PozUZWBd5weniGj+M8VZZ8Bm0GgG2srMgtRcRpohCThzdlkPr2AqLUUhkr5
AH7B6BLTFILAXkZG4GI+ZEGxgxIZKZVokQrS58CBXcA3rorLCmN5QrPiyceR
EtDqQFyJ+cTOJ30besXn6Rq3w54L5teKMeesJp1nqW+UhGRKBaL7jIaL7BlZ
XWI5cHUXi9XrtGZtNoiyhEbZkJMqVstpqo/ZhQOXpMNSpgBnzVyITh2Jgh6X
7deXcuwFl8v6MImKqf4pdbqJo9uJZEnTe5hExMYkQY6gD7//TrcV01Q0QoX2
KczCbQ3dNm970cRNuiQ+TjF25EZoX6X5vB6wFnzOE+oXeb1oJFb+OX84J6Wp
R6y57kREXeAx3uFoEVsmJoAZuH+dY5UZ36wRc6wdG7VOBQ0ItGKWnHvownw2
lRPMwjs9mrS6dDqtUEfDMbdekYZ2VEyXJYj4rchl8TqaBJMd9N9yZcwtSktB
K54eIhYNZjAcJhGOz9jRpDfW5MSxRuhUGmHjAWiPmfIovMQJDTCVRQ6iGrEe
m1Xtnb1aTYolirWQw2xVkc/YhRMPJcFdkvwHbDG3VHXrPscgCDHFiBRLSrNG
HgQUDfyE9BRW5elstlCNlvO6LN9t4YHP0oo067KuMZV3KIkryBFVIZxlt5gV
qF/xMRfKTQTrqHZWhmO9cJ9T1FnqSPiLD1BiFoUWIYxil89knGq10JozkmBx
W+irSpwitzWMiO+KlVgRE8LlabwEaZTstwYTnwpn71GdBB6WNcwjX3AhqVPC
mKZgtKA/h55AA6aVUJkaDwPLj0y8G/BTEkjZViYYU4UAUzjuEom4p6pAThz5
n1kF9lKJPjpbYS5h3nNMzuOIIhVK0DAuRGv5vLUQ+TKxeSaXL8AJIqcpVgOL
k2SuifKxya5Jl5LUuYAtc1lRXqVu17bUYR1CENls+4R8Fru4Gub5Ihc3IaUj
YqC+QziivN3jxxxIagMaqcqPWO0gXQ3TkMDYEqUuIVUFGD7ac1a7DJQzYI8+
iR+RQqfAsyhSf1xeYKrQTZlPvUtSz8nlFBi1DW1CF8/aIfaj4qkI1K/D8YBH
MZ8heBFQVVAbCLSF8ENGe4RXPEx/HLmN8nnseDCYjCWb7zO+XJEEp3X1pnM5
V/P/GL/+jskfIVpEWL4+ujh88/olf44Qm2y4YAYtukyEFDElpubwOEfcgroo
zf5AD04pPGFDOH2B2R2qdeDJcxHEHQ5UOrPNZQ8k476I3zCTlZv5ZXy2KpIL
VMuC3HKc5CvE/3kAnBDacydj3CUaoWaVSzmPRlvRMzEjJ6kpe1IFdEecLbAL
fIGQdCTNUTZ2wMnKEuBC2VnBzEmhbFUJ8rzZtpDsM/QnJpQHSgm1rfo1792V
KeKWvzmnZBCdoRZ3ET/P3i1hwrW58CK2hA8hEO8JKlN4OzE1TV2LWkhDCjfn
rbBqgEvr1AFwkNGNKgaMLB/ViWQB3JFAEfr2gqjthJb+E5VDxUeaqisgu89M
ARgMTbEHzfdQDxvLRw5TBu5VmNkCpN5NVrvEGl/daBPhWRehM0DZIaVZeHeY
6acmaTwj9xRZ82PNPRO1wBNGK4edQm04Glx+yaqjBNFFOaWh7y+EkzwUKQ86
n2fZkrAN62c98t+7VV3e51aNj2xhDAPDhfQ8ZRPll2RYg05aTmVqnCeqlYKb
1gnDmCvQWvCm7PjA6UPFc6BbIz+Aa9gzKZwqGkvOvHRpqSDwygpUR9k+UmU6
BYf9hXdiM89WrKZc5Vg5zGwpm8+5iFBiwD/lFWZkKEIazu2Q/TKZZpI8I29i
SiLvRr+ObjKiX3bmXaN8h9ua1xFctyVu7aUUbPtgG7GkHzHh8XyZojMPPd0+
rqNWaLliKW4Nynk+y/BqaU4/v1uS5buTqsNZkXngsvLh8/US5XWNJRER33ox
W/xf+CF2d3nVTqPCodmMT8ok4IkJ5uzB1FpbG0mySbC3gasvZh2MUn5hv4wU
6ykHwGlHXVruUCopgd3kSdIMkbJdvDb0i1g1gl3VmFdFtsY4tDXa+m0rW85H
CdsuO581tSpQXY2CnH283IkJExsHUNajkKqRgaWuLjPmdw6ZsSOErhBsY7S8
TjmGSFVvsF8vyVyI9zlXhWlVQ7coebC4AwiC3DD0sISRp5hpDZagMSAv/wb8
DHdlS30KW+1MZC4f4m9u1ybMS84QyaAL8zym+RU8OgjCvwZwVQryMGytFSBA
UKPoe/FmIC9GJTF7J/Yrb4W4SDa4McgFAWNv81OUOkjjbQ+G/I7bdO1TIsyJ
3wDNI9OnN6B7hkofslrOzka8lXKc3haxK5xFLnmiOLAFYlbD+MTG5+5qnKjv
5jkcj6ZkeX9TyDD05bX3MZWFBKN5nTXddTtHu1nD6BLRGTNRqNioR6ecKwfY
JN6GLq9465Usy1LvkSl6GG6pH8kMkc5NPn2kada0FcTH33D6YGb0OrlWLqXW
8lOfjevLGoZhoJ9cZxi9Xc5TunhjWMIyrVhomepKfU9eOD6peVxBah7VGpOx
XZVXSh8+pcs7FKsM6eXGERAbZyi/lt7XT1eiNsHeyzURKIe2mADCazm0Acei
VYANRlbDNcJcjIHfYiZboL2pmZ30cdT2NJKpwmRpa3U7JNHC+ceblk4wN1Ns
jNwc0kgT9Dn/xGS6BRVxRqq5DFjHZC8xZJFR0lPEYSfaCDKesBOBGFW4LZSQ
7mJe3SiNWqaw6O063DvCUMKtc0leUcACwlTRoDDpct0KpwIPA0bW2Jx3IgBc
iUYundcpkvNUWrDx5aFLvuZn9DuiGiFbouBP25+K+agbgtt20WQqOe8QiW3g
HxVsGZomWDqQTf+g8zsK0ntTkwZik3mCoICkv5ObC4ZrmnmGm7rKnPPqAzIB
XeIDQwcoNei0YMn/Df8IRuar5OP+fUVPvzfPfxUM91X7l+Cb7+Xp9z8ibjui
aL2Hz//0Pn6F21DF7+mXH7CJyzzmP6EaiY088KnP8m7/v/Lv/Yafg3+f7+lg
578Kfv7q/qdb/1AWxqeoqmx8+x1P238/ffTT4ZZ/6NPvCfK191uf691n5APc
/P7ejx92S973f/xVdNekWy+5/2txGASh837wo+EqHjizr/haOgn00Km6h/37
6EGMmzetTcIKF1L2wNxLuF4jQdV7NBq57/yJOZamwRtNKuFeKwSx9cdtVbXa
Zgt9aRsYNzukQVpdFX/cwpSBrd+pIAH543Oj7we5Mcikt1SZ3iLbgFTj6TDU
rBkkSpxaZEmAuelCJiLZnVjHJ0gBXS2t0L03WjmKX6WUVVSqCii6bh6ofENb
+xLQjSxRiyBVUrJRwZrYNMzdQvW0nM3gWN5xbXid1+LZ/BmX8wJ9Mn7P/y9Q
ZXA7QruRK7Up7v3g2Dzb6piGX7m/ceCOKi1AEs6lTppVGNIrIq5UTgsOCTqo
DRcKzYuWmXLs0uBl98NveD92aFHhJNUCIf8LJprhp/ENx2ojl/qt26qeGs1n
iD0Unos4U7S5pbyOQ49+K3Uu1E7Fb+18fzhNrvWv3RORg0/CHBlfwQIUpUm2
PpllMqdKNhzUadaSN4xlLvRn/8fa2YdLdgU6DeYa1GGlyMhtJZnBM4dBIC+z
PjpagDU62VxagypaLctaE9465aGNs7tri28UGe+xdf5qmJiyKXttZy5eEuN1
SIWBV4UiFgUsQ6hD/CWc7yalvAtQcdRH0IPJgYajWDiU72dri/hGSdJY51TI
nXEInG6oXgUMNlYMSFcPJDacvQN7R5FE4sPTH0f8mL2ICTvS1fNcIiFgqVRW
YQiglCDchEGD5zwWeQtLDGzO24mCN6CSY2Km9Rjl1DMwtGM0Hq4BV4ckhL3w
gHBqOhwqGGF/NprIKZB5zZyCI8RCKERtssyg9gRvbBmkY4lNRUm6Fi5COXUn
00UVbTMvzFpsKLfZZQ3QV3l3HWA6ojCPw1IYmglWht0zE293SR2bGRRIHv2B
nN8RFErQbqHLkCoIxSCkHLRN5bM7z9fG9TDkFwouoquSCLKJYMe3KdmE/Ql0
aQzZYs4C5ecEDXUe2t3qt9/6G3aBLYt+7toGiTSHBmXMLecsCNVHTogaqegd
fFT4oxMSH6Bm7MbOSIl3sD/KCvYGEVOdeMpcnagHNZLXxRlFzC9z2q0I2xT6
CyjsyKQaO3gOfy0QDqBUGxgvZXi1rFeQKgqZbbRv0jCeZykFrKOijK/SJYe2
C7crNDMOOaDHG8HjGAdzCEM0TGZzlx3jrHd01AHJRNHLsnLsorNvw7sOkVOi
epuHyRHLocIsfR2+hRXgDjsgdVd1epVJjICFSeQO1XrnnNBGitwwpkeSFDjE
7B1cWQ4zcBUc+XvE1J4mb1jOOKpEduiHDoATcapGdNDlFpkCl1ECnFrdGElW
GHu6N+0icJnna1ZwCr61lIBBIkjQelibyLEoJa9c9InCfwhXy4Ww8A3eSC0n
FyomkqVVT0i+UAIescbp9O5H8RqSQw2zf3rKjmV25SR3uoImlEwzp5pp0UsT
RwTH0Ihvhdx++Fpkooovy4q2uIem5a8IcLKDmRk3FPQBEYZxZCplAT6VgxpE
cRwjvjGGgvbGx3pHAsPnXpO7Y6iN9bRwZV/gpzDIS8lBe9AgqAXQf8xWv48+
fTVJgjNRhk0YU5NQ4DjdQ5ezp6va9/ODQXLJFyceHCAKT7FjbgXnE+xJx0L/
bMt5we9jFx/PyvaPYm0HZspTONCZfB0sBxVSuAp54bjg3Uf8r1sOiCnxohFP
79w4c0AwhUc6k8fBctg1O80Cz62eEmmSlAEHmtbG5bzvZny8JYfeSJQ6Yk4c
xbpjELrhXFIKrHaxFMiQtLAYEnhOd83Em2hz3hp0uXJpyf/LpyM5Ia7Hp03a
VdWEVktTeKIzefL5ZyKphOw5JANFk+2R6/C51Kz82T35JtjYLj/vDQoCTd5x
OnImD/n3Lz6d4DSsneYvlZnJU53Jt8FyKOMw/u7sx+cH3JsFM6MGcd+//y+W
g2os50RKqtnJeEBT2N9TRr3nZ/JZJKC67trKknrt9PNYPt/oqPviiy9elw2j
/SGVjucK2FZTGCfQFEibnZRXCGjF2gI88l9/2fsr1TZK4aK4TIC1YaC5HQU2
DzBAp5BDtxY9Mns9ZNZJChbhrllrCmwltsa8sQTfMG/WW2gnE5liKK94ewOM
/CHzeWxquAN1BtQoNlh1QXZwPyOJ4rKSyzE9E1VCblvpq2GCy5XskqJsgtb0
QjIkyD/wXBxJ8tIh/3CgPzz6K7EP+vnpXxmXbbVYpGyREvIJYxXJnH0KmCvq
YxyHAgv0qW5dSjAqGIsL2MgD8D2pwmoIcHGNqz8ZcjEw8t2gkAk5Irn+yHxU
yMiVwkyAPcX4vPAG0YvbFS1UhZqT+i9mMltLjsdGfkWubqp3PWQl6vyr7Cqt
pnOxGDFtzzuMxDMzctt28Nc2QpQviEzjf/7j/9DzjoPDQrZsDN8ITvritVSD
KMAQlVJr7mZktsA5TJ2B6e/TwV9HvtTWpPUVGftquB3CNF02FPIGKcQ4oeJs
x4kkKdVEUcpZdHp4HDuDr56XTO8Fm5+uVwJj3ItuJj4+UwKKjJHLi8/enNT9
02arx/rPcNnOyvW7/uiOXe8GyBWbyNJMWQRYB3r4//zH/wbSqbLkjVOtOKk0
jhgpQ9F4nJcqVd3LhSE6j8rMjPQPfA60osdwaQ0KPgWdRYGPOmqeyHORMigI
jRz0u/SUdsliN4Joss/SowPl49U09LDKvUDfYrlq4/YZr52bFxXyGmTF0B3l
vMBieYc54I2TERnWKbPuSq4dKZplrw9Ymispq5CmBnxPonSB++k88pF3KWli
LoEL92UhOKRfRzXaZsE5Q4M0acrjms2zdzm/fORTd2rLcrSHBkYSxBlgQx6C
RiHiJBe4b0FslizEHSn/WbdcwXOqHFUWOuDUxSCTBaeOI7QmoRa9TmQtRexY
X3u9xi0iTLHaFzsFyRVwKtj84AUXQ+EOAduNWkoABTzo/NhngL6JbqzHDuvz
b2Sfa4N7gMD7xHnaY/TmaqpyQgEUDrAQAIcPGenOlIpxJBVG2hQq5QwfFvkG
1UHcXq40mDL2DAsc8sLTru/ZtaNBySgYBYw6LkWkmIbMaIFkmvNIDSXDhUmI
xDpYYKbeBXmTl3OxPBmSlfar5op//3YOJ6mn3YCcozaA76Hr5tCZUNnw5wzL
SFkXzOzJUYkeyXDnT+OoTMFAYQxrfE25Z8GRc0AFRTfxQCboKIDiEPbmtIfU
dPVAVsBigoLFnEsmX7LIzZTTIyG9IcfmcuTZnMCNVCGonvIJsfUBe8V4zXUp
NdDGPTZ1+2KbDSl4NJx9li4oJ7w0gDHA5Mh9J1W3mE6olXY7Hvz4wa2LET04
9mZuZG8HAbvjWlEJFjNxqphC7rIJvkYtLnTPElIGhnR4TfPsBldOxAfbYYuw
BjF1PuLtEILToI/mNpK2OGSYTM64EqrRuqTQvmWVDxsh4OXgp8o5iA6uMcO8
5yiQUzoM2FmuZgdT3EaM6gc3CvvLw3J+1wztH+jXbp0nVjay7YMIZyb8Q2ry
uPB5YBghRjcvg65jbIogL02Wnz1fpBKOnt+dTcbYYFhmY8AuWrVSnwBG4ePd
GyOjrdxExapkAFx2Q6saY5z58RWmJ9RzPP75mhD61iVsjEzyD7Fgh8FJUAAH
NkJyolEMszY97obgP2iDcXE0Zy4lD/o5aJaFBw0wUAI2UTAsF2UgTU488eVu
w9jBTY83JLyqkshQHfYv1B/n0nZB89MbAb9dSmJ4qXV2VHIf3A8PnzckkY+k
yiFLzKLO32asKaFNpfkFf2DR5PFXTL0zZ3uYej3Q2qItfC22V/4BB+5BTqQl
muVv2XpGWnYQOtHgZDCsUwg3P2rugJZt+xCM6xdZ097yJf0Z604c59k0Xb9h
qB0P24cZwfzinfEPA4cf9ufR471vA/ITVRJfBFrZ3J+3qeGuU9h1ht8Nkcmc
UBBzjwnFDr/jKsLdQBpapgRj/hnU7df4p518plYGIvJpGEb0cL1L2tZMqGKg
N5kkbA2M/O90dVxiksZHwzyZH1QD4ZxcGA/zi12aTOTgNjyANe4h+WlQanju
QqnJWNpEJD/+wW6A86hEumwJ5oZfo2I1jI27/IDWqJ2dZXgW+OJ6GzbDrM0r
i4rAoKw3UKoptXsu+6OtN5gxj+vybVokdbPGen1QD8oiyYsEvppwD0MGRH2r
8n6ZNwtuAgCE+7qFeWsyopYuWWVFqRrkVv4VK9QbqlAPoAFSxHrRayM5867g
HQs4hQMhKu7S858AXYIIGGvpLdAzXZmdEIUISVE/AcJAOFXOsTo2f4d7hKcZ
fBK2F+A5IVe9zFpSyiH6w9g7pptPvwCjF2FZe+1PpfViSsrR5BapdIxihyFA
kHSK5WcADEMsZgZrRI+VgPhYRtMCGCNeJ9A+DIKDjCWfkdpUUdGgS7vETE2n
pRybzIOX8AfWV4J+oj2FirbHQFoxuJfAVbhOiBF7nXrQVm/FA1raMoj+Nj4e
jhvLm0UPHXK/TVddRllmJgOgSd+VRblY+9ZnMGFWve+tZ5XKQuqSA3oHtUeQ
xDRdGGEV5QbSANtdSLtE9nwz+NfFtQWPM8TkY/bdrUnF0mEmJuCQY88ddiS9
jZTgS7u9XRTEAUlkPgZTA+RY7wvDRKnKJ6jgaUPpcFt673BG7VejeOl8TYY5
wkiUMRbNwnv+tppecVadwKq2sllC/C+Gyxm3u8H5VDPMM2tVODKsHjsKYZPT
ScflFmJjisoUeV8KAyQ6y75TLs2dLB714PiY2n64CDPKvd05Oz7BfFej4LYL
VSh0gJVOjIqO7kvssHSnxozl/yiOhZkar555wGAoBlik5ANggAMPVTZnVGr1
U3F/LnROCUWzWkgtg3ZY9HY6lSgVMaq30e61+8R1XpHmgqfoSK7E/ibbwD4u
MZPV2azcbosKtFChaJz7YYszZK/KUmuEt1y7KdhbIlfaZtj4tk6BZe1k64ju
EebisfKK7mrkLM6/nDbOd0NOOXZRR7GuX9L3yDcIN48rTNdBSx/bVbRseu4l
Drckh79zP8SIFC/PqyUDa0o455TN8ONZfxscd3q4fuqhIP5J7gQu2l3otBOH
nXT7y9QGZ/6pHYtw1VwwTZtFBYUk7KVMD0fHXyepQmxgN1swftJismaFvA5C
KkSP8/mKJJzTG0AkuXUlQa4LqfX/3ZvC4ypEvrrvY19UEr1vg2a5kO17bx/T
b4QMux/7mgn/zei9g9oK47/4w47wVPrt3+TF8LEoXu+VIcEo9qutUajpq/4m
g/zpfXxSXC04pYDZGc7lxKpU4SiG3AeyogNamn7kV+QCL9259AS67cd2FAcq
NviEUT7PSfe++L5/u/91x3O0f3vdz3nW8sOHBNThXxTWw2y4BRpfR8XME3D4
FZRVqtw7/PiNAfj4S4ys8YqGUpl/F5pcj0zysTpz6gvqoxchU9VS9IcKTGtO
CattNc+0JsqlQsq2uhWEav0dvbm4Z/I864i1aKfLfGl3t8DIugQxvEWyWPHW
+BPtrUeo2aQrXlP7JuDaaHXpXu8PW/ETZQs9HR8H6EiGdV6n8xnz1pZihG4p
2kPfZ8KCDKm2Qb0INb6Duz3sIhuHszxgkHPHD+VgHAq5vBg32XcASdUtQdY9
HKwLvd7IRMKj0dEHjCmu2XkyR7RW8N+PJmznsHZd765AsrCEx4Nqh+1EGT89
YSNJTVMTNcZCo0opb7OfSFAg3Z/lb5ThzHp6N32aQjdkj2HYdNiJfQYpkxi5
IaJcUHduP1fOWgmmGYY9N2de85Q35BsP/dSsY5tV8bYzTifD+gxBSgYegDs9
xpMQlazlNmZl1lYoMKXARGtWv63WT5XlRMQ084QBlFWF02myWdu0jxdp6TAt
yoLifkcE/oiAsfx1mJr7Y0J/TOCP1AwbT7LvVStp84gH4uPBjCqJ0Y7NR4PE
ymhkHv4Gz+OhBRZ3ZOPL0PALbN/jEbur/d5sqA/sENjF+DRwEHCR5m+/weeS
8k/b+f347Gxs0RTuBVCwTUr5LSeScJ863LnEthNuNRgkno+Z6Ao9DAR4U85v
qJaT4Fls/phPNBfuFK7ad5LMC1d+47AIunsWoqg4ICuYQQCfoOgMQwanJKzB
TNJDHB6KJK7djzihORYOw0uK5jbDkG6AHkVP4JNR15LQdSLsFbpWuIP9TBz2
ip0BRAEM2nrV4Ve8wd5rxozv/OfjF/BX/A9j7b0+Pr9Ijs/g1j/ZY750WNKX
mvQq6FxapxNYd1nf5lNiRS6+5qI6DgNJPiDHroeVRMMjRAN82+kJX5tHA0RK
DN5MV5NM2ia8YwHCyIOMw+CMU0133ODs9O4ycQQSkyMH5H3xNUmNFqdn19UX
76C/U9hmwFqxMERwX3DGLScog2NpgYXz+bvO23EIT2TDBjsW4Onh8QKk2UFb
+LedqTpTqrIEQuKOkVkAUwRz05xkCsJxxExqbBVHkhVSrRXV6knkB4u0essy
KyUi3jrLEMYTBc0WvuoP3FiAvUEKKsuIvB4XBr7yWWNWg9GmpuHs9coNwlKA
XFpnkpI4ZKJj8BwHDhkSmvcJ42+wzekcsRzXQYNFDPoju6T6MIri0v3IiaTY
9S71dKIsWvJ1LFB7JaTuqgRBXeujIgJaSRkynh8aQNp0szF4iXS7BEVWcmmC
QR02DK1zt+P2J4Lhy455edxKDIHbuN2ygAV2fdyYoMjly+oOUyUVHtGVkx+6
1nI7V2PCzR2woi7e2HNFh5CQezf2J2MTOCMLGCIxVFtIjykpE7Ke1Aa3CNFV
9w8eiwbg0hWdn81EmKmU3LakGLXZnJMIuCdLreq6t4XX2cUJ3PjgS7LJ59x5
i/smdwY5c4DbO4HoQSly+nRvL9l/DAsbqPe8vJIu6lVGEaElac7Sp6CsFlaN
EVgry0VPRcvYrN94wFmfwOT7e2JnCTThaJPI7vM2ZVu2El8VAcSAAcIPSf6F
kpBNH/YInCRSC/87YTQ8xJSGR+8HryIEB8pAERguhRujvNVFTtXQ3vHPnfDc
3KlOL8DVaDX1prSYOH4uVbUuyQ6vvuK6abUskHZWYE58gHDBKV3YHYcS8Pmg
SXKY91Jm3hZZpBQMAT5Wb8Wc7gG7yPpl3jgIfe623dsPqw5epy0NKcWobLUB
1Fh5hxDkkkvLkR73A6HOxgoudedhDjn10HaEoohiuDumjZs7K+5a7Z3mQ/45
ukynMZUK85/6c1HqFjBCwwG8StI/cnQCYF6+m7o9DjazT1r2bZZWWG8coDKq
05triimRn/OFh5g6zNVlA2qagoHpuvZly4iumTksYsX/k0Tu7F1KGQIloYSQ
ki6LpeTXCWF5xwIEKADDVGDqwiDaPIkTz1kbIIyVW2erYMZkqZC+Bgcd/0YI
GB6SkBMrfVqbyVdfMBfWpBAgLRytBzPOndMOOdM48WZoSvicaglSiuIVcAtw
LBM2cVmpPOwWE+pWt8Fpa7YezhnxYq4p5E+n1bNBJl7YSx2yx1JYP8/rRkJH
3qsnkC2SbSPhWsFZs/DyKRkgUlssnYhkLPL8LLIp1iDreB5vBFuvUGHn5eqK
8Etw6rWpjXBTYQAYHIBGZelL0avCEAl5fAJ6ZzcNVu9Tu2OfBRuAWQriD8wr
hMnGd4V9gTqOmcFQaYjIQUwUsQNWBRznFFRakkFbtIgtHNSnJfeemw8MOaCJ
rKC0HmsMSPq+IJFo1xa3ZSb1mYxrB/94F1XUGrHSbsqooas3mXkRabETBn4N
Xigvk+OFj6Xtge8B0yNch4oazH/0oD25i1CXBIVYM8I6Rc8xIhjsdlrbrTDn
G2LhaC41HZm4J2JXt87OP5c3YA0XjJyB1oKkQdFGhKiibG5zHIpaOeMos3OD
lLM+yRJ5NYFDS+SFwKgCW/R3yKJe/YhsftdqrzMth9wDwij2Nr5Xg93GT00b
x7BB4lQ0wDreuoQ5z0m2z8xoLlR7aRsdqb0msNnY97DT5l3BiI9PPAcBvp6S
Q4mDoD1BCHk4pv6lGIFHpWEI1vaqtryLQqMGj0DBsu0JK/eS3VBHApw74fV0
bREtFaGGY8bLiAXcVNkdBzpKt2ZGEXhszYlmUEeUfm7dmN75eE+DolarPOuQ
FLcQK+uqcVofAnXtofNMTN8FccPWq5zZGPNDutzcAtq/WziA59qcd2ALuRjb
zKr9r4AvRdF/Gjdg6hpOKZaWbXrWhFVYYmCzKsmXaJGRduweuk21HB7FO/Eb
CQyh1e4G5SxICZ6rFNL0C0ld70KVoQAi3JEi8h5mTuL0ZV28545wNZhAxT35
JelK/BXZQVkKzSiS4nVV1bhDk9QnuC7kMWfAamY0s2acCllD6l/qShEua1gQ
66Ts6qY2eV+Xa1+GQcrcBjbLSHeRxYEz+gdvrM9sBWLDOo1QSzOwfB4qDrUI
XIQm3ZIZnHlXl2wX1xJIyoW8GxWmP0jtAxVBarKo25rIlXkRghMjNYlN7ZCo
DZj3gPMnRP92KR3+1HlT6xDuTBpUshy8yVN/peqgWeq9HZhFUhrfSTusxj3Y
jS35t5VimrHDdEM8REIT5ETbeWCoY3BHrOMh78IQC70Lv+PeEgJU6Xdfposc
uNP+aD8mJR+eHaIvnb70zWBzPEcn0hdd2hBWYox/F888dPFM7gB1WmV0xbCd
Vq3paJznHjJmzXxj+YxfPLzGrMniKkvOuK9DJrGrHgj+nb6iIKewJbl/QULy
HYgzsn1LhUfSIiQXMvDe3Nk+xGr2vp/KMli5vza+gN5oDq2gLzpggDKDbE3T
8tXJwvAd2kdLS30dsOJqNsP6x4LNDYSetwqPAigGijRnK4orFO1BzbIKdN8A
Aj0Ix7PY+pFS+tv+5Sgaa3L2pqqcNjhlN9jQKgNox2Ody8R6iPOQW3BDeoUP
RW84E2YnUqEFDp0wRCBV5CVlmyV9lsj8sfdluk53amf2u1TcmZrl9lZ2gGJC
kje28RQBkUXpxpvNWe2+PkkqxRQ17QMid84zKLkprODc1ZIZCKYWv7NLt6MM
8N978gI5lbAbHCRNSbUTSStkY1Iv7bCvJpX9os59OqTGgIkr4pQiPCkTp03K
uSjL9RgcWF1ZwCbDYjrNAB5zjZ56rZx2jR4u2BR0qmH/xprCfJgNu7jMr1Zc
f6HikAqYujmWhI7Tbk4vBUdu+4jCOGW0pzl40CS7nXiJmgtdDVE6CbTTZVLa
CXowV29QuyxPzESV7/m/3vg1hA3dnYXOMfFR5ALyVeYYQM9S2g3+XPCHj3Xt
eA/WAVemzoGrWG8yn+5PvHYpoxZaKuGrEte2ozIwSZ83r647CWm4PgQC0aq9
6laFNPUVFTdIoZI2i/6475KeUeQ6dSz7pLKgZCCsVZBbrjlmKg6OgjNwiMDa
gttEqKd5elWlC5MvW5Pv66dA/lCRhp66ebWE+3z5QQRsJHcZH06fQS1n1lsV
fKcCYBxJMk/prcO6F/mjgP1FeYHwMuThWDX4IxYhLDICgM5raeUDrHKLlKId
+npC36kHf/zTDj9UD7ZGEetSaG7pYz5n0BpjFD+2cVtBDB4vqerxXTz2C96k
lDyTvEwPXJ6M7kkdHW3I8BxFJrP4nmzU9yF97rrDfB9t+xG37x5ke8NEkm0M
cMMG7fz0XT+K1b3/3kda73o4T/NFvcOMGCZs2uDcOTblyb6P//gnRD3OMd+J
6AWN8gfPIf7QrN7POgLt4OvzAQ/yb0mi6ZBGO9gBljVF/y1KPrhpxy/QDMUF
nxPCD1XmfJaF0GyOPvY8YQQRa3Keeijtud45Bz1QFZA81oes4pP3QclSmWv/
AYQTHAQj6CqciPzgOXzsKugIz74bno2FpjIHdO/vxoOSyf/0r7ocKWsAfnt7
poj5yDPWlwYfMgujy3ExV/xvf/xc6/jvTxnhvz9lDnyofx749P7jo4uXQb8L
41ZPsO5Sk/zxi4Gp0S7Q3JjU/6UWrewomx88i9+YVPyxsmtXKSAWpMMXds5G
EuAt7DlUPRzAWVFKSTYVaDsNJHJiOG1a0MQNhcdqTk9zuaMssslX17gGVRTa
VYwnD3QSNHKqvW/hA9BM2CwYuc06kM0Cjj7gxr1O6CpTQa2Lq+vjCmYNylNB
8budLUlqkm4Yk2xrMBQgibcZl49yojzBz5pzoO3u0f9e9iSvi7bt9PEJB485
JNRKwMb9pCTcFxjI+Dhf0KnDffDtI+sH5fNKJjMlMFPmsWSgkYuGtoxcp/O0
uso0tVDiFDfq0wVL6NdM8/YO9nDHvj4AzR/mx0Vxf+G3/JU0pNg45h6PHtOr
/8Lv7n5hf2/0aPRo4I/+azn6I7kngbk/jFv1C5vaqoTukJEHLeHUUPTVO24Z
tQo3ldS2a96fYad3SF73lk20vSsd3G1JhoNTkUhHOPvAq/Jx2dvjxrs7cBuH
od9GhG3NeD82OUUtNdlW49prdepgoE94VdjjkrPE6R75JgEYZ6R7Ihk6nC7I
CRhixbgwhw/6amNXDZxKcjiik5z6FOfak8yjZ/Fhxw9AGJopxZ47VNGuLnIj
PRbiY8HfZj1VhpCRfEWObPk1c1Bx9qa1xD3Z+aFGdbsKulsBbe3TvoLnoWYI
FIyZqZYU9qIsMurYOsI+UF8qHKlvREjwXsI2gh1iBDVqEhiUwp9//+bHVy/i
128uDHJpODqzW5eiwhysB5Kje52CByRCgmwZRNBaY8x3zYLyN4NVhpkO0lLA
T6HOaDctShYLQc6qUApvo9196I50cO5C77ODt/NFEMFMTW6QFmfd+/44/jkz
dRQ2hY9SLoM0QsYDcBCr5ZXSUom5hR4kjLOSepKPyHMiWcqSxZX4+baIr7vn
Wnldk1OkphruJceTlY/e5Z/7oOPgWzxIVI2gpG2q6CcsvOL+121TB+0MmONc
WiJhPyASvjP8GJtqDkNeEIIWIEIG84dNkyUv8QUmdxIuFX71CMs8CJ+spwZR
C5zwzjhMCEP/rD646bCm8Pro4vDN65cotM+Ozvlnkkf3yxPM9BFABM5LMjEb
AZAiDQjImFIVuOJQwiDNqiiomy4G2tycumU72I0HqYSY5CydZHUbwebeaZIq
j5X6SVMm+F8qRTlEupM+5jd1fCp/x/9SOu59qj/GAS7Lm4wLUXrvNOYEKqqz
T0b0kG7EYMUhH0wgzPgWDDvM5qyoiyKKkKuyyTk8LllYkgMDu36dL6VVCjyB
62WpQJ6+tH7LOhwn53LEzBbtalzf+AoDgDMWWC1XpvRvQ72CkycYagAjcci1
Sa0u8R6TbllbDVq6DeuewWuPqNu3NlauVwzMrNqwpI+a77QrXWlp23XwSO37
j//226khhZ5jhSnYb/hx4D57CcBokVrc4iKcvafhHfx8fENXcuGgJ0rEsq3W
khFE+a93puBx3vgoFmNQUTjhnpHQcuPdHdJwqU8uwGYALVyU1G42prcRJiRD
kEoKF5ctkFkSJIRp87lrbn9E2Yg18jICj53wDQySB/txIzb0ZOV/nS9H6JJF
t4Z+457ep60vw+Oujn78gMfdl5/r4y4R4iFvb305ajWOue/x1pfRca3b+ZC3
t77c6ZdzX9vY8PdPPbgHvLM7iY97imEUnrce/qp38u1P269s9SJ2KCTBp/T7
f3WeNAAmijwS9HzVJ+9+p3+y+873rvmurvar/m87rJGeMRLvj6gVNoO3cNzf
ifnumYxbnWzDbyd3rab9ZOLGjJP36iTwnz7HT+nJ3TvfuXHe/4qnHkAh/mNL
C/6cQ7r5Kn747m6iFfpP3znfsYYutcTBTJ5/1O7Rfx6yhuQhT7Zur1BI303f
NcgudyoJ6vYNdLaPcv/26lhW4Frcp05Vn1YlIYwWhaublnYlSG+oF9yb38CK
WK0BJNfgBF7AZY7Ud9JWaQ59NpexvcxErFqHKL7Uxo8qOdH9PMd+0Q44wOm5
lPH0Z5PeBL9x6TnnQh0FfxofOSQKkydJyajFZF6SlxdR5lNuhMrdYo/Gp1x2
+fU3j57y2K9evcDP8D+o2VONmGQzc/UQJw3wJHElnAaDwLyuRaC1MSyaOqPo
hh6bIB2DywcxdZAqhVsZRN7YM7XGultOpaxhDybXkjQyA+XyFk4GPr+mg8D0
HFLBUeWfU2lDfLVKxZ9IfgF+ddCXrzY9V8RDDyfZmY2pd06nmInC9buKs0h5
zGxqYLBeX8X9ZdLJ26xhXxy/qXLYtHoDUJ2WJjncxaPVP3VK8RGXJ2iQ+J+x
xX8mVhO3qBXilCtwhDd1wgb0aZlTUxpO6zblABKOuFS4e+pwm03eZlpTprNx
VTcMQOdxHjFZ2A1ChcytyhCzSKlZmHYWStYHYWLjqrrHkOsSxSO9Wgpk3ryc
vNUp+YMg60LykNgLGryNS6nxkM5KLpczE/YESAahQS1PhSTBAiPbcxisDVb2
tmdlBXb2uCzlfcczg/MzxIusUP3s/XO/EotKMdXTxVrQ7MkFExIx27Eth1rf
po9uXyNfeLf2eRRrvkWxnG6qTg72rWplPLfOII4Gv13DzXIAQUHHmYjjTFiL
4C8VZQ4JniZIhDlXxpKnrO5pt9rqB2yuLp2ZZtzL4EP7i6eWiHZMChDWgrk4
dKjW0qkp6BbqoUSdD5arLMICOO9rHQwjMcrdazFcaFMOpZs5XDjyAANZoIRJ
4SKuibpKLu2daQNOKxsRULfVkbc2lOOtYCCGEIwor6XUiBK3+bAFjApnGyL6
+t4yzsUjuxm5yKphFoTdlZFk43NBPguCJ8vqLv62+jkY8TLEsIwjLpHGFi0Z
KC1Ud6E3rYZbkKHg4BoEYAZHfxcAAal747RnhZ+fEMvv0Fvtaq5tnDZw8CBj
UOpRf4XEBjykvFaPdLAuNFYjrbO4C7KMRtTam4KqVU607jBzlFsj0inLxSV+
e1PmU0q/BJmPL5EaVLoMkbuBVLHcwZ+zyxXkWspDnaUTDOemjaJzA9VcYeFZ
I974m9W80KAvM2ZUHcPEYKwV6M8MhrOztQy+WwWjcj969AQOdOfi1flAMo7h
02++fYw4PDsY+Bu4XQ+6cKdTIinKd84IZESD6/C1gvm+uorZGas1gbVqfloJ
6HJ+q7x+y/xyASu9kvmantfmjLDVkzkxp5U5wFPF+ePMBOnagq/3/dFTxR5B
gcJbT+oC4beYguwKk4PRWf4lmH9waOQkzvLGas/SuhSHzRcMvU48q16W5Wzg
6s1dPx/HiUE72QzU7qbh6/zNhKwu7F8/BXkEdBlpdEukDMjAq5zmlLvWO+2Z
nFH4q/1uGXvzBCjRn3ftx5od5liMQtAaQBLoxJNgULvfCYN4YZlzVRZXXPgn
0R/XmJCEqMO3cnhEbWQJrr3WZBSOhmLXLqRUuOeILYKQIlTPt3SXqc12XTxa
olI+TnJxi8omR4NhSonvZ+CiUzBWa4HctsVn+tNTDq/rnq4syrULky2D86e6
WoE+H3Ubl/ygr6EEAFTJe96X9t2dHdHotjnavS3NOHy4GyStDtQpiNRKG4fT
HlTIBrwQNhOWsaRoNMMhrqTpI/urVQBKW42gk8iQTT6EWEN9CI+ONRRq6SUm
QiIAaASoIYqYaYLpwKLwbtJdMLtBa+cCc9ICfDG8tlFR2E38TLaXLzd1PBJV
xGHEuddGPtyE0d6qYLQsktV0sdQOJlxs5JYBaW5LW1CcThTU1npoJJ3iriBR
h3TqO9K0sewczgErnwXaVFH2Drdw2loFzh0PDkYRbLnNCFZgbf7AwoHPsU5n
mShFivtCAC/MgZuQXXCIhzK/qHpQVWB7VioD/0AHgO/hm+JKcC4RCFa1Q3+f
tJ0pToYGT21AnPljt0emaaNT+32KZZ+citP4ykws1vD4rxhCdZUsXFosdT8b
t3AoSf2EcFVHUsLJmLO+/8ZW2IBjhzwxIm9q6tORcJ+OsrgsWT0aMMYAdUqI
VN8S7BVpG/0/L06HtnXHQOmElmByFyy0BIellpSm1ki8PbJVXCGSPdecU6O3
AG9KREhsSwkf0nVKkqzC0nOnPrsS6rmDpfHcWZiPSelzHaBcAEtVOU61Swtp
7QvU0oHoGjrALCYawq/ydcpOIlBUs2Tgg7LyyXpea8SGIHD7tH+eW41VTmkL
NJ3tyehg9LhTuDfgmqQulpjDOdDt8dC5Ht2Q+YkFaFu5EkRZiO3ZyOiXYj8J
wL4PcZL7xyGLmb5mjLmI4HvC0rdrfY/c4RBmOugREbuWs9TtQ5q0RCHKnJ+8
Q9Ljdhm+4jAno5sQCObpZTYPZddIdqRTshg0jmFXGDLKzCJJ29lv1+zqhC8i
65DkPBB5Sp021YRQCs3KyeAPFib6iiv1F8I0yTZRt7iTACpIqmiz6QAmJ8DK
m2cp2VWX2D9o83qisIXSuI4D3EQGwANrA72h5+ffx2ItoKaP9VFBGm13X40O
kRc+f4sDvS4SzwwH5ooB56zWVjy+5tJw8hE3tVnVmUW0bEx3+7R/unEoVbRt
ciCd+NWXGSjeNRXyi4VWziLGaZU0Ka6/EveYeZvKt2EreTPoIuKQJwKCGBoA
bviJ6F6Bo2ReXNCacrP1KCi80yvFEt7ZiSIPHh08/ppSXrzVNetJ7mCMTDJG
PF9zlccCxhCeLUi+yPmIOky2jVja6hUY4JVuRCtF9LlskiqmiU3yxN95Vnfi
/q6d/hYtyqmXMztBailDTEtCQmqqMwlKhv88ECCtIOnCAkEgZhThd11qsy8Q
17gagoiAwUcU8VgVl1WJ3201jUcEPcVIc5aOU5fJYSs5elPRusmBmKLrJtow
Kd/TntHSGGON1q/o+D8FKU0ngguAN41kbAuspa+bs/Nlln18tVfbJg4eUSNb
ucoa0JI+JZaZ9rxqR1pGEpFSH2gLKCPUe3Zxwsnm1Lt+8AekhkhLlS1WytBo
2wbqyrSCVDJfpFNKPQSJlU+oz7VLjOGZUfGu4CwuU0RvNRzYYXIwmWzCmVYZ
psZNNPYq+CxLbcclk+wdANw+CIaaWKDvHM9+UcqYRqJ36dUKqQK6FdiXiSJC
8KXwCT2VIxe8dK1tNoPx9QZVO/PXln34ynxMj0tFF9eORz7yxvigN1R/T5OW
pG9205Hbg9wYNLMpGBZsLJhoBSZoTvHd0i9aHfVqhnKcS7kHKdKS6xbgUHCC
YgALjtORUYYeWEK5AO6PhpNiTycGyMVTnCuvCSApDH/RVEbsDShIIwp6jCBb
aDNrMm/ouTphz9WYvUdRFD5YuwdbTs5AZIrHkHJ869IbZVwCLXaVU1QJHsl0
QHb6Kr7WJb75en+aA2YsH7c6EVP7WOTTUs6GIWr1SvooNwKGam81tHkq13PE
8ndTtROJx7DjseMZiQOerqwKdjR6CXBZe4GblpjkRCw039lbCPA2hPBE9E24
EERpqOsAkxwyUntwjREH+On+1wJiOw6AoUPv3ptzmSiPC3+dpZeVlM3zvLyS
IXvb61kaBe067uscnHuSdcaOBqNQmAvdqDeEtQl9ve4K9voMpF2rDCDQslgf
4kbcqM861Ug64VIOOp28c3iediekU/h7gCBmt5dP2qsoaBVd5iGG4Chqt3l2
BV62MQ0DnQNbROhV3AJWmWFJAmI1s4zPQzdJYQvjnjbogHK3o4Wh3j5r9khJ
lNct1jat5SrNodGjNrmcuqp9lDpU9+3a3CbbkJAUXymD6vg8yd0JB/Mdt1HX
Brz2W7h2D7rCrWwuc0ZjDVCvfnBMknRKmyJgkWnw6yUYG1zCmN7dcZV9Kzjm
NrdpFUa5ba8kI3uxFRvU84k/RBMXfC/ulkocdv510I9WAY526G8t261lPIT6
St8DsIUDZldeDY8CJUssd5ihd0dabuXNLf/3ES+/fSoep74N4Y7WpWoylPk7
Z2SzMFTk+j87aJIPxep/UI/o6M3xCx7NPnkYQM67IDCt/3DMvkFEnRYvSoiE
yLou68FR2mlR7jrpSRNudfeGoEq+07TDRneikrfWhAhahq+1eLtcMRQeiqls
m7XLa7iFQ8hi2l73+g6j1Xw58kGacmE7tpjLOhL8FopnOY0kjG+pP9MCxqDW
dUNaeFBRTIlal1qhFHoeUFozN3V9t4YR7zeHNYRB8HXKg+bAob/DVTtxbbC3
bSIq/XFsmGoXXAWxrt4XhIi7mPKCbt0r2E+0k/LLBtyDlteOV3eDOR4AKfMO
SwWdw2MMXm6hsiJToySFu+483YtFUiA0ppUWwRa3ZLcPGPMeANe8yBdZ8pxc
xT8WecK6GfubwkvcLQpvVlO0XpyqgfEgYxsIyBAGEaQjsVtVn6Gic9p185+s
J3OhxzfY4TSRdrGMizbWWvaePnpS2RT0wXbJEXTlwEJFQEJnk2/kk1E+s4GA
IF6gCQFdPZEd/8ZFrRCSFAdkHo6tJkx6kyZtLBDzrykrKvGxnnugzrKCUYQb
kscmVSw639ubeDHIKm5RMhjGPUGEsLcsZ5ZyN2w3gPa9HvQ9Tw1n2RlnvMgU
wqVMiI0Mn6s1hZlP8Dosqeedw1w2a+ltz8O91WiqVoGiv1N37lCO+3iKD5XQ
5LnmiqB/i7UC0Gt0lp1819ohPMxB+zIUh3dJN2obcC0CK+8uK6KAkAdTDwLN
YdtxUrywYZq3BlpfMPlRU7NQvH6McAxaBfkQfY6SL9qeVGXt/CcM9kTs0UGk
hrdrxwLz3abriIVzEW+NaywdvUivtpzUIhcN+v7QQ76scjE9XWqb7+8Lhwhz
puZFZosj2GJz68wGk0rp2OzVCqRvwak1wTXlU7SWgatHp15ub5ggBKGWwcIs
CXG0nRpTinbl7oruPxPkD6ouBiGHWxm2avWzH1FumMaeQgxDorOAXodISAzp
aSmX/SUGD8712EDjupYgeLaos/mNKlHzYD+ijroDm5lVjQcN6Li3LRbA8npd
kw4JTy3VrisI6BcRzBBjJKJQnBSW4svZ56PAvkuqofNZYohlQtKRPbFFZ0cT
hUzmSxFFh3PqiDGUlemt2vY5C5QbLtFZjP5edJj5HzQ1JGgu4AeMcNfJc6od
roGuCdpQYxG0t9WqqNXBa0PnJvMkaI3k0tCHcYStRGrR4BQvxKfxoriQzC+S
M8/LssGkPGpUpagjEoFGdnhczKrUX/Gd52fnPxwPRDx9++1jIjJB6GAqyopp
GBmM5/lMxLARIwZynlywmAOaL+1eoXpYOAs+omgGIgcyUCRBW5eUkjlJbe27
36uijBHVI6NSSy92PAcRYL/QsopUcoRX3eOusltwOnR+T03QK8qwLQPb0iiN
fVsvjW6GploYS1xiwp1oLLSlL2FymDRJOMguTWMdv9Fjp3QZhft0Pnf5VsDF
JKGLExs0/YuCrT5Cy+c4My+1wzlaY/ANJhW3V2ZIAxDJXRbJTIenExcww+xW
3l6SE1zSYVP++IBQBXf6oQBgLNXPTflI3ZZV0tCKnWw9KW/EYHoiNzYyMmSs
dS73FzUfy2IlQGFDNH044TQPjBZcVdoQOUi8ki5WmPjcDXjULjJB0SHxu1AQ
5K4eX7bbo/IXSWyKXENbn+pACeCzeVoj0PmJPzDKMMb8bBPfa7r5hBKTMcUv
UQuuhB0UhBArfeLyxWIlDQRkPs7dsVpOueKIzC1OTvGQtJpuH7G6LVG/BiZN
jg6CgeQzwEB4Us4SmnHvOeA3aheoc+3ErMqjiA0ObRq59ByIeE5VQCqwQOek
3gEKWuz02OOZJBkRZ6ICHeECFMdTyQbnwta7TQl1TgE4qXnGojCUp2lPIuww
MJrVejffi0zC7CXyUq5/oWqtVV5f86kI+lU3QZUi9aQtmUvkPD7dllppbZq/
uHzgk6BJSSZKu0w5cglMKrqYkk7qzYg46isMDi9HlpKRWFElRwBojYslShWi
pL8Af2RbBKrn0fcJ1IoT3BbbpCL1myLiScWB99Fo2HMJZIl5aez8xqkGaRa6
OsV1kW8jNXE+oOlXQAGSvKu7Y2YIG8O5Dw228LRzl9/IQEDuTUrWpnSRCOHE
ZGhLrwc4Hbx0lwQpi24Q+nHY7ixpPUmq9PQ0dh9Imzqr5oiOr44jn/Lgc1i1
0StJBYy3Ja4hRCRrGjI9be572gpeykJa7Z0wo4ag58OLz1suANQ2jbqdeq1e
LxdqK2ZzaoU2le7tHutNLDpCrulcM3Ik+obNeL8k0OgQyobS+S4hIVcrY+M6
Kuy9hfs2qbD8i+q0ekphDNJaRPA9Pot/Vbg2L7CJ+XI117S/nMtqJG5KWCMU
JkzaIUiScIQpzr3WVzkGfGmyEV8SA8iBYkCyhxsxcGiZlVsYlTy6wSkegyhI
rHbKu9HRcGfPRq6xQ0gz20KIIfKkGVTEZZSZS+QhjDzqNUKYgkzvrphKe9+K
pU5YVxMt8sUeUgv4AAgqK66AXLPKJXpjq5PIWZI4G1bfNDNlVWhUimPIbHVq
EDOnHm0CAUh5Vuffj5N9XRUaI0ObToo8JWIgFfU61ehgyeUd7a3kwdGXT/PR
1iwShaPF4QsPHj8ZuvY3oFxSoIww+kk3YQvFnc1hECKjVNSwVYSeNXJM1009
+gIs4tfjVgVO/NsX+Onv7d7TzET5CQZmo5YJ+LT4iLnZF2kYJVZzSlMzdmIX
JmWZ+JvYmK1cAur6hVZV5KnsJ6PAoOLouoyw2lW4/H2fCmpAWKKeN5BgZu2C
yq+57Fa7qTjtXEjvQTm9FJlczoVAqY8rMYuAmUhaNe1nDyel+3nIgVVtvylM
SKYibgOqRKW8D+w6o/MOIjfGRWY/N81gqZ/s+NT4MewKHpBB0/KhOXgty7cz
H1P/stuPwBWoqlD0wREVVg4IR2KS0r49aLwdB40e+ruQShoOt+90RSqBbkwX
ErPYXONxgrAlHNDD7+DF1LINf5VGfCRldzY1fB+q5jagVCFWGICWcm0NiT9I
CSfdpPEEtR04gCtpC0tSkTcAWUN9LcnKxVs0P7MKAz+MsJiJ5UkxCYoH1cgp
0iL0G/0MK8zTRfw8m2OfWjhX4I0nGM57nq7q67fw5ddwCucLIIBh9H0GL3ou
0YdhfAFH8yqdzTKg9RfI+sAWm6Nr7Ocsj0/TAkaCLU1B4T+avM3m8MB1uQCm
8T3c1b+VRTmEsWCDz1fzXzP4Ms4FBc/OCWgc6wH8XmdwqsPoB5jVHDW1Ezh3
LC6BScFC1vFhukh+hmlnjPt2fn2bwWbEz6+JH+Qx7aGA43NWkLcu0Tvwo6Ct
oZXRjnpGMQddpajF3akTajkmPeErMogoKQoOmUlJtVhqF8UJyZhzwF0525Vb
JHjEJaZIg/jyctZqaZEqdJTqtf6SB7W9Zxl2/ybvMGLxImwvA6X6W62hBu1r
RDqL6+c0goVTgA43hayuBnOn4VpmnGhOdWugxWGE7xYeWiezclUx8u8OGzYm
wLrkLlf0mDR0nVyXqIUOBMIDRT2rBZF0VYOdIcBA/AtpHwymuENyd+iloe8u
ye1p51fIF64XzBwj4UTDOJgULkvKXlFFpmnD1//5j/+tKMRsb3EIbr7m7Qfd
3OV/TAg6Trtt4niRw90zYTiq8YKl/PMf/4fjLf/8x/8tIU3Niw48FtJYE21T
EGAEnZk6r2bQIcQBhPC+RL5RG+qspJcYuNw7X+itP+nQKzoV5Wg6xzPpTYxY
64OuceTrw7FfCLaWvSLHIPWTWqCHcFNjur751C2YXCIOXBOMoq3q+IZxG8Ia
C7tjbJ6BiHCEy61boAMNuRCqqdbGW5pOp1rkkZlGGzhVfwli6qboPJPBnKPO
qVEdgnNd3rj+9pTFhANf55rFUso5sjPPR4w37cqI2ZBvt+aNEw9Q4VIRJxNS
VdJ5YEpoKRoZydSfOUfCZrs3YT7TAJ3+L6K80D2kBIg3CvWjjRPlnXDimsGR
2QnIraQzr5ERuQjxckLXYpk6c0nADJgUVkvThxBdVJz6WGVwYQWqXZsJrV1D
QoKvdd4EBDOZrCibKkLRiIRIb0A6Enp3pI5viaLXARqsnzOuEW100f21FyZO
kRgJ+liqKXlokeWQP9FnCuS2yZHtKoztgdwfIhpBfM3u9omfRbpnclcpJoqx
xMrY8OXPnsdrpsC0742kMcB37HPjwShCTJhWH3IyLdVfQMCUxICkhyezDoRi
xCmTdTvL39G9C3tvmZwcfoGfDHMgLWdAstHEeOy+U5QUNF2A2CJ8X6KvttZo
G+2128OybWwcHGB+F4nanMhHJwSIXthEy0oRpbA+8tLMesvjC2/5JdzTelqa
Y5oMDEdZhNlae/Ro2dFCKp8yabkrGqo+EbifciwMQmOY+53X6noUzBg6Ki4H
TsM6JhRcVuExBaO8gq5TXbVz8qz7bvD2/uCo3mUeq8eUTmHn4U74s4sTCkD3
O/eFmRMitzCkK/oDwlj4YhCEq1+hmSkFYYi85Bq/wxuGXqYWOr6WXrwTr4qO
LMFEGE/yk4eCWhNT0BBZvyRObChmcQEOsBzOyguLQoIZ8+LSv6njY+ff7zjZ
L9ppxZqpbyy2AGZfPNiWdwMnJG7AnEBYDHfJwHixuC0xWD2M70f1F186JgO4
OENYK2GrX8L0P1PFNhS3btQqihmZDn+MI0ypPQ9sKjhkt6x3MzRlC+ebN6k1
Yd+ZIEz6Fe2HPexcYUJSWOKZuEKxeFXt+U9thCzKIFWVak+5TbUuuO0fDN/M
U/Nr8P6PBaOWT31CmknGs6YgptybSQT5bD6fbqhGPgGQw9zCthVfm64UT0aP
h2HjCvenp6NHo4OR2liOVboqRt44zum4cjmfskr+Y5DXF0po6/3hLunkCgM2
hHbVRuUFHeOd/EEE6BI6bWVCyWxwgm4uqagEinUVqIq9zBLGx8uHzvq1KEpK
Pd1FqfocxljtzaT8CCdlbDGj7IlTJLsoS306JvmqaU80b1PMFPVqEwFP48g/
PGFg+ELRZ1IFmQpUbefzFh3IKdkNe/xafiF4PnLXpaTymbn33SgaN9DTGKxy
oPlKMPp8NoFiEdKFYpQdl72plaudNi9C6zMKe9JFvBifoiNHKfmRQhvSuKZi
8xJjbY6t9vGZum90mgF7ingKdLfPKG+DiQcVgEj7XmtMeHML6aHkAvb2aJZS
qTDcS4nHd0lnlkOB5WYQrsMYTQiIojEezlPQhkhoR4aInX35CGGMXjugU1DZ
ZFdENgdLRJ81PzZWRrYqT7X9e+RQm2KP8l0rGo8QoDaUh3VoJuvwrpwKTSaO
VGEiTw17TIl7eHu8VmdNMBjlU58RYJBDDCdgDfPgJjwPKdMB/r6kaAreNtUz
eKY7RklBQjw/fbq3l+w/fhz8+u3XBKmBefs6FCH3CfqfxyKh3dU6pzAp3SXx
d49FDs3Hve8mCNLFKCsjik0BFnDXjacw9IVJ1JtAwWNFGVevuHaMFfgY59Yh
B8SGqek5+/zqhJKmMAsvvn85pHmKurdZCbc7FOi81sRnNfwPnOUHp9Oz0SLO
V5c3lB6B3Wp98A2+JIwy7O+dFpHtoCJQOoZSBtia+m7l6458GEnZUcwezqCk
lbo7Iy3tKSiCukOS8FOM/KjBX1eraswT2kAHN0gfR7WHNtBJSA/dV1gEixvg
m44ppuiRwxQN+jT4jkhnrA6mc4sYEreRvxgdknQf3HkP9YvBPMmRUPAlHqoj
Hulha+uLHNWxCPGV8B6jx5IQ3QqPgTZazm+oera3ucAGrPpNX+MGA/3/3t/5
q/2LG8LgeIfQ1i2Aa4MC3h5ih8Nzrjfm+2AEwvneMW1izvlwBn1w/62Z94LN
txZyz3b2Iuu3tnPj6PoO80vfCL0f2oce3BvgfbRxmvKqDVMIX/2+Q8bBS8Ip
WeX7s88k+vIz/ANxof86jS7DWKS2MXshbbD9vy8/z0zoVEeb/vnXbfwKD9Ab
QsXP/QAxBYx3Ti/OQdscEKI7fS4D0D8Nutqn/I/MVimGqipqe4DOv1H7R7Q7
XnJfdv380/eARti4yebQNp4D/ZURKSg8LLFDfsoMwF/pkLgO0BdNbg1gRzaf
R603hX+1P4YOho8YoOWTCAf4pE38XOfw55NXw/g/zt+8HsaHz9+cxTtZMxmE
i9jwlc8xg8+1ith1INvVrmTto9jwlf8fHQX/u3h1PiQEgz562vCVT5+B716B
SD+noiEl55xSJz0rMCFI/xTznzZ3p0Bu7zBGydKapMtm5VLE31EFCecKiCcU
lRlECx6FAKVkPbkmXH1PTktMq41YNz0OE5kwalVjW7ZD1etwVc0KXaTsFcl/
pSZYPkFK8rbUgCc3jTjNQm9txLauIHlhZ4pa6tUZO9a3FFWAmtaOlEVTYYLD
NMKKHUFAqV3mVlldgZj4VR23mgiGDlCdo9rkfTlclBgk3rFWsq6mEW5E3htG
q2JOBgiayrcIn0IeZ+N8HjL/BrvfeW28c9TBZHKclXR47RTWlCV5if+Czyfw
zF/v0a8/4F9bw3anHm/+955SA+kk0Ka5S7u9a5AAkvsBatiD/sFMTjDXKtWi
GA/NZcFMW8uhC3RWXsgHtJxyY8WK5tpUYn/rID8evTweAQ2aQWJxBVGYxhjM
NhWEEdXquEd51kFuM8RwriWYQxVw4h1gp7w6ceK7BukEIu48nd5BSknYxVvL
W3aHB2K0eZDXx+cX8flpLE4gTr52ASms/swYFv2O5eBRtJxOH7Kcz0Rsp0GR
MUGwtYrI5YV/6a8t/isvJ2Dgdx8NLSfI0PzYCxjb3M7PuScrrLHg8hkgiSCT
1AIbhcvBT/gZXU6JuepYaHlXKbn4ge7YE9eD22GG2TGQE3P5Jsy6Z0+U2JjZ
gzS9f2P79oSW43096nFiz76Usdt2DO/DtGAzEye0OmX+QHnKKPwRh1PTQTog
A3fTSWuQz0Qnh4yq4uhB3Wuvztlt1Z3JT5z8h98wyym5lh6flZqtwo7paqj4
RGXsHcpDt3tCVmgAxWoBeU3kAQcR6zuvWxv7Af/euwYqlHP96vzDB3mvpVV+
7R8zCCJ/o0OWYj/00UcMYmrP2T/2eQW6JEeT9oSCBiNUu6+wyUi1+0NWFVgR
KLUd79l3Ik/Elk7G0419Ximg6t8Bg5y/2T0+Ooz3v/3mm73kwA9yYrVASSMh
MB88BT8C7QpJuuMzuMhP9oKZaK48llthuZBiFmP2dkX5GH5r23vtTsc4qX1x
km9VF5zPxkG8jm2xtSWFBfP2MBB63yB+U20Es59SOoN8JjqhFmeSeGLOQaKB
kjjsSgBi6kcrxQV8YLQc6QnWO/fe5dD4nT1BYsNhE9HxMaQwX2EzMqqyMc/3
eWZ0Y1PV+r8DrT8ojeiZSXtLPo4pkRg9jA+FGXzcICHxfcYjRkbvZ2dVal/C
WtuZ9C2Hct9mXHeZKY4cxdk3LAeZTbAcGGQnVdSin3OgrFt4GL6E6WLS6+O1
7wAVb7o7R77NIFoP/CJOmRi0H+gf5HNuLApAW3IT8Md7Z+LZ4xJHIXfk3f/e
85fE7whs473OxLtxu17Znpk8T+t80prJB/3DJwLX6cffHeOB/tiZBGv+fGp5
WVNa16EvETnHpDPEQ2vZLCQ/+4/4fHx4UsdHh6cDFX0Oqu26h2n2DxKE8Cm1
jDNVTQ3BvYOgADWxNlMb7QFqJYlyir6w/pk0vnumAyCVvg+bTqc7iHB73WCe
VaW7++BB4J/2RKMTqrWfk89MoJAr5fHeMUhKSUKXDxBidyznTUFhcNqUMR9P
pWBfIIbmZflWbK87tQKur+ZGqVcrQai45Wp3SpkWa/dfxdmcn7btzlQnrXd4
8ecbPbT0D4akspbo/wGgYHS91FwBAA== best practice.
-->
  </rfc>