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

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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-rats-yang-tpm-charra-23"
docName="draft-ietf-rats-yang-tpm-charra-21" number="9684" submissionType="IETF"
category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"
updates="" obsoletes="" xml:lang="en" version="3">

  <front>
<!-- xml2rfc v2v3 conversion 2.46.0 [rfced] Title. FYI, we have expanded the abbreviation TPM and added the abbreviation CHARRA to the title. We have also updated the short title, which is displayed in the header of the PDF pages.  Please let us know if any changes are necessary.

Original:
   A YANG Data Model for Challenge-Response-based Remote Attestation
                         Procedures using TPMs

   YANG-CHARRA for TPMs

Current:
   A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA)
               Procedures Using Trusted Platform Modules (TPMs)

   YANG Data Model for CHARRA Procedures
-->
  <front>
    <title abbrev="YANG-CHARRA abbrev="YANG Data Model for TPMs">A CHARRA Procedures">A YANG Data Model for Challenge-Response-based Challenge-Response-Based Remote Attestation (CHARRA) Procedures using TPMs</title> Using Trusted Platform Modules (TPMs)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-rats-yang-tpm-charra-23"/> name="RFC" value="9684"/>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@ietf.contact</email>
      </address>
    </author>
    <author initials="M." surname="Eckel" fullname="Michael Eckel">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>michael.eckel@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="S." surname="Bhandari" fullname="Shwetha Bhandari">
      <organization abbrev="ThoughtSpot">ThoughtSpot</organization>
      <address>
        <email>shwetha.bhandari@thoughtspot.com</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="B." surname="Sulzen" fullname="Bill Sulzen">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <email>bsulzen@cisco.com</email>
      </address>
    </author>
    <author initials="L." surname="Xia" fullname="Liang Xia (Frank)">
      <organization abbrev="Huawei">Huawei Technologies</organization>
      <address>
        <postal>
          <extaddr>Yuhuatai District</extaddr>
          <street>101 Software Avenue, Yuhuatai District</street> Avenue</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>Frank.Xialiang@huawei.com</email>
      </address>
    </author>
    <author initials="T." surname="Laffey" fullname="Tom Laffey">
      <organization abbrev="HPE">Hewlett Packard Enterprise</organization>
      <address>
        <email>tom.laffey@hpe.com</email>
      </address>
    </author>
    <author initials="G." surname="Fedorkow" fullname="Guy C. Fedorkow">
      <organization abbrev="Juniper">Juniper Networks</organization>
      <address>
        <postal>
          <street>10 Technology Park Drive</street>
          <city>Westford</city>
          <region>Massachusetts</region>
          <code>01886</code>
          <country>United States of America</country>
        </postal>
        <email>gfedorkow@juniper.net</email>
      </address>
    </author>
    <date year="2024" month="July" day="29"/>
    <area>Security</area>
    <workgroup>RATS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="October"/>
    <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>
      <?line 236?>
<!-- [rfced] Abstract. We having difficulty parsing the following. Does the suggested text clarify the requirements for the YANG module?

Original:
   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.

Perhaps:
   The defined module requires the inclusion of the following in the device
   components of the composite device on which the YANG server is running:
   at least one Trusted Platform Module (TPM) of either version 1.2 or 2.0
   as well as a corresponding TPM Software Stack (TSS), or an equivalent
   hardware implementation that includes the protected capabilities as
   provided by TPMs as well as a corresponding software stack.
-->
      <t>This document defines the YANG Remote Procedure Calls (RPCs) and a few configuration nodes that are required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in TPM-based RFC 9683 "TPM-based Network Device Remote Integrity Verification. Verification". Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots Roots of trust Trust for measurement (RTMs). Measurement (RTMs) are also provided by the YANG RPCs. 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>
  <middle>
    <?line 240?>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>This document is based on the general terminology defined in the Remote ATtestation procedureS (RATS) architecture <xref target="RFC9334"/> and uses the operational context defined in <xref target="I-D.ietf-rats-tpm-based-network-device-attest"/> target="RFC9683"/> as well as the interaction model and information elements defined in <xref target="I-D.ietf-rats-reference-interaction-models"/>. The currently supported hardware security modules (HSMs) are the Trusted Platform Modules (TPMs) <xref target="TPM1.2"/> and <xref target="TPM2.0"/> as specified by the Trusted Computing Group (TCG). One TPM, or multiple TPMs in the case of a Composite Device, are composite device, is required in order to use the YANG module defined in this document. Each TPM is used as a root Root of trust Trust for storage Storage (RTS) in order to store system security measurement Evidence.  And each TPM is used as a root Root of trust Trust for reporting Reporting (RTR) in order to retrieve attestation Evidence.  This is done by using a YANG RPC to request a quote which that exposes a rolling hash of the security measurements held internally within the TPM.</t>
      <t>Specific terms imported from <xref target="RFC9334"/> and used in this document include: include Attester, Composite Device, composite device, and Evidence.</t>
      <t>Specific terms imported from <xref target="TPM2.0-Key"/> and used in this document include: include Endorsement Key (EK), Initial Attestation Key (IAK), Attestation Identity Key (AIK), and Local Attestation Key (LAK).</t>
      <section anchor="requirements-notation">
        <name>Requirements notation</name>
        <t>The 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&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
<?line -6?>
        </t>
      </section>
    </section>
    <section anchor="the-yang-module-for-basic-remote-attestation-procedures">
      <name>The YANG Module for Basic Remote Attestation Procedures</name>
      <t>One or more TPMs MUST <bcp14>MUST</bcp14> be embedded in a Composite Device composite device that provides attestation Evidence via the YANG module defined in this document. The ietf-tpm-remote-attestation YANG module enables a composite device to take on the role of an Attester, in accordance with the Remote Attestation Procedures (RATS) RATS architecture <xref target="RFC9334"/>, target="RFC9334"/> and the corresponding challenge-response interaction model defined in the <xref target="I-D.ietf-rats-reference-interaction-models"/> document. target="I-D.ietf-rats-reference-interaction-models"/>. A fresh nonce with an appropriate amount of entropy <xref target="NIST-915121"/> MUST <bcp14>MUST</bcp14> be supplied by the YANG client in order to enable a proof-of-freshness with respect to the attestation Evidence provided by the Attester running the YANG datastore. Further, this nonce is used to prevent replay attacks. The method for communicating the relationship of each individual TPM to the specific measured component within the Composite Device composite device is out of the scope of this document.</t>
      <section anchor="yang-modules">
        <name>YANG Modules</name>
        <t>In this section section, the several two YANG modules are defined.</t>
        <section anchor="ietf-tpm-remote-attestation">
          <name>'ietf-tpm-remote-attestation'</name>
          <name>ietf-tpm-remote-attestation</name>
<!-- [rfced] Section 2.1.1. FYI, we have updated the following paragraph to include the references that are used in the YANG module:

Original:
   This YANG module imports modules from [RFC6991] with prefix 'yang',
   [RFC8348] with prefix 'hw', [RFC9642] with prefix 'ks', and 'ietf-
   tcg-algs.yang' Section 2.1.2.3 with prefix 'taa'.  Additionally,
   references are made to [RFC8032], [RFC8017], [RFC6933],
   [TPM1.2-Commands], [TPM2.0-Arch], [TPM2.0-Structures], [TPM2.0-Key],
   [TPM1.2-Structures], [bios-log], [BIOS-Log-Event-Type], as well as
   Appendix A and Appendix B.

Current (removing [RFC8032], RFC8017], Appendix A, and adding [CEL]):
   This YANG module imports modules from [RFC6991] with prefix 'yang',
   [RFC8348] with prefix 'hw', [RFC9642] with prefix 'ks', and 'ietf-
   tcg-algs.yang' Section 2.1.2.3 with prefix 'taa'.  Additionally,
   references are made to [RFC6933], [TPM1.2-Commands], [TPM2.0-Arch],
   [TPM2.0-Structures], [TPM2.0-Key], [TPM1.2-Structures], [BIOS-Log],
   [BIOS-Log-Event-Type], and [CEL], as well as Appendix B.
-->
          <t>This YANG module imports modules from <xref target="RFC6991"/> with prefix 'yang', <xref target="RFC8348"/> with prefix 'hw', <xref target="I-D.ietf-netconf-keystore"/> target="RFC9642"/> with prefix 'ks', and 'ietf-tcg-algs.yang' ietf-tcg-algs.yang <xref target="ref-ietf-tcg-algs"/> with prefix 'taa'.  Additionally, references are made to <xref target="RFC8032"/>, <xref target="RFC8017"/>, <xref target="RFC6933"/>, <xref target="TPM1.2-Commands"/>, <xref target="TPM2.0-Arch"/>, <xref target="TPM2.0-Structures"/>, <xref target="TPM2.0-Key"/>, <xref target="TPM1.2-Structures"/>, <xref target="bios-log"/>, target="BIOS-Log"/>, <xref target="BIOS-Log-Event-Type"/>, and <xref target="CEL"/>, as well as <xref target="ima"/> and <xref target="netequip-boot-log"/>.</t>
          <section anchor="features">
            <name>Features</name>
            <t>This module supports the following features:</t>
            <ul
            <dl spacing="normal">
              <li>'mtpm': Indicates
              <dt>'mtpm':</dt><dd>Indicates that multiple TPMs on the device can support remote attestation. For example, this feature could be used in cases where multiple line cards are present, each with its own TPM.</li>
              <li>'bios': Indicates TPM.</dd>
              <dt>'bios':</dt><dd>Indicates that the device supports the retrieval of BIOS/UEFI BIOS and Unified Extensible Firmware Interface (UEFI) event logs. logs <xref target="bios-log"/></li>
              <li>'ima': Indicates target="BIOS-Log"/>.</dd>
              <dt>'ima':</dt><dd>Indicates that the device supports the retrieval of event logs from the Linux Integrity Measurement Architecture (IMA, see <xref target="ima"/>).</li>
              <li>'netequip_boot': Indicates target="ima"/>).</dd>
              <dt>'netequip_boot':</dt><dd>Indicates that the device supports the retrieval of netequip boot event logs. See Appendixes <xref target="ima"/> target="ima" format="counter"/> and <xref target="netequip-boot-log"/>.</li>
            </ul> target="netequip-boot-log" format="counter"/>.</dd>
            </dl>
          </section>
          <section anchor="identities">
            <name>Identities</name>
            <t>This module supports the following types of attestation event logs: 'bios', 'ima', and 'netequip_boot'.</t>
          </section>
          <section anchor="remote-procedure-calls-rpcs">
            <name>Remote Procedure Calls (RPCs)</name>
            <t>In the following, following sections, RPCs for attestation procedures for both TPM 1.2 and TPM 2.0 attestation procedures are defined.</t>
            <section anchor="tpm12-challenge-response-attestation">
              <name>'tpm12-challenge-response-attestation'</name>
              <t>This
              <name>tpm12-challenge-response-attestation</name>
<!-- [rfced] Section 2.1.1.3.1.  The sentence below shows the first use of the abbreviation "PCR". Does the expansion of the abbreviation along with adding the preposition "via" improve the clarity of the sentence?

Original:
   This RPC allows a Verifier to request signed TPM PCRs (<em>TPM Quote</em> (_TPM Quote_
   operation) from a TPM 1.2 compliant cryptoprocessor.

Perhaps:
   This RPC allows a Verifier to request, via the _TPM Quote_ operation,
   signed TPM Platform Configuration Registers (PCRs) from a cryptoprocessor
   compliant with TPM 1.2.
-->
              <t>This RPC allows a Verifier to request signed TPM PCRs (<em>TPM Quote</em> operation) from a cryptoprocessor compliant with TPM 1.2. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all cryptoprocessors compliant with TPM 1.2 compliant cryptoprocessors will respond. A  The YANG tree diagram of this RPC is as follows:</t>
<!-- [rfced] FYI, we have updated the sourcecode type of the YANG trees to be type="yangtree", and we have updated the artwork tags to <sourcecode type="xml"> for the examples. Please let us know if any changes are necessary.
-->
              <sourcecode type="TREE"> type="yangtree">
+---x tpm12-challenge-response-attestation {taa:tpm12}?
   +---w input
   |  +---w tpm12-attestation-challenge
   |     +---w pcr-index*          pcr
   |     +---w nonce-value         binary
   |     +---w certificate-name*   certificate-name-ref
   |             {tpm:mtpm}?
   +--ro output
      +--ro tpm12-attestation-response* []
         +--ro certificate-name    certificate-name-ref
         +--ro up-time?            uint32
         +--ro TPM_QUOTE2?         binary
</sourcecode>
            </section>
            <section anchor="tpm20-challenge-response-attestation">
              <name>'tpm20-challenge-response-attestation'</name>
              <name>tpm20-challenge-response-attestation</name>
              <t>This RPC allows a Verifier to request signed TPM PCRs (<em>TPM Quote</em> operation) from a TPM 2.0 cryptoprocessor compliant cryptoprocessor. with TPM 2.0. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all cryptoprocessors compliant with TPM 2.0 compliant cryptoprocessors will respond. A The YANG tree diagram of this RPC is as follows:</t>
              <sourcecode type="TREE"> type="yangtree">
+---x tpm20-challenge-response-attestation {taa:tpm20}?
   +---w input
   |  +---w tpm20-attestation-challenge
   |     +---w nonce-value            binary
   |     +---w tpm20-pcr-selection* []
   |     |  +---w tpm20-hash-algo?   identityref
   |     |  +---w pcr-index*         pcr
   |     +---w certificate-name*      certificate-name-ref
   |             {tpm:mtpm}?
   +--ro output
      +--ro tpm20-attestation-response* []
         +--ro certificate-name       certificate-name-ref
         +--ro TPMS_QUOTE_INFO        binary
         +--ro quote-signature?       binary
         +--ro up-time?               uint32
         +--ro unsigned-pcr-values* []
            +--ro tpm20-hash-algo?   identityref
            +--ro pcr-values* [pcr-index]
               +--ro pcr-index    pcr
               +--ro pcr-value?   binary
</sourcecode>
              <t>An example of an RPC challenge requesting PCRs 0-7 from a SHA-256 bank could look like the following:</t>
              <artwork><![CDATA[
              <sourcecode type="xml"><![CDATA[
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <tpm20-attestation-challenge
    xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation">
    <certificate-name>
        (identifier of a TPM signature key with which the Attester is
        supposed to sign the attestation data)
    </certificate-name>
    <nonce>
    0xe041307208d9f78f5b1bbecd19e2d152ad49de2fc5a7d8dbf769f6b8ffdeab9
    </nonce>
    <tpm20-pcr-selection>
      <tpm20-hash-algo
          xmlns="urn:ietf:params:xml:ns:yang:ietf-tcg-algs">
        TPM_ALG_SHA256
      </tpm20-hash-algo>
      <pcr-index>0</pcr-index>
      <pcr-index>1</pcr-index>
      <pcr-index>2</pcr-index>
      <pcr-index>3</pcr-index>
      <pcr-index>4</pcr-index>
      <pcr-index>5</pcr-index>
      <pcr-index>6</pcr-index>
      <pcr-index>7</pcr-index>
    </tpm20-pcr-selection>
  </tpm20-attestation-challenge>
</rpc>
]]></artwork>
]]></sourcecode>
              <t>A successful response could be formatted as follows:</t>
              <artwork><![CDATA[
              <sourcecode type="xml"><![CDATA[
<rpc-reply message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <tpm20-attestation-response
    xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation">
    <certificate-name
        xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
        (instance of Certificate certificate name in the Keystore) keystore)
    </certificate-name>
    <attestation-data>
       (raw attestation data, i.e., the TPM quote; this includes,
       among other information, a composite digest of requested PCRs,
       the nonce, and TPM 2.0 clock information.)
    </attestation-data>
    <quote-signature>
        (signature over attestation-data using the TPM key
        identified by sig-key-id)
    </quote-signature>
  </tpm20-attestation-response>
</rpc-reply>
]]></artwork>
]]></sourcecode>
            </section>
          </section>
          <section anchor="log-retrieval">
            <name>'log-retrieval'</name>
            <name>log-retrieval</name>
            <t>This RPC allows a Verifier to acquire the Evidence which that was extended into specific TPM PCRs. A The YANG tree diagram of this RPC is as follows:</t>
<!--[rfced] Sections 2.1.1.4 and 2.1.1.5. May we align the log-retrieval, attester-supported-algos, and compute-nodes YANG trees flush left to make them consistent?  -->
            <sourcecode type="TREE"> type="yangtree">
    +---x log-retrieval
       +---w input
       |  +---w log-type        identityref
       |  +---w log-selector* []
       |     +---w name*                      string
       |     +---w (index-type)?
       |     |  +--:(last-entry)
       |     |  |  +---w last-entry-value?    binary
       |     |  +--:(index)
       |     |  |  +---w last-index-number?   uint64
       |     |  +--:(timestamp)
       |     |     +---w timestamp?           yang:date-and-time
       |     +---w log-entry-quantity?        uint16
       +--ro output
          +--ro system-event-logs
             +--ro node-data* []
                +--ro name?         string
                +--ro up-time?      uint32
                +--ro log-result
                   +--ro (attested_event_log_type)
                      +--:(bios) {bios}?
                      |  +--ro bios-event-logs
                      |     +--ro bios-event-entry* [event-number]
                      |        +--ro event-number    uint32
                      |        +--ro event-type?     uint32
                      |        +--ro pcr-index?      pcr
                      |        +--ro digest-list* []
                      |        |  +--ro hash-algo?   identityref
                      |        |  +--ro digest*      binary
                      |        +--ro event-size?     uint32
                      |        +--ro event-data*     binary
                      +--:(ima) {ima}?
                      |  +--ro ima-event-logs
                      |     +--ro ima-event-entry* [event-number]
                      |        +--ro event-number              uint64
                      |        +--ro ima-template?             string
                      |        +--ro filename-hint?            string
                      |        +--ro filedata-hash?            binary
                      |        +--ro filedata-hash-algorithm?  string
                      |        +--ro template-hash-algorithm?  string
                      |        +--ro template-hash?            binary
                      |        +--ro pcr-index?                pcr
                      |        +--ro signature?                binary
                      +--:(netequip_boot) {netequip_boot}?
                         +--ro boot-event-logs
                            +--ro boot-event-entry* [event-number]
                               +--ro event-number              uint64
                               +--ro ima-template?             string
                               +--ro filename-hint?            string
                               +--ro filedata-hash?            binary
                               +--ro filedata-hash-algorithm?  string
                               +--ro template-hash-algorithm?  string
                               +--ro template-hash?            binary
                               +--ro pcr-index?                pcr
                               +--ro signature?                binary
</sourcecode>
          </section>
          <section anchor="data-nodes">
            <name>Data Nodes</name>
            <t>This section provides a high level high-level description of the data nodes containing that contain the configuration and operational objects with within the YANG data model. For more details, please see the YANG model module itself in <xref target="ref-ietf-tpm-remote-attestation"/>.</t>
            <dl>
              <dt>Container 'rats-support-structures':</dt>
              <dd>
                <t>This houses the set of information relating to remote attestation for a device.  This includes specific device TPM(s), the compute nodes (such as line cards) on which the TPM(s) reside, and the algorithms supported across the platform.</t>
              </dd>
              <dt>Container 'tpms':</dt>
              <dd>
                <t>Provides
                <t>This provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which that may be quoted, certificates which that are associated with that TPM, and the current operational status. Of note are the certificates which that are associated with that TPM. As a certificate is associated with a particular TPM attestation key, Attestation Key, knowledge of the certificate allows a specific TPM to be identified.</t>
              </dd>
            </dl>
            <sourcecode type="TREE"> type="yangtree">
+--rw tpms
   +--rw tpm* [name]
      +--rw name                string
      +--ro hardware-based      boolean
      +--ro physical-index?     int32 {hw:entity-mib}?
      +--ro path?               string
      +--ro compute-node        compute-node-ref {tpm:mtpm}?
      +--ro manufacturer?       string
      +--rw firmware-version    identityref
      +--rw tpm12-hash-algo?    identityref {taa:tpm12}?
      +--rw tpm12-pcrs*         pcr
      +--rw tpm20-pcr-bank* [tpm20-hash-algo]  {taa:tpm20}?
      |  +--rw tpm20-hash-algo    identityref
      |  +--rw pcr-index*         tpm:pcr
      +--ro status              enumeration
      +--rw certificates
         +--rw certificate* [name]
            +--rw name            string
            +--rw keystore-ref?   leafref {ks:asymmetric-keys}?
            +--rw type?           enumeration
</sourcecode>
            <t>container 'attester-supported-algos' - Identifies
          <dl>
            <dt>Container 'attester-supported-algos':</dt>
            <dd>
              <t>This identifies which TCG hash algorithms are available for use on the Attesting platform. An operator will use this information to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed hash algorithms allowed by the TCG.</t>
             </dd>
            </dl>
            <sourcecode type="TREE"> type="yangtree">
     +--rw attester-supported-algos
        +--rw tpm12-asymmetric-signing*   identityref {taa:tpm12}?
        +--rw tpm12-hash*                 identityref {taa:tpm12}?
        +--rw tpm20-asymmetric-signing*   identityref {taa:tpm20}?
        +--rw tpm20-hash*                 identityref {taa:tpm20}?
</sourcecode>
            <t>container 'compute-nodes' - When
         <dl>
            <dt>Container 'compute-nodes':</dt>
            <dd>
               <t>When there is more than one TPM supported, this container maintains the set of information related to the compute node associated with a specific TPM. This allows each specific TPM to identify to which 'compute-node' it belongs.</t>
            </dd>
         </dl>
            <sourcecode type="TREE"> type="yangtree">
     +--rw compute-nodes {tpm:mtpm}?
        +--ro compute-node* [node-id]
           +--ro node-id                string
           +--ro node-physical-index?   int32 {hw:entity-mib}?
           +--ro node-name?             string
           +--ro node-location?         string
</sourcecode>
          </section>
          <section anchor="yang-module">
            <name>YANG Module</name>
            <figure anchor="ref-ietf-tpm-remote-attestation">
<!-- [rfced] Section 2.1.1.6. FYI, we have updated the following to include both a description and a reference. Please let us know if any changes are necessary:

Original:
       leaf event-type {
         type uint32;
         description
           "BIOS Log Event Type:
            https://trustedcomputinggroup.org/wp-content/uploads/
            TCG_PCClient_PFP_r1p05_v23_pub.pdf  Section 10.4.1";
       ...
       leaf-list event-data {
         type binary;
         description
           "The event data.  This is a binary structure
            of size 'event-size'. For more on what
            might be recorded within this object
            see [bios-log] Section 9 which details
            viable events which might be recorded.";

Current:
       leaf event-type {
         type uint32;
         description
           "BIOS log event type";
         reference
           "BIOS Log Event Type:
            TCG PC Client Platform Firmware Profile Specification
            https://trustedcomputinggroup.org/wp-content/uploads/
            TCG_PCClient_PFP_r1p05_v23_pub.pdf  Section 10.4.1";
       ...
       leaf-list event-data {
         type binary;
      description
        "The event data.  This is a binary structure
         of size 'event-size'. For more on what
         might be recorded within this object
         see BIOS-Log, Section 9, which details
         viable events that might be recorded.";
    reference
      "BIOS-Log:
       TCG PC Client Platform Firmware Profile Specification,
       https://trustedcomputinggroup.org/wp-content/uploads/
       PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf
       Section 9";
-->

<!-- [rfced] Section 2.1.1.6. FYI, in the YANG module, a reference called "ima-log" used the same URL as [CEL] <https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p41_pub.pdf>. We have updated the label to CEL:

Original:
     feature ima {
       description
         "The device supports Integrity Measurement Architecture logs.
          Many variants of IMA logs exist in the deployment.  Each encodes
          the log entry contents as the specific measurements which get
          hashed into a PCRs as Evidence.  See the reference below for
          one example of such an encoding.";
       reference
         "ima-log:
          https://www.trustedcomputinggroup.org/wp-content/uploads/
          TCG_IWG_CEL_v1_r0p41_pub.pdf  Section 5.1.6";
     ...
     grouping ima-event {
       description
         "Defines a hash log extend event for IMA measurements";
       reference
         "ima-log:
          https://www.trustedcomputinggroup.org/wp-content/uploads/
          TCG_IWG_CEL_v1_r0p41_pub.pdf  Section 4.3";

Current:
       reference
         "CEL:
          Canonical Event Log Format
          https://www.trustedcomputinggroup.org/wp-content/uploads/
          TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 5.1.6";

       reference
         "CEL:
          Canonical Event Log Format
          https://www.trustedcomputinggroup.org/wp-content/uploads/
          TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 4.3";
-->
<!-- [rfced] Section 2.1.1.6. We found the following description hard to parse. We have updated some of the prepositions used. Please let us know if any changes are necessary.

Original:
      description
        "The numbers/indexes of the PCRs.  In addition, any selection
         of PCRs MUST verify that the set of PCRs requested are a
         subset the set of PCRs exposed by in the leaf-list
         /tpm:rats-support-structures
         /tpm:tpms/tpm:tpm[name=current()]/tpm:tpm12-pcrs";

Current (adding "of" and removing "by"):
      description
        "The numbers/indexes of the PCRs.  In addition, any selection
         of PCRs MUST verify that the set of PCRs requested are a
         subset of the set of PCRs exposed in the leaf-list
         /tpm:rats-support-structures
         /tpm:tpms/tpm:tpm[name=current()]/tpm:tpm12-pcrs";
-->
<!-- [rfced] Section 2.1.1.6. We found the following description hard to parse. Does the suggested update convey the same meaning?

Original:
        description
          "The numbers of the PCRs that which are being tracked
           with a hash based on the tpm20-hash-algo.  In addition,
           any selection of PCRs MUST verify that the set of PCRs
           requested are a subset the set of PCR indexes selected
           are available for that specific TPM.";

Possibly (adding "of" and updating "PCR indexes selected are available" to "selected PCR indexes available"):
        description
          "The numbers of the PCRs that are being tracked
           with a hash based on the tpm20-hash-algo.  In addition,
           any selection of PCRs MUST verify that the set of PCRs
           requested are a subset of the set of selected PCR indexes
           available for that specific TPM.";
-->
<!-- [rfced] Section 2.1.1.6. How may we clarify the description below? Is the leaf sig a blob or the 'sig' part of the Quote2 operation?

Original:
       leaf sig {
         type binary;
         description
           "The signed data blob, i.e., the signature
            i.e., the 'sig' part of a TPM1.2 Quote2 operation
            result.";
-->
<!-- [rfced] Section 2.1.1.6. Please help us clarify the following description.

   a) We could not find "ComponentIndex" within the YANG modules specified in this document, nor in the YANG modules imported by ietf-tpm-remote-attestation. Is this the correct term?

   b) Should "TPM" be plural?

   c) Are smart NICs not covered because they are not a TPM?

Original:
  rpc tpm20-challenge-response-attestation {
    if-feature "taa:tpm20";
    description
      "This RPC accepts the input for TSS TPM 2.0 commands of the
       managed device.  ComponentIndex from the hardware manager YANG
       module is used to refer to dedicated TPM in composite devices,
       e.g. smart NICs, is not covered.";
-->
<!-- [rfced] Section 2.1.1.6. Please help us clarify the following description. Is the TPMS_ATTEST structure part of the binary output of the TPM2_Quote, or is it provided in addition to the TPM2_Quote? We could not find another mention of the TPMS_ATTEST structure. Should there be a reference provided?

Original:
       output {
         list tpm20-attestation-response {
           unique "certificate-name";
           description
             "The binary output of TPM2_Quote from one TPM of the
              node which identified by node-id. An TPMS_ATTEST structure
              including a length, encapsulated in a signature";
-->
<!-- [rfced] Section 2.1.1.6. FYI, we adjusted line lengths to fit in the 72-character limit.
-->
              <sourcecode type="YANG">
&lt;CODE BEGINS&gt; file "ietf-tpm-remote-attestation.yang@24-07-29.yang" type="yang" name="ietf-tpm-remote-attestation@2024-10-22.yang" markers="true"><![CDATA[
module ietf-tpm-remote-attestation {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation"; "urn:ietf:params:xml:ns:yang"
          + ":ietf-tpm-remote-attestation";
  prefix tpm;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-hardware {
    prefix hw;
  }
  import ietf-keystore {
    prefix ks;
  }
  import ietf-tcg-algs {
    prefix taa;
  }

  organization
    "IETF RATS (Remote ATtestation procedureS) Working Group";
  contact
    "WG Web  : &lt;https://datatracker.ietf.org/wg/rats/&gt; <https://datatracker.ietf.org/wg/rats/>
     WG List : &lt;mailto:rats@ietf.org&gt; <mailto:rats@ietf.org>
     Author  : Eric Voit &lt;evoit@cisco.com&gt; <evoit@cisco.com>
     Author  : Henk Birkholz &lt;henk.birkholz@sit.fraunhofer.de&gt; <henk.birkholz@ietf.contact>
     Author  : Michael Eckel &lt;michael.eckel@sit.fraunhofer.de&gt; <michael.eckel@sit.fraunhofer.de>
     Author  : Shwetha Bhandari &lt;shwetha.bhandari@thoughtspot.com&gt; <shwetha.bhandari@thoughtspot.com>
     Author  : Bill Sulzen &lt;bsulzen@cisco.com&gt; <bsulzen@cisco.com>
     Author  : Liang Xia (Frank) &lt;frank.xialiang@huawei.com&gt; <frank.xialiang@huawei.com>
     Author  : Tom Laffey &lt;tom.laffey@hpe.com&gt; <tom.laffey@hpe.com>
     Author  : Guy Fedorkow &lt;gfedorkow@juniper.net&gt;"; <gfedorkow@juniper.net>";
  description
    "A YANG module to enable a remote attestation procedures based
     on TPM 1.2 and TPM 2.0 based
     remote attestation procedure using a challenge-response
     interaction model and the Quote primitive operations defined
     by TPM 1.2 and TPM 2.0 Quote
     primitive operations. 2.0.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2022 2024 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); 9684; see the
     RFC itself for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here."; notices.";

  revision 2022-05-17 2024-10-22 {
    description
      "Initial version";
    reference
      "RFC XXXX: 9684: A YANG Data Model for Challenge-Response-based Challenge-Response-Based
       Remote Attestation (CHARRA) Procedures using TPMs"; Using Trusted Platform
       Modules (TPMs)";
  }

  /*****************/
  /*   Features    */
  /*****************/

  feature mtpm {
    description
      "The device supports the remote attestation of multiple
       TPM based
       TPM-based cryptoprocessors.";
  }

  feature bios {
    description
      "The device supports the bios BIOS logs.";
    reference
      "bios-log:
      "BIOS-Log:
       TCG PC Client Platform Firmware Profile Specification,
       https://trustedcomputinggroup.org/wp-content/uploads/
       PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf
       Section 9.4.5.2";
  }

  feature ima {
    description
      "The device supports Integrity Measurement Architecture logs.
       Many variants of IMA logs exist in the deployment.  Each
       encodes the log entry contents as the specific measurements which
       that get hashed into a PCRs as Evidence.  See the reference
       below for one example of such an encoding.";
    reference
      "ima-log:
      "CEL:
       Canonical Event Log Format,
       https://www.trustedcomputinggroup.org/wp-content/uploads/
       TCG_IWG_CEL_v1_r0p41_pub.pdf
       TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 5.1.6";
  }

  feature netequip_boot {
    description
      "The device supports the netequip_boot logs.";
    reference
      "netequip-boot-log:
       RFC XXXX
      "RFC 9684: A YANG Data Model for Challenge-Response-Based
       Remote Attestation (CHARRA) Procedures Using Trusted Platform
       Modules (TPMs), Appendix B";
  }

  /*****************/
  /*   Typedefs    */
  /*****************/

  typedef pcr {
    type uint8 {
      range "0..31";
    }
    description
      "Valid index number for a PCR.  A {{TPM2.0}} compliant PCR index compliant with
       TPM 2.0 extends from 0-31.  At this time time, a typical TPM would
       have no more than 32 PCRS."; PCRs.";
  }

  typedef compute-node-ref {
    type leafref {
      path "/tpm:rats-support-structures/tpm:compute-nodes"
         + "/tpm:compute-node/tpm:node-id";
    }
    description
      "This type is used to reference a hardware node.  Note that an
       implementer might include an alternative leafref pointing to a
       different YANG module node specifying hardware structures.";
  }

  typedef certificate-name-ref {
    type leafref {
      path "/tpm:rats-support-structures/tpm:tpms/tpm:tpm"
         + "/tpm:certificates/tpm:certificate/tpm:name";
    }
    description
      "A type which that allows identification of a TPM based TPM-based
       certificate.";
  }

  /******************/
  /*   Identities   */
  /******************/

  identity attested_event_log_type {
    description
      "Base identity allowing categorization of the reasons why an
       attested measurement has been taken on an Attester.";
  }

  identity ima {
    base attested_event_log_type;
    description
      "An event type recorded in IMA.";
  }

  identity bios {
    base attested_event_log_type;
    description
      "An event type associated with BIOS/UEFI.";
  }

  identity netequip_boot {
    base attested_event_log_type;
    description
      "An event type associated with Network Equipment Boot.";
  }

  /*****************/
  /*   Groupings   */
  /*****************/

  grouping tpm20-hash-algo {
    description
      "The cryptographic algorithm used to hash the TPM2 PCRs. PCRs compliant
       with TPM 2.0.  This must be from the list of platform platform-
       supported options.";
    leaf tpm20-hash-algo {
      type identityref {
        base taa:hash;
      }
      must '. = /tpm:rats-support-structures'
         + '/tpm:attester-supported-algos/tpm:tpm20-hash' {
        error-message "This platform does not support tpm20-hash-algo"; "
                    + "tpm20-hash-algo";
      }
      description
        "The hash scheme that is used to hash a TPM2.0 PCR. PCR compliant with
         TPM 2.0.  This must be one of those supported by a platform.
         Where this object does not appear, the default value of
         'taa:TPM_ALG_SHA256' will apply.";
    }
  }

  grouping tpm12-hash-algo {
    description
      "The cryptographic algorithm used to hash the TPM1.2 PCRs."; PCRs compliant
       with TPM 1.2.";
    leaf tpm12-hash-algo {
      type identityref {
        base taa:hash;
      }
      must '. = /tpm:rats-support-structures'
         + '/tpm:attester-supported-algos/tpm:tpm12-hash' {
        error-message "This platform does not support tpm12-hash-algo"; "
                    + "tpm12-hash-algo";
      }
      description
        "The hash scheme that is used to hash a TPM1.2 PCR. PCR compliant with
         TPM 1.2.  This MUST be one of those supported by a platform.
         Where this object does not appear, the default value of
         'taa:TPM_ALG_SHA1' will apply.";
    }
  }

  grouping nonce {
    description
      "A random number intended to guarantee freshness and for use
       as part of a replay-detection mechanism.";
    leaf nonce-value {
      type binary;
      mandatory true;
      description
        "A cryptographically generated random number which that should
         not be predictable prior to its issuance from a random
         number generation function.  The random number MUST be
         derived from an entropy source external to the Attester.

         Note that a nonce sent into a TPM will typically be 160 or
         256 binary digits long.  (This is 20 or 32 bytes.)  So if
         fewer binary digits are sent, this nonce object will be
         padded with leading zeros within Quotes returned from the
         TPM.
         Additionally  Additionally, if more bytes are sent, the nonce will
         be trimmed to the most significant binary digits.";
    }
  }

  grouping tpm12-pcr-selection {
    description
      "A Verifier can request one or more PCR values using its
       individually created Attestation Key Certificate (AC).
       The corresponding selection filter is represented in this
       grouping.";
    leaf-list pcr-index {
      type pcr;
      description
        "The numbers/indexes of the PCRs.  In addition, any selection
         of PCRs MUST verify that the set of PCRs requested are a
         subset of the set of PCRs exposed by in the leaf-list
         /tpm:rats-support-structures
         /tpm:tpms/tpm:tpm[name=current()]/tpm:tpm12-pcrs";
    }
  }

  grouping tpm20-pcr-selection {
    description
      "A Verifier can acquire one or more PCR values, which are
       hashed together in a TPM2B_DIGEST coming from the TPM2.
       The selection list of desired PCRs and the Hash Algorithm hash algorithm
       is represented in this grouping.";
    list tpm20-pcr-selection {
      unique "tpm20-hash-algo";
      description
        "Specifies the list of PCRs and Hash Algorithms hash algorithms that can be
         returned within a TPM2B_DIGEST.";
      reference
        "TPM2.0-Structures:
         Trusted Platform Module Library Part 2: Structures
         https://www.trustedcomputinggroup.org/wp-content/uploads/
         TPM-Rev-2.0-Part-2-Structures-01.38.pdf
         TPM-Rev-2.0-Part-2-Structures-01.38.pdf, Section 10.9.7";
      uses tpm20-hash-algo;
      leaf-list pcr-index {
        type pcr;
        description
          "The numbers of the PCRs that which are being tracked
           with a hash based on the tpm20-hash-algo.  In addition,
           any selection of PCRs MUST verify that the set of PCRs
           requested are a subset the set of PCR indexes selected
           are available for that specific TPM.";
      }
    }
  }

  grouping certificate-name-ref {
    description
      "Identifies a certificate in a keystore.";
    leaf certificate-name {
      type certificate-name-ref;
      mandatory true;
      description
        "Identifies a certificate in a keystore.";
    }
  }

  grouping tpm-name {
    description
      "A unique TPM on a device.";
    leaf name {
      type string;
      description
        "Unique system generated system-generated name for a TPM on a device.";
    }
  }

  grouping node-uptime {
    description
      "Uptime in seconds of the node.";
    leaf up-time {
      type uint32;
      description
        "Uptime in seconds of this node reporting its data"; data.";
    }
  }

  grouping tpm12-attestation {
    description
      "Contains an instance of TPM1.2 style signed cryptoprocessor
       measurements. measurements signed
       according to TPM 1.2.  It is supplemented by unsigned
       Attester information.";
    uses node-uptime;
    leaf pcr-data {
      type binary;
      description
        "The value created and signed for the quote
         (type TPM_PCR_INFO_SHORT), i.e., the 'pcrData' part of
          a TPM1.2 Quote2 operation result.";
      reference
        "TPM1.2-Commands:
         TPM1.2 commands rev116 July 2007, Section 16.5
         TPM Main Part 3 Commands, Rev116,
         https://trustedcomputinggroup.org/wp-content/uploads
         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf";
         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,
         Section 16.5";
    }
    leaf version-info {
      type binary;
      description
        "The version info (type TPM_CAP_VERSION_INFO),
         i.e., the 'versionInfo' part of a TPM1.2 Quote2
         operation result.";
      reference
        "TPM1.2-Commands:
         TPM1.2 commands rev116 July 2007, Section 16.5
         TPM Main Part 3 Commands, Rev116,
         https://trustedcomputinggroup.org/wp-content/uploads
         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf";
         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,
         Section 16.5";
    }
    leaf sig {
      type binary;
      description
        "The signed data blob, i.e., the signature signature,
         i.e., the 'sig' part of a TPM1.2 Quote2 operation
         result.";
      reference
        "TPM1.2-Commands:
         TPM1.2 commands rev116 July 2007, Section 16.5
         TPM Main Part 3 Commands, Rev116,
         https://trustedcomputinggroup.org/wp-content/uploads
         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf";
         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,
         Section 16.5";
    }
  }

  grouping tpm20-attestation {
    description
      "Contains an instance of TPM2 style signed cryptoprocessor
       measurements. measurements signed
       according to TPM 2.0.  It is supplemented by unsigned
       Attester information.";
    leaf quote-data {
      type binary;
      mandatory true;
      description
        "A hash of the latest PCR values (and the hash algorithm
         used)
         which that have been returned from an Attester for the
         selected PCRs and Hash Algorithms."; hash algorithms.";
      reference
        "TPM2.0-Structures:
         TPM Main Part 2 TPM Structures, Rev116,
         https://www.trustedcomputinggroup.org/wp-content/uploads/
         TPM-Rev-2.0-Part-2-Structures-01.38.pdf
         TPM-Rev-2.0-Part-2-Structures-01.38.pdf, Section 10.12.1";
    }
    leaf quote-signature {
      type binary;
      description
        "Quote signature returned by TPM Quote.  The signature was
         generated using the key associated with the
         certificate 'name'.";
      reference
        "TPM2.0-Structures:
         TPM Main Part 2 TPM Structures, Rev116,
         https://www.trustedcomputinggroup.org/wp-content/uploads/
         TPM-Rev-2.0-Part-2-Structures-01.38.pdf
         TPM-Rev-2.0-Part-2-Structures-01.38.pdf, Section 11.2.1";
    }
    uses node-uptime;
    list unsigned-pcr-values {
      description
        "PCR values in each PCR bank.  This might appear redundant
         with the TPM2B_DIGEST, but that digest is calculated across
         multiple PCRs.  Having to verify across multiple PCRs does
         not necessarily make it easy for a Verifier to appraise just
         the minimum set of PCR information which that has changed since
         the last received TPM2B_DIGEST.  Put another way, why should
         a Verifier reconstruct the proper value of all PCR Quotes
         when only a single PCR has changed?
         To help this happen, if the Attester does know specific PCR
         values, the Attester can provide these individual values via
         'unsigned-pcr-values'.  By comparing this information to
         what has previously been validated, it is possible for a
         Verifier to confirm the Attester's signature while
         eliminating significant processing.  Note that there should
         never be a result where an unsigned PCR value differs from
         what may be reconstructed from the within the PCR quote and
         the event logs.
         If there is a difference, a signed result which that has been
         verified from retrieved logs is considered definitive.";
      uses tpm20-hash-algo;
      list pcr-values {
        key "pcr-index";
        description
          "List of one PCR bank.";
        leaf pcr-index {
          type pcr;
          description
            "PCR index number.";
        }
        leaf pcr-value {
          type binary;
          description
            "PCR value.";
          reference
            "TPM2.0-Structures:
             https://www.trustedcomputinggroup.org/wp-content/uploads/
             TPM-Rev-2.0-Part-2-Structures-01.38.pdf
             TPM Main Part 2 TPM Structures, Rev116,
             https://www.trustedcomputinggroup.org/wp-content/
             uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf,
             Section 10.9.7";
        }
      }
    }
  }

  grouping log-identifier {
    description
      "Identifier for type of log to be retrieved.";
    leaf log-type {
      type identityref {
        base attested_event_log_type;
      }
      mandatory true;
      description
        "The corresponding identity of the measurement log type identity."; type.";
    }
  }

  grouping boot-event-log {
    description
      "Defines a specific instance of an event log entry
       and corresponding to the information used to
       extend the PCR"; PCR.";
    leaf event-number {
      type uint32;
      description
        "Unique event number of this event event, which monotonically
         increases within a given event log.  The maximum event
         number should not be reached, nor is wrapping back to
         an earlier number supported.";
    }
    leaf event-type {
      type uint32;
      description
        "BIOS Log Event Type: log event type.";
      reference
        "BIOS-Log-Event-Type:
         TCG PC Client Platform Firmware Profile Specification,
         https://trustedcomputinggroup.org/wp-content/uploads/
         TCG_PCClient_PFP_r1p05_v23_pub.pdf
         TCG_PCClient_PFP_r1p05_v23_pub.pdf, Section 10.4.1";
    }
    leaf pcr-index {
      type pcr;
      description
        "Defines the PCR index that this event extended"; extended.";
    }
    list digest-list {
      description
        "Hash of event data"; data.";
      leaf hash-algo {
        type identityref {
          base taa:hash;
        }
        description
          "The hash scheme that is used to compress the event data in
           each of the leaf-list digest items.";
      }
      leaf-list digest {
        type binary;
        description
          "The hash of the event data using the algorithm of the
           'hash-algo' against 'event data'.";
      }
    }
    leaf event-size {
      type uint32;
      description
        "Size of the event data"; data.";
    }
    leaf-list event-data {
      type binary;
      description
        "The event data.  This is a binary structure
         of size 'event-size'. For more on what
         might be recorded within this object
         see [bios-log] BIOS-Log, Section 9 9, which details
         viable events which that might be recorded.";
      reference
        "BIOS-Log:
         TCG PC Client Platform Firmware Profile Specification,
         https://trustedcomputinggroup.org/wp-content/uploads/
         PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_
         v51.pdf, Section 9";
    }
  }

  grouping bios-event-log {
    description
      "Measurement log created by the BIOS/UEFI.";
    list bios-event-entry {
      key "event-number";
      description
        "Ordered list of TCG described the TCG-described event log
         that extended the PCRs in the order they
         were logged"; logged.";
      uses boot-event-log;
    }
  }

  grouping ima-event {
    description
      "Defines a hash log extend event for IMA measurements"; measurements.";
    reference
      "ima-log:
      "CEL:
       Canonical Event Log Format,
       https://www.trustedcomputinggroup.org/wp-content/uploads/
       TCG_IWG_CEL_v1_r0p41_pub.pdf
       TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 4.3";
    leaf event-number {
      type uint64;
      description
        "Unique event number of this event event, which monotonically
         increases.  The maximum event number should not be
         reached, nor is wrapping back to an earlier number
         supported.";
    }
    leaf ima-template {
      type string;
      description
        "Name of the template used for event logs
         for e.g. logs,
         e.g., ima, ima-ng, ima-sig"; ima-sig.";
    }
    leaf filename-hint {
      type string;
      description
        "File name (including the path) that was measured.";
    }
    leaf filedata-hash {
      type binary;
      description
        "Hash of filedata as updated based upon the
         filedata-hash-algorithm";
         filedata-hash-algorithm.";
    }
    leaf filedata-hash-algorithm {
      type string;
      description
        "Algorithm used for filedata-hash"; filedata-hash.";
    }
    leaf template-hash-algorithm {
      type string;
      description
        "Algorithm used for template-hash"; template-hash.";
    }
    leaf template-hash {
      type binary;
      description
        "hash(filedata-hash, filename-hint)";
    }
    leaf pcr-index {
      type pcr;
      description
        "Defines the PCR index that this event extended"; extended.";
    }
    leaf signature {
      type binary;
      description
        "Digital file signature which that provides a
         fingerprint for the file being measured.";
    }
  }

  grouping ima-event-log {
    description
      "Measurement log created by IMA.";
    list ima-event-entry {
      key "event-number";
      description
        "Ordered list of ima IMA event logs by event-number"; event-number.";
      uses ima-event;
    }
  }

  grouping network-equipment-boot-event-log {
    description
      "Measurement log created by Network Equipment Boot.  The
       Network Equipment Boot format is identical to the IMA
       format.  In contrast to the IMA log, the Network Equipment
       Boot log includes every measurable event from an Attester,
       including the boot stages of BIOS, Bootloader, etc. In
       essence, the scope of events represented in this format
       combines the scope of BIOS events and IMA events.";
    list boot-event-entry {
      key "event-number";
      description
        "Ordered list of Network Equipment Boot event logs
         by event-number, using the IMA event format.";
      uses ima-event;
    }
  }

  grouping event-logs {
    description
      "A selector for the log and its type.";
    choice attested_event_log_type {
      mandatory true;
      description
        "Event log type determines the event logs log's content.";
      case bios {
        if-feature "bios";
        description
          "BIOS/UEFI event logs"; logs.";
        container bios-event-logs {
          description
            "BIOS/UEFI event logs"; logs.";
          uses bios-event-log;
        }
      }
      case ima {
        if-feature "ima";
        description
          "IMA event logs.";
        container ima-event-logs {
          description
            "IMA event logs.";
          uses ima-event-log;
        }
      }
      case netequip_boot {
        if-feature "netequip_boot";
        description
          "Network Equipment Boot event logs"; logs.";
        container boot-event-logs {
          description
            "Network equipment boot Equipment Boot event logs.";
          uses network-equipment-boot-event-log;
        }
      }
    }
  }

  /**********************/
  /*   RPC operations   */
  /**********************/

  rpc tpm12-challenge-response-attestation {
    if-feature "taa:tpm12";
    description
      "This RPC accepts the input for TSS TPM 1.2 commands made to
       the attesting device.";
    input {
      container tpm12-attestation-challenge {
        description
          "This container includes every information element defined
           in the reference challenge-response interaction model for
           remote attestation.  Corresponding values are based on
           TPM 1.2 structure definitions";
        uses tpm12-pcr-selection;
        uses nonce;
        leaf-list certificate-name {
          if-feature "tpm:mtpm";
          type certificate-name-ref;
          must "/tpm:rats-support-structures/tpm:tpms"
             + "/tpm:tpm[tpm:firmware-version='taa:tpm12']"
             + "/tpm:certificates/"
             + "/tpm:certificate[name=current()]" {
            error-message "Not an available TPM1.2 AIK certificate.";
          }
          description
            "When populated, the RPC will only get a Quote for the
             TPMs associated with these certificate(s).";
        }
      }
    }
    output {
      list tpm12-attestation-response {
        unique "certificate-name";
        description
          "The binary output of TPM 1.2 TPM_Quote/TPM_Quote2,
           including the PCR selection and other associated
           attestation evidence
           metadata"; metadata.";
        uses certificate-name-ref {
          description
            "Certificate associated with this tpm12-attestation.";
        }
        uses tpm12-attestation;
      }
    }
  }

  rpc tpm20-challenge-response-attestation {
    if-feature "taa:tpm20";
    description
      "This RPC accepts the input for TSS TPM 2.0 commands of the
       managed device.  ComponentIndex from the hardware manager YANG
       module is used to refer to dedicated TPM in composite devices,
       e.g.
       e.g., smart NICs, is NICs are not covered.";
    input {
      container tpm20-attestation-challenge {
        description
          "This container includes every information element defined
           in the reference challenge-response interaction model for
           remote attestation.  Corresponding values are based on
           TPM 2.0 structure definitions"; definitions.";
        uses nonce;
        uses tpm20-pcr-selection;
        leaf-list certificate-name {
          if-feature "tpm:mtpm";
          type certificate-name-ref;
          must "/tpm:rats-support-structures/tpm:tpms"
             + "/tpm:tpm[tpm:firmware-version='taa:tpm20']"
             + "/tpm:certificates/"
             + "/tpm:certificate[name=current()]" {
            error-message "Not an available TPM2.0 AIK certificate.";
          }
          description
            "When populated, the RPC will only get a Quote for the
             TPMs associated with the certificates.";
        }
      }
    }
    output {
      list tpm20-attestation-response {
        unique "certificate-name";
        description
          "The binary output of TPM2_Quote from one TPM of the
           node
           node, which is identified by node-id. An  A TPMS_ATTEST
           structure including a length, encapsulated in a signature";
           signature.";
        uses certificate-name-ref {
          description
            "Certificate associated with this tpm20-attestation.";
        }
        uses tpm20-attestation;
      }
    }
  }

  rpc log-retrieval {
    description
      "Logs Entries
      "Log entries are either identified either via indices or via by providing
       the last line received.  The number of lines returned can be
       limited.  The type of log is a choice that can be augmented.";
    input {
      uses log-identifier;
      list log-selector {
        description
          "Only log entries which that meet all of the provided selection
           criteria
           provided are to be returned by the RPC output.";
        leaf-list name {
          type string;
          description
            "Name of one or more unique TPMs on a device.  If this
             object exists, a selection should pull only the objects
             related to these TPM(s).  If it does not exist, all
             qualifying TPMs that are 'hardware-based' equals true
             on the device are selected.  When this selection
             criteria is provided, it will be considered as a logical
             AND with any other selection criteria provided.";
        }
        choice index-type {
          description
            "Last log entry received, log index number, or
             timestamp.";
          case last-entry {
            description
              "The last entry of the log already retrieved.";
            leaf last-entry-value {
              type binary;
              description
                "Content of a log event which that matches 1:1 with a
                 unique event record contained within the log.  Log
                 entries after this will be passed to the
                 requester.  Note: if log entry values are not
                 unique, this MUST return an error.";
            }
          }
          case index {
            description
              "Numeric index of the last log entry retrieved, or
               zero.";
            leaf last-index-number {
              type uint64;
              description
                "The last numeric index number of a log entry.
                 Zero means to start at the beginning of the log.
                 Entries after this will be passed to the
                 requester.";
            }
          }
          case timestamp {
            leaf timestamp {
              type yang:date-and-time;
              description
                "Timestamp from which to start the extraction.  The
                 next log entry after this timestamp is to
                 be sent.";
            }
            description
              "Timestamp from which to start the extraction.";
          }
        }
        leaf log-entry-quantity {
          type uint16;
          description
            "The number of log entries to be returned. If omitted, it
             means all of them.";
        }
      }
    }
    output {
      container system-event-logs {
        description
          "The requested data of the measurement event logs"; logs.";
        list node-data {
          unique "name";
          description
            "Event logs of a node in a distributed system
             identified by the node name"; name.";
          uses tpm-name;
          uses node-uptime;
          container log-result {
            description
              "The requested entries of the corresponding log.";
            uses event-logs;
          }
        }
      }
    }
  }

  /**************************************/

  /****************************************/
  /*   Config &amp; and Oper accessible nodes   */
  /**************************************/
  /****************************************/

  container rats-support-structures {
    description
      "The datastore definition enabling verifiers Verifiers or relying
       parties Relying
       Parties to discover the information necessary to use the
       remote attestation RPCs appropriately.";
    container compute-nodes {
      if-feature "tpm:mtpm";
      description
        "Holds the set of device subsystems/components in this
         composite device that support TPM operations.";
      list compute-node {
        key "node-id";
        unique "node-name";
        config false;
        min-elements 2;
        description
          "A component within this composite device which that
           supports TPM operations.";
        leaf node-id {
          type string;
          description
            "ID of the compute node, such as Board Serial Number.";
        }
        leaf node-physical-index {
          if-feature "hw:entity-mib";
          type int32 {
            range "1..2147483647";
          }
          config false;
          description
            "The entPhysicalIndex for the compute node.";
          reference
            "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex";
        }
        leaf node-name {
          type string;
          description
            "Name of the compute node.";
        }
        leaf node-location {
          type string;
          description
            "Location of the compute node, such as slot number.";
        }
      }
    }
    container tpms {
      description
        "Holds the set of TPMs within an Attester.";
      list tpm {
        key "name";
        unique "path";
        description
          "A list of TPMs in this composite device that RATS
           can be conducted with.";
        uses tpm-name;
        leaf hardware-based {
          type boolean;
          config false;
          mandatory true;
          description
            "System generated
            "System-generated indication of whether this is a
             hardware based
             hardware-based TPM.";
        }
        leaf physical-index {
          if-feature "hw:entity-mib";
          type int32 {
            range "1..2147483647";
          }
          config false;
          description
            "The entPhysicalIndex for the TPM.";
          reference
            "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex";
        }
        leaf path {
          type string;
          config false;
          description
            "Device path to a unique TPM on a device.  This can
             change across reboots.";
        }
        leaf compute-node {
          if-feature "tpm:mtpm";
          type compute-node-ref;
          config false;
          mandatory true;
          description
            "Indicates the compute node measured by this TPM.";
        }
        leaf manufacturer {
          type string;
          config false;
          description
            "TPM manufacturer name.";
        }
        leaf firmware-version {
          type identityref {
            base taa:cryptoprocessor;
          }
          mandatory true;
          description
            "Identifies the cryptoprocessor API set supported.  This
             is automatically configured by the device and should not
             be changed.";
        }
        uses tpm12-hash-algo {
          when "derived-from-or-self(firmware-version, 'taa:tpm12')";
          if-feature "taa:tpm12";
          refine "tpm12-hash-algo" {
            description
              "The hash algorithm overwrites the default used for
               PCRs on this TPM1.2 compliant TPM1.2-compliant cryptoprocessor.";
          }
        }
        leaf-list tpm12-pcrs {
          when "derived-from-or-self(../firmware-version, 'taa:tpm12')"; "
             + "'taa:tpm12')";
          if-feature "taa:tpm12";
          type pcr;
          description
            "The PCRs which that may be extracted from this TPM1.2 TPM1.2-
             compliant cryptoprocessor.";
        }
        list tpm20-pcr-bank {
          when "derived-from-or-self(../firmware-version, 'taa:tpm20')"; "
             + "'taa:tpm20')";
          if-feature "taa:tpm20";
          key "tpm20-hash-algo";
          description
            "Specifies the list of PCRs that may be extracted for
             a specific Hash Algorithm hash algorithm on this TPM2 compliant TPM2-compliant
             cryptoprocessor.  A bank is a set of PCRs which that are
             extended using a particular hash algorithm.";
          reference
            "TPM2.0-Structures:
             https://www.trustedcomputinggroup.org/wp-content/uploads/
             TPM-Rev-2.0-Part-2-Structures-01.38.pdf
             Trusted Platform Module Library Part 2: Structures,
             https://www.trustedcomputinggroup.org/wp-content/
             uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf,
             Section 10.9.7";
          leaf tpm20-hash-algo {
            type identityref {
              base taa:hash;
            }
            must '/tpm:rats-support-structures'
               + '/tpm:attester-supported-algos'
               + '/tpm:tpm20-hash' {
              error-message "This platform does not support tpm20-hash-algo"; "
                          + "tpm20-hash-algo";
            }
            description
              "The hash scheme actively being used to hash a
               one or more TPM2.0 PCRs.";
          }
          leaf-list pcr-index {
            type tpm:pcr;
            description
              "Defines what TPM2 which TPM2.0 PCRs are available to be
               extracted.";
          }
        }
        leaf status {
          type enumeration {
            enum operational {
              value 0;
              description
                "The TPM currently is running normally and
                 is ready to accept and process TPM quotes.";
              reference
                "TPM2.0-Arch:
                 https://trustedcomputinggroup.org/wp-content/uploads/
                 TCG_TPM2_r1p59_Part1_Architecture_pub.pdf
                 Trusted Platform Module Library Part 1:
                 Architecture, https://trustedcomputinggroup.org/
                 wp-content/uploads/
                 TCG_TPM2_r1p59_Part1_Architecture_pub.pdf,
                 Section 12";
            }
            enum non-operational {
              value 1;
              description
                "TPM is in a state such as startup or shutdown shutdown, which
                 precludes the processing of TPM quotes.";
            }
          }
          config false;
          mandatory true;
          description
            "TPM chip self-test status.";
        }
        container certificates {
          description
            "The TPM's certificates, including EK certificates Certificates
             and Attestation Key certificates."; Certificates.";
          list certificate {
            key "name";
            description
              "Three types of certificates can be accessed via
               this statement, including Initial Attestation
               Key Certificate, Local Attestation Key Certificate Certificate, or
               Endorsement Key Certificate.";
            leaf name {
              type string;
              description
                "An arbitrary name uniquely identifying a certificate
                 associated within with a key within a TPM.";
            }
            leaf keystore-ref {
              if-feature "ks:central-keystore-supported";
              if-feature "ks:asymmetric-keys";
              type leafref {
                path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" "/ks:keystore/ks:asymmetric-keys"
                   + "/ks:name"; "/ks:asymmetric-key/ks:name";
              }
              description
                "A reference to a specific certificate of an
                 asymmetric key in the Keystore."; keystore.";
            }
            leaf type {
              type enumeration {
                enum endorsement-certificate {
                  value 0;
                  description
                    "Endorsement Key (EK) Certificate type.";
                  reference
                    "TPM2.0-Key:
                     TPM 2.0 Keys for Device Identity and Attestation
                     https://trustedcomputinggroup.org/wp-content/
                     uploads/TPM-2p0-Keys-for-Device-Identity-
                     and-Attestation_v1_r12_pub10082021.pdf
                     and-Attestation_v1_r12_pub10082021.pdf,
                     Section 3.11";
                }
                enum initial-attestation-certificate {
                  value 1;
                  description
                    "Initial Attestation key Key (IAK) Certificate
                     type.";
                  reference
                    "TPM2.0-Key:
                     TPM 2.0 Keys for Device Identity and Attestation
                     https://trustedcomputinggroup.org/wp-content/
                     uploads/TPM-2p0-Keys-for-Device-Identity-
                     and-Attestation_v1_r12_pub10082021.pdf
                     and-Attestation_v1_r12_pub10082021.pdf,
                     Section 3.2";
                }
                enum local-attestation-certificate {
                  value 2;
                  description
                    "Local Attestation Key (LAK) Certificate type.";
                  reference
                    "TPM2.0-Key:
                     TPM 2.0 Keys for Device Identity and Attestation
                     https://trustedcomputinggroup.org/wp-content/
                     uploads/TPM-2p0-Keys-for-Device-Identity-
                     and-Attestation_v1_r12_pub10082021.pdf
                     and-Attestation_v1_r12_pub10082021.pdf,
                     Section 3.2";
                }
              }
              description
                "Function supported by this certificate from within
                 the TPM.";
            }
          }
        }
      }
    }
    container attester-supported-algos {
      description
        "Identifies which TPM algorithms are available for use on an
         attesting platform.";
      leaf-list tpm12-asymmetric-signing {
        when "../../tpm:tpms"
           + "/tpm:tpm[tpm:firmware-version='taa:tpm12']";
        if-feature "taa:tpm12";
        type identityref {
          base taa:asymmetric;
        }
        description
          "Platform Supported TPM12
          "Platform-supported TPM1.2 asymmetric algorithms.";
      }
      leaf-list tpm12-hash {
        when "../../tpm:tpms"
           + "/tpm:tpm[tpm:firmware-version='taa:tpm12']";
        if-feature "taa:tpm12";
        type identityref {
          base taa:hash;
        }
        description
          "Platform supported TPM12
          "Platform-supported TPM1.2 hash algorithms.";
      }
      leaf-list tpm20-asymmetric-signing {
        when "../../tpm:tpms"
           + "/tpm:tpm[tpm:firmware-version='taa:tpm20']";
        if-feature "taa:tpm20";
        type identityref {
          base taa:asymmetric;
        }
        description
          "Platform Supported TPM20
          "Platform-supported TPM2.0 asymmetric algorithms.";
      }
      leaf-list tpm20-hash {
        when "../../tpm:tpms"
           + "/tpm:tpm[tpm:firmware-version='taa:tpm20']";
        if-feature "taa:tpm20";
        type identityref {
          base taa:hash;
        }
        description
          "Platform supported TPM20
          "Platform-supported TPM2.0 hash algorithms.";
      }
    }
  }
}
&lt;CODE ENDS&gt;
</sourcecode>
]]></sourcecode>
            </figure>
          </section>
        </section>
        <section anchor="ietf-tcg-algs">
          <name>'ietf-tcg-algs'</name>
          <name>ietf-tcg-algs</name>
<!-- [rfced] Section 2.1.2. Please help us clarify the phrase "By including this full table" in the following passage. Is Table 3 of [TCG-Algos] meant? FYI, we have updated the introductory paragraph to reflect which references are used in the ietf-tcg-algs module:

Original:
   This document has encoded the TCG Algorithm definitions of
   [TCG-Algos], revision 1.32.  By including this full table as a
   separate YANG file within this document, it is possible for other
   YANG models to leverage the contents of this model.  Specific
   references to [RFC2104], [RFC8017], [ISO-IEC-9797-1],
   [ISO-IEC-9797-2], [ISO-IEC-10116], [ISO-IEC-10118-3],
   [ISO-IEC-14888-3], [ISO-IEC-15946-1], [ISO-IEC-18033-3],
   [IEEE-Std-1363-2000], [IEEE-Std-1363a-2004], [NIST-PUB-FIPS-202],
   [NIST-SP800-38C], [NIST-SP800-38D], [NIST-SP800-38F],
   [NIST-SP800-56A], [NIST-SP800-108], [bios-log], as well as Appendix A
   and Appendix B exist within the YANG Model.

Current (removing version information, replacing "model" with "module", removing [bios-log], Appendix A, and Appendix B, and adding [RFC8032], [TPM1.2-Structures], and [TPM2.0]):
   This document has encoded the TCG Algorithm definitions of
   [TCG-Algos].  By including this full table as a
   separate YANG file within this document, it is possible for other
   YANG modules to leverage the contents of this module.  Specific
   references to [TPM1.2-Structures], [TPM2.0], [RFC2104], [RFC8017],
   [RFC8032], [ISO-IEC-9797-1], [ISO-IEC-9797-2], [ISO-IEC-10116],
   [ISO-IEC-10118-3], [ISO-IEC-14888-3], [ISO-IEC-15946-1],
   [ISO-IEC-18033-3], [IEEE-Std-1363-2000], [IEEE-Std-1363a-2004],
   [NIST-FIPS-202], [NIST-SP800-38C], [NIST-SP800-38D],
   [NIST-SP800-38F], [NIST-SP800-56A], and [NIST-SP800-108] exist
   within the YANG module.
-->
          <t>This document has encoded the TCG Algorithm definitions of <xref target="TCG-Algos"/>, revision 1.32. By including this full table as a separate YANG file within this document, it is possible for other YANG models modules to leverage the contents of this model. module.  Specific references to <xref target="TPM1.2-Structures"/>, <xref target="TPM2.0"/>, <xref target="RFC2104"/>, <xref target="RFC8017"/>, <xref target="RFC8032"/>, <xref target="ISO-IEC-9797-1"/>, <xref target="ISO-IEC-9797-2"/>, <xref target="ISO-IEC-10116"/>, <xref target="ISO-IEC-10118-3"/>, <xref target="ISO-IEC-14888-3"/>, <xref target="ISO-IEC-15946-1"/>, <xref target="ISO-IEC-18033-3"/>, <xref target="IEEE-Std-1363-2000"/>, <xref target="IEEE-Std-1363a-2004"/>, <xref target="NIST-PUB-FIPS-202"/>, target="NIST-FIPS-202"/>, <xref target="NIST-SP800-38C"/>, <xref target="NIST-SP800-38D"/>, <xref target="NIST-SP800-38F"/>, <xref target="NIST-SP800-56A"/>, <xref target="NIST-SP800-108"/>, <xref target="bios-log"/>, as well as <xref target="ima"/> and <xref target="netequip-boot-log"/> target="NIST-SP800-108"/> exist within the YANG Model.</t> module.</t>
          <section anchor="features-1">
            <name>Features</name>
            <t>There are two types of features supported: 'TPM12' 'tpm12' and 'TPM20'. 'tpm20'. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG TPM API is present on an Attester. Most commonly, only one type of cryptoprocessor will be available on an Attester.</t>
          </section>
          <section anchor="identities-1">
            <name>Identities</name>
            <t>There are three types of identities in this model:</t>
            <ol spacing="normal" type="1">
              <li>Cryptographic functions supported by a TPM algorithm; these include: include 'asymmetric', 'symmetric', 'hash', 'signing', 'anonymous_signing', 'encryption_mode', 'method', and 'object_type'. The definitions of each of these are in Table 2 of <xref target="TCG-Algos"/>.</li>
              <li>API specifications for TPM types: 'tpm12' and 'tpm20'</li>
              <li>Specific algorithm types: Each algorithm type defines what which cryptographic functions may be supported, and on which type of API specification. It is not required that an implementation of a specific TPM will support all algorithm types. The contents of each specific algorithm mirrors what is in the contents of Table 3 of <xref target="TCG-Algos"/>.</li>
            </ol>
          </section>
          <section anchor="ref-ietf-tcg-algs">
            <name>YANG Module</name>
<!-- [rfced] Section 2.1.2.3. Should the ALG_ID information move from the reference to the description for each identity? For example:

Current:
       description
         "RSA algorithm.";
       reference
         "TCG-Algos: TCG Algorithm Registry, Rev1.32, Table 3, and
          RFC 8017. ALG_ID: 0x0001";

Perhaps:
       description
         "RSA algorithm. ALG_ID: 0x0001.";
       reference
         "TCG-Algos: TCG Algorithm Registry, Rev1.32, Table 3, and
          RFC 8017";
-->
<!-- [rfced] Section 2.1.2.3. Should the reference for identity TPM_ALG_SHA3_256 also include ISO/IEC 10118-3?

Original:
     identity TPM_ALG_SHA3_256 {
       if-feature "tpm20";
       base tpm20;
       base hash;
       description
         "ISO/IEC 10118-3 - the SHA 256 algorithm";
       reference
         "TCG-Algos:TCG Algorithm Registry Rev1.32  Table 3 and
          NIST PUB FIPS 202. ALG_ID: 0x0027";

Perhaps:
     identity TPM_ALG_SHA3_256 {
       if-feature "tpm20";
       base tpm20;
       base hash;
       description
         "The SHA-256 algorithm. ALG_ID: 0x0027";
       reference
         "TCG-Algos: TCG Algorithm Registry, Rev1.32, Table 3, and
          NIST FIPS 202, and
          ISO/IEC 10118-3";
-->
<!-- [rfced] Section 2.1.2.3. FYI, we have added references to the following. Please let us know if any changes are necessary.

Original:
  feature tpm12 {
    description
      "This feature indicates algorithm support for the TPM 1.2 API
       as per Section 4.8 of TPM1.2-Structures:
       TPM Main Part 2 TPM Structures
       https://trustedcomputinggroup.org/wp-content/uploads/TPM-
       Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf";
  }

  feature tpm20 {
    description
      "This feature indicates algorithm support for the TPM 2.0 API
       as per Section 11.4 of Trusted Platform Module Library
       Part 1: Architecture. See TPM2.0-Arch:
       https://trustedcomputinggroup.org/wp-content/uploads/
       TCG_TPM2_r1p59_Part1_Architecture_pub.pdf";
  }

Current:

     feature tpm12 {
       description
         "This feature indicates algorithm support for the TPM 1.2 API
          per Section 4.8 of TPM1.2-Structures.";
       reference
         "TPM1.2-Structures: TPM Main Part 2 TPM Structures,
          https://trustedcomputinggroup.org/wp-content/uploads/
          TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
          TPM_ALGORITHM_ID values, Section 4.8";
     }

     feature tpm20 {
       description
         "This feature indicates algorithm support for the TPM 2.0 API
          per Section 11.4 of Trusted Platform Module Library Part 1:
          Architecture.";
       reference
        "TPM2.0-Arch: Trusted Platform Module Library Part 1:
         Architecture, https://trustedcomputinggroup.org/wp-content/
         uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf,
         Section 11.4";
-->
            <sourcecode type="YANG">
&lt;CODE BEGINS&gt; file "ietf-tcg-algs@2022-03-23.yang" type="yang" markers="true" name="ietf-tcg-algs@2024-10-22.yang"><![CDATA[
module ietf-tcg-algs {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-tcg-algs";
  prefix taa;

  organization
    "IETF RATS (Remote ATtestation procedureS) Working Group";
  contact
    "WG Web:   &lt;https://datatracker.ietf.org/wg/rats/&gt;   <https://datatracker.ietf.org/wg/rats/>
     WG List:  &lt;mailto:rats@ietf.org&gt;  <mailto:rats@ietf.org>
     Author:   Eric Voit &lt;mailto:evoit@cisco.com&gt;"; <mailto:evoit@cisco.com>";
  description
    "This module defines identities for asymmetric algorithms.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2022 2024 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); 9684; see the
     RFC itself for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
     are to be interpreted as described in BCP 14 (RFC 2119)
     (RFC 8174) when, and only when, they appear in all
     capitals, as shown here."; notices.";

  revision 2022-03-23 2024-10-22 {
    description
      "Initial version";
    reference
      "RFC XXXX: 9684: A YANG Data Model for Challenge-Response-based Challenge-Response-Based
       Remote Attestation (CHARRA) Procedures using TPMs"; Using Trusted Platform
       Modules (TPMs)";
  }

  /*****************/
  /*   Features    */
  /*****************/

  feature tpm12 {
    description
      "This feature indicates algorithm support for the TPM 1.2 API
       as
       per Section 4.8 of TPM1.2-Structures: TPM1.2-Structures.";
    reference
      "TPM1.2-Structures: TPM Main Part 2 TPM Structures
       https://trustedcomputinggroup.org/wp-content/uploads/TPM-
       Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf"; Structures,
       https://trustedcomputinggroup.org/wp-content/uploads/
       TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
       TPM_ALGORITHM_ID values, Section 4.8";
  }

  feature tpm20 {
    description
      "This feature indicates algorithm support for the TPM 2.0 API
       as
       per Section 11.4 of Trusted Platform Module Library Part 1: Architecture. See TPM2.0-Arch:
       https://trustedcomputinggroup.org/wp-content/uploads/
       TCG_TPM2_r1p59_Part1_Architecture_pub.pdf";
       Architecture.";
    reference
      "TPM2.0-Arch: Trusted Platform Module Library Part 1:
       Architecture, https://trustedcomputinggroup.org/wp-content/
       uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf,
       Section 11.4";
  }

  /*****************/
  /*  Identities   */
  /*****************/

  identity asymmetric {
    description
      "A TCG recognized TCG-recognized asymmetric algorithm with a public and
       private key.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2,
       https://trustedcomputinggroup.org/resource/
       tcg-algorithm-registry/TCG-_Algorithm_Registry_r1p32_pub";
  }

  identity symmetric {
    description
      "A TCG recognized TCG-recognized symmetric algorithm with only a private
       key.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2";
  }

  identity hash {
    description
      "A TCG recognized TCG-recognized hash algorithm that compresses input data to
       a digest value or indicates a method that uses a hash.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2";
  }

  identity signing {
    description
      "A TCG recognized TCG-recognized signing algorithm";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2";
  }

  identity anonymous_signing {
    description
      "A TCG recognized TCG-recognized anonymous signing algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2";
  }

  identity encryption_mode {
    description
      "A TCG recognized TCG-recognized encryption mode.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2";
  }

  identity method {
    description
      "A TCG recognized TCG-recognized method such as a mask generation function.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2";
  }

  identity object_type {
    description
      "A TCG recognized TCG-recognized object type.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 2";
  }

  identity cryptoprocessor {
    description
      "Base identity identifying a crytoprocessor.";
  }

  identity tpm12 {
    if-feature "tpm12";
    base cryptoprocessor;
    description
      "Supportable by a TPM1.2."; TPM 1.2.";
    reference
      "TPM1.2-Structures:
       TPM Main Part 2 TPM Structures,
       https://trustedcomputinggroup.org/wp-content/uploads/
       TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
       TPM_ALGORITHM_ID values, Section 4.8";
  }

  identity tpm20 {
    if-feature "tpm20";
    base cryptoprocessor;
    description
      "Supportable by a TPM2."; TPM 2.0";
    reference
      "TPM2.0-Structures:
       Trusted Platform Module Library Part 2: Structures,
       https://trustedcomputinggroup.org/wp-content/uploads/
       TPM-Rev-2.0-Part-2-Structures-01.38.pdf";
  }

  identity TPM_ALG_RSA {
    if-feature "tpm12 or tpm20";
    base tpm12;
    base tpm20;
    base asymmetric;
    base object_type;
    description
      "RSA algorithm"; algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       RFC 8017. ALG_ID: 0x0001";
  }

  identity TPM_ALG_TDES {
    if-feature "tpm12";
    base tpm12;
    base symmetric;
    description
      "Block cipher with various key sizes (Triple Data Encryption
       Algorithm, commonly called Triple Data Encryption Standard)
       Note: was Was banned in TPM1.2 TPM 1.2, v94";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 18033-3. ALG_ID: 0x0003";
  }

  identity TPM_ALG_SHA1 {
    if-feature "tpm12 or tpm20";
    base hash;
    base tpm12;
    base tpm20;
    description
      "SHA1 algorithm - Deprecated due to insufficient cryptographic
       protection.  However, it is still useful for hash algorithms
       where protection is not required.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Rev1.32, Table 3 3, and
       ISO/IEC 10118-3. ALG_ID: 0x0004";
  }

  identity TPM_ALG_HMAC {
    if-feature "tpm12 or tpm20";
    base tpm12;
    base tpm20;
    base hash;
    base signing;
    description
      "Hash Message Authentication Code (HMAC) algorithm"; algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3, and
       ISO/IEC 9797-2 9797-2, and RFC2104.
       RFC 2104. ALG_ID: 0x0005";
  }

  identity TPM_ALG_AES {
    if-feature "tpm12";
    base tpm12;
    base symmetric;
    description
      "The AES algorithm with various key sizes"; sizes.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3, and
       ISO/IEC 18033-3. ALG_ID: 0x0006";
  }

  identity TPM_ALG_MGF1 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    base method;
    description
      "hash-based
      "Hash-based mask-generation function"; function.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3, and
       IEEE Std 1363-2000 1363-2000, and
       IEEE Std 1363a-2004.
       ALG_ID: 0x0007";
  }

  identity TPM_ALG_KEYEDHASH {
    if-feature "tpm20";
    base tpm20;
    base hash;
    base object_type;
    description
      "An encryption or signing algorithm using a keyed hash.  These
       may use XOR for encryption or an HMAC for signing and may
       also refer to a data object that is neither signing nor
       encrypting.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3, 3.
       ALG_ID: 0x0008";
  }

  identity TPM_ALG_XOR {
    if-feature "tpm12 or tpm20";
    base tpm12;
    base tpm20;
    base hash;
    base symmetric;
    description
      "The XOR encryption algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3.
       ALG_ID: 0x000A";
  }

  identity TPM_ALG_SHA256 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    description
      "The SHA 256 algorithm"; SHA-256 algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10118-3. ALG_ID: 0x000B";
  }

  identity TPM_ALG_SHA384 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    description
      "The SHA 384 algorithm"; SHA-384 algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10118-3. ALG_ID: 0x000C";
  }

  identity TPM_ALG_SHA512 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    description
      "The SHA 512 algorithm"; SHA-512 algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10118-3. ALG_ID: 0x000D";
  }

  identity TPM_ALG_NULL {
    if-feature "tpm20";
    base tpm20;
    description
      "NULL algorithm";
      "Null algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3.
       ALG_ID: 0x0010";
  }

  identity TPM_ALG_SM3_256 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    description
      "The SM3 ShangMi 3 (SM3) hash algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10118-3:2018. ALG_ID: 0x0012";
  }

  identity TPM_ALG_SM4 {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    description
      "SM4
      "ShangMi 4 (SM4) symmetric block cipher"; cipher.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3.
       ALG_ID: 0x0013";
  }

  identity TPM_ALG_RSASSA {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base signing;
    description
      "RFC 8017 Signature
      "Signature algorithm defined in section Section 8.2
       (RSASSAPKCS1-v1_5)";
       (RSASSA-PKCS1-v1_5) of RFC 8017.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       RFC 8017.  ALG_ID: 0x0014";
  }

  identity TPM_ALG_RSAES {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base encryption_mode;
    description
      "RFC 8017 Signature
      "Signature algorithm defined in section Section 7.2
       (RSAES-PKCS1-v1_5)";
       (RSAES-PKCS1-v1_5) of RFC 8017.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       RFC 8017. ALG_ID: 0x0015";
  }

  identity TPM_ALG_RSAPSS {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base signing;
    description
      "Padding algorithm defined in section Section 8.1 (RSASSA PSS)"; (RSASSA-PSS)
       of RFC 8017.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       RFC 8017. ALG_ID: 0x0016";
  }

  identity TPM_ALG_OAEP {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base encryption_mode;
    description
      "Padding algorithm defined in section Section 7.1 (RSASSA OAEP)"; (RSAES-OAEP)
       of RFC 8017.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       RFC 8017. ALG_ID: 0x0017";
  }

  identity TPM_ALG_ECDSA {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base signing;
    description
      "Signature algorithm using elliptic curve cryptography (ECC)"; (ECC).";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 14888-3. ALG_ID: 0x0018";
  }

  identity TPM_ALG_ECDH {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base method;
    description
      "Secret sharing using ECC"; ECC.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-56A. ALG_ID: 0x0019";
  }

  identity TPM_ALG_ECDAA {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base signing;
    base anonymous_signing;
    description
      "Elliptic-curve based
      "Elliptic-curve-based, anonymous signing scheme"; scheme.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       TCG TPM 2.0 library specification. Library. ALG_ID: 0x001A";
  }

  identity TPM_ALG_SM2 {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base signing;
    base encryption_mode;
    base method;
    description
      "SM2 - depending on context, either an elliptic-curve based,
       signature algorithm, an encryption scheme, or a key exchange
       protocol";
       protocol.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3.
       ALG_ID: 0x001B";
  }

  identity TPM_ALG_ECSCHNORR {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base signing;
    description
      "Elliptic-curve based
      "Elliptic-curve-based Schnorr signature"; signature.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3.
       ALG_ID: 0x001C";
  }

  identity TPM_ALG_ECMQV {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base method;
    description
      "Two-phase elliptic-curve key"; key.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-56A. ALG_ID: 0x001D";
  }

  identity TPM_ALG_KDF1_SP800_56A {
    if-feature "tpm20";
    base tpm20;
    base hash;
    base method;
    description
      "Concatenation key derivation function"; function.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-56A  (approved alternative1) section Section 5.8.1.
       ALG_ID: 0x0020";
  }

  identity TPM_ALG_KDF2 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    base method;
    description
      "Key derivation function"; function.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       IEEE 1363a-2004 KDF2 section 1363a-2004, KDF2, Section 13.2. ALG_ID: 0x0021";
  }

  identity TPM_ALG_KDF1_SP800_108 {
    base TPM_ALG_KDF2;
    description
      "A key derivation method"; method.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32,  Table 3 and
       NIST SP800-108 - SP800-108, Section 5.1 5.1, KDF. ALG_ID: 0x0022";
  }

  identity TPM_ALG_ECC {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base object_type;
    description
      "Prime field ECC"; ECC.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 15946-1. ALG_ID: 0x0023";
  }

  identity TPM_ALG_SYMCIPHER {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base object_type;
    description
      "Object type for a symmetric block cipher"; cipher.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       TCG TPM 2.0 library specification. Library. ALG_ID: 0x0025";
  }

  identity TPM_ALG_CAMELLIA {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    description
      "The Camellia algorithm"; algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 18033-3. ALG_ID: 0x0026";
  }

  identity TPM_ALG_SHA3_256 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    description
      "ISO/IEC 10118-3 - the SHA 256 algorithm"; SHA-256 algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST PUB FIPS 202. ALG_ID: 0x0027";
  }

  identity TPM_ALG_SHA3_384 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    description
      "The SHA 384 algorithm"; SHA-384 algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST PUB FIPS 202. ALG_ID: 0x0028";
  }

  identity TPM_ALG_SHA3_512 {
    if-feature "tpm20";
    base tpm20;
    base hash;
    description
      "The SHA 512 algorithm"; SHA-512 algorithm.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST PUB FIPS 202. ALG_ID: 0x0029";
  }

  identity TPM_ALG_CMAC {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base signing;
    description
      "block
      "Block Cipher-based Message Authentication Code (CMAC)"; (CMAC).";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 9797-1:2011 9797-1:2011, Algorithm 5. ALG_ID: 0x003F";
  }

  identity TPM_ALG_CTR {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base encryption_mode;
    description
      "Counter mode"; mode.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10116. ALG_ID: 0x0040";
  }

  identity TPM_ALG_OFB {
    base tpm20;
    base symmetric;
    base encryption_mode;
    description
      "Output Feedback mode"; mode.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10116. ALG_ID: 0x0041";
  }

  identity TPM_ALG_CBC {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base encryption_mode;
    description
      "Cipher Block Chaining mode"; mode.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10116. ALG_ID: 0x0042";
  }

  identity TPM_ALG_CFB {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base encryption_mode;
    description
      "Cipher Feedback mode"; mode.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10116. ALG_ID: 0x0043";
  }

  identity TPM_ALG_ECB {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base encryption_mode;
    description
      "Electronic Codebook mode"; mode.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       ISO/IEC 10116. ALG_ID: 0x0044";
  }

  identity TPM_ALG_CCM {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base signing;
    base encryption_mode;
    description
      "Counter with Cipher Block Chaining-Message Chaining--Message Authentication
       Code (CCM)"; (CCM).";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-38C. ALG_ID: 0x0050";
  }

  identity TPM_ALG_GCM {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base signing;
    base encryption_mode;
    description
      "Galois/Counter Mode (GCM)"; (GCM).";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-38D. ALG_ID: 0x0051";
  }

  identity TPM_ALG_KW {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base signing;
    base encryption_mode;
    description
      "AES Key Wrap (KW)"; (KW).";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-38F. ALG_ID: 0x0052";
  }

  identity TPM_ALG_KWP {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base signing;
    base encryption_mode;
    description
      "AES Key Wrap with Padding (KWP)"; (KWP).";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-38F. ALG_ID: 0x0053";
  }

  identity TPM_ALG_EAX {
    if-feature "tpm20";
    base tpm20;
    base symmetric;
    base signing;
    base encryption_mode;
    description
      "Authenticated-Encryption Mode"; Mode.";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       NIST SP800-38F. ALG_ID: 0x0054";
  }

  identity TPM_ALG_EDDSA {
    if-feature "tpm20";
    base tpm20;
    base asymmetric;
    base signing;
    description
      "Edwards-curve Digital Signature Algorithm (PureEdDSA)"; (PureEdDSA).";
    reference
      "TCG-Algos:TCG
      "TCG-Algos: TCG Algorithm Registry Rev1.32 Registry, Rev1.32, Table 3 3, and
       RFC 8032. ALG_ID: 0x0060";
  }
}
&lt;CODE ENDS&gt;
</sourcecode>
]]></sourcecode>
            <t>Note that not all cryptographic functions are required for use by <tt>ietf-tpm-remote-attestation.yang</tt>. ietf-tpm-remote-attestation.yang. However, the full definition of Table 3 of <xref target="TCG-Algos"/> will allow use by additional YANG specifications.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document registers the following namespace URIs in the
<xref target="xml-registry"/> as target="XML-Registry"/> per <xref target="RFC3688"/>:</t>
      <dl>
        <dt>URI:</dt>
        <dd>
          <t>urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation
</t>
          <dl>
            <dt>Registrant Contact:</dt>
            <dd>
              <t>The IESG.</t>
            </dd>
            <dt>XML:</dt>
            <dd>
              <t>N/A; the requested URI is an XML namespace.</t>
            </dd>
          </dl>
        </dd>
        <dt>URI:</dt>
        <dd>
          <t>urn:ietf:params:xml:ns:yang:ietf-tcg-algs
</t>
          <dl>
            <dt>Registrant Contact:</dt>
            <dd>
              <t>The IESG.</t>
            </dd>
            <dt>XML:</dt>
            <dd>
              <t>N/A; the requested URI is an XML namespace.</t>
            </dd>
          </dl>
        </dd>
      </dl>
      <t>This document registers the following YANG modules in the
registry <xref target="yang-parameters"/> as target="YANG-Parameters"/> per Section 14 of <xref target="RFC6020"/>:</t> target="RFC6020" section="14" sectionFormat="of"/>:</t>
      <dl>
        <dt>Name:</dt>
        <dd>
          <t>ietf-tpm-remote-attestation
</t>
          <dl>
            <dt>Namespace:</dt>
            <dd>
              <t>urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation</t>
            </dd>
            <dt>Prefix:</dt>
            <dd>
              <t>tpm</t>
            </dd>
            <dt>Reference:</dt>
            <dd>
              <t>draft-ietf-rats-yang-tpm-charra (RFC form)</t>
            </dd>
          </dl>
        </dd>
        <dt>Name:</dt>
        <dd>
          <t>ietf-tcg-algs
</t>
          <dl>
            <dt>Namespace:</dt>
            <dd>
              <t>urn:ietf:params:xml:ns:yang:ietf-tcg-algs</t>
            </dd>
            <dt>Prefix:</dt>
            <dd>
              <t>taa</t>
            </dd>
            <dt>Reference:</dt>
            <dd>
              <t>draft-ietf-rats-yang-tpm-charra (RFC form)</t>
            </dd>
          </dl>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
<!-- [rfced] Section 4. The original Security Considerations section was missing paragraphs 2, 4, and 5 that are specified in the template found at <https://wiki.ietf.org/group/ops/yang-security-guidelines>. We have added paragraph 2. Please let us know if paragraphs 4 and 5 should also be added. -->
      <t>The YANG module ietf-tpm-remote-attestation.yang specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.  The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) <xref target="RFC6242"/>.  The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t>
      <t> The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
</t>
      <t>There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., <em>config true</em>, which is the default).  These data nodes may be considered sensitive or vulnerable in some network environments.  Write operations (e.g., <em>edit-config</em>) to these data nodes without proper protection can have a negative effect on network operations.  These are the subtrees and data nodes as well as their sensitivity/vulnerability:</t>
      <dl>
        <dt>Container '/rats-support-structures/attester-supported-algos':</dt>
        <dd>
          <t>'tpm12-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric-signing', and 'tpm20-hash'. All could be populated with algorithms that are not supported by the underlying physical TPM installed by the equipment vendor.  A vendor should restrict the ability to configure unsupported algorithms.</t>
        </dd>
        <dt>Container: '/rats-support-structures/tpms':</dt>
        <dd>
          <t>'name': Although shown as 'rw', it is system generated. Therefore, it should not be possible for an operator to add or remove a TPM from the configuration.</t>
        </dd>
        <dt/>
        <dd>
          <t>'tpm20-pcr-bank': It is possible to configure PCRs for extraction which that are not being extended by system software. software for extraction.  This could unnecessarily use TPM resources.</t>
        </dd>
        <dt/>
        <dd>
          <t>'certificates': It is possible to provision a certificate which that does not correspond to an Attestation Identity Key (AIK) AIK within the TPM 1.2, or to an Attestation Key (AK) within the TPM 2.0 2.0, respectively. In such a case, calls to an RPC requesting this specific certificate could result in either no response or a response for from an unexpected TPM.</t>
        </dd>
        <dt>RPC 'tpm12-challenge-response-attestation':</dt>
        <dd>
          <t>The receiver of the RPC response must verify that the certificate is for an active AIK, i.e., the certificate has been confirmed by a third party as being able to support Attestation on the targeted TPM 1.2.</t>
        </dd>
        <dt>RPC 'tpm20-challenge-response-attestation':</dt>
        <dd>
          <t>The receiver of the RPC response must verify that the certificate is for an active AK, i.e., the private key confirmation of the quote signature within the RPC response has been confirmed by a third party to belong to an entity legitimately able to perform Attestation on the targeted TPM 2.0.</t>
        </dd>
        <dt>RPC 'log-retrieval':</dt>
        <dd>
          <t>Requesting a large volume of logs from the Attester could require significant system resources and create a denial of service.</t>
        </dd>
      </dl>
      <t>Information collected through the RPCs above could reveal that specific versions of software and configurations of endpoints that could identify vulnerabilities on those systems.  Therefore, RPCs should be protected by NACM <xref target="RFC8341"/> with a default setting of deny-all to limit the extraction of attestation data by only authorized Verifiers.</t>
      <t>For the YANG module ietf-tcg-algs.yang, please use care when selecting specific algorithms.  The introductory section of <xref target="TCG-Algos"/> highlights that some algorithms should be considered legacy, and recommends implementers and adopters diligently evaluate available information such as governmental, industrial, and academic research before selecting an algorithm for use.</t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-rats-reference-interaction-models" to="RATS-Interaction-Models"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2104">
          <front>
            <title>HMAC: Keyed-Hashing for Message Authentication</title>
            <seriesInfo name="DOI" value="10.17487/RFC2104"/>
            <seriesInfo name="RFC" value="2104"/>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="M. Bellare" initials="M." surname="Bellare"/>
            <author fullname="R. Canetti" initials="R." surname="Canetti"/>
            <date month="February" year="1997"/>
            <abstract>
              <t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6020"/>
            <seriesInfo name="RFC" value="6020"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <seriesInfo name="DOI" value="10.17487/RFC3688"/>
            <seriesInfo name="RFC" value="3688"/>
            <seriesInfo name="BCP" value="81"/>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <seriesInfo name="DOI" value="10.17487/RFC6991"/>
            <seriesInfo name="RFC" value="6991"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <date month="July" year="2013"/>
            <abstract>
              <t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8348.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.8040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6933.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.8341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>

<!-- [I-D.ietf-netconf-keystore] now RFC 6021.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8348">
          <front>
            <title>A YANG Data Model for Hardware Management</title>
            <seriesInfo name="DOI" value="10.17487/RFC8348"/>
            <seriesInfo name="RFC" value="8348"/>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="J. Dong" initials="J." surname="Dong"/>
            <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document defines a YANG data model for the management of hardware on a single server.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6241"/>
            <seriesInfo name="RFC" value="6241"/>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes 9642 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9642.xml"/>
<!-- [I-D.ietf-rats-architecture] now RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC8040"/>
            <seriesInfo name="RFC" value="8040"/>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined 9334 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/>

<!-- [I-D.ietf-rats-tpm-based-network-device-attest] in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6242">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6242"/>
            <seriesInfo name="RFC" value="6242"/>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>This REF; companion document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference> 9683 -->
<reference anchor="RFC6933"> anchor='RFC9683' target='https://www.rfc-editor.org/info/rfc9683'>
  <front>
            <title>Entity MIB (Version 4)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6933"/>
            <seriesInfo name="RFC" value="6933"/>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
            <author fullname="J. Quittek" initials="J." surname="Quittek"/>
            <author fullname="M. Chandramouli" initials="M." surname="Chandramouli"/>
            <date month="May" year="2013"/>
            <abstract>
              <t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple
    <title>TPM-based Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <seriesInfo name="DOI" value="10.17487/RFC8446"/>
            <seriesInfo name="RFC" value="8446"/> Device Remote Integrity Verification</title>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <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 the Internet in a way 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>
        </reference>
        <reference anchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <seriesInfo name="DOI" value="10.17487/RFC8341"/>
            <seriesInfo name="RFC" value="8341"/>
            <seriesInfo name="STD" value="91"/> initials='G' surname='Fedorkow' fullname='Guy Fedorkow'>
      <organization />
    </author>
    <author fullname="A. Bierman" initials="A." surname="Bierman"/> initials='E' surname='Voit' fullname='Eric Voit'>
      <organization />
    </author>
    <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> initials='J' surname='Fitzgerald-McKay' fullname='Jessica Fitzgerald-McKay'>
      <organization />
    </author>
    <date month="March" year="2018"/>
            <abstract>
              <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t>This document obsoletes RFC 6536.</t>
            </abstract> year='2024' month='October' />
  </front>
        </reference>
        <reference anchor="RFC8032">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8032"/>
  <seriesInfo name="RFC" value="8032"/>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title> value="9683"/>
  <seriesInfo name="DOI" value="10.17487/RFC8017"/>
            <seriesInfo name="RFC" value="8017"/>
            <author fullname="K. Moriarty" initials="K." role="editor" surname="Moriarty"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
            <author fullname="A. Rusch" initials="A." surname="Rusch"/>
            <date month="November" year="2016"/>
            <abstract>
              <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying value="10.17487/RFC9683"/>
</reference>

<!-- [rfced] Normative References. FYI, the schemes.</t>
              <t>This document represents a republication date of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred [TPM1.2] was updated to the IETF.</t>
              <t>This document also obsoletes RFC 3447.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC9334">
          <front>
            <title>Remote ATtestation procedureS (RATS) Architecture</title>
            <seriesInfo name="DOI" value="10.17487/RFC9334"/>
            <seriesInfo name="RFC" value="9334"/>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="N. Smith" initials="N." surname="Smith"/>
            <author fullname="W. Pan" initials="W." surname="Pan"/>
            <date month="January" year="2023"/>
            <abstract>
              <t>In network protocol exchanges, it is often useful for one end of a communication "01 March 2011" from "2 October 2003" to know whether match 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. It provides a model that is neutral toward processor architectures, information provided at the content of Claims, and protocols.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-netconf-keystore">
          <front>
            <title>A YANG Data Model for a Keystore and Keystore Operations</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-keystore-35"/>
            <author fullname="Kent Watsen" initials="K." surname="Watsen">
              <organization>Watsen Networks</organization>
            </author>
            <date day="16" month="March" year="2024"/>
            <abstract>
              <t>   This document presents a YANG module called "ietf-keystore" that
   enables centralized configuration of both symmetric and asymmetric
   keys.  The secret value for both key types may be encrypted or
   hidden.  Asymmetric keys may be associated with certificates.
   Notifications are sent when certificates target URL (https://trustedcomputinggroup.org/resource/tpm-main-specification/). Please let us know if any changes are about to expire.

              </t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-rats-tpm-based-network-device-attest">
          <front>
            <title>TPM-based Network Device Remote Integrity Verification</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-rats-tpm-based-network-device-attest-14"/>
            <author fullname="Guy Fedorkow" initials="G." surname="Fedorkow">
              <organization>Juniper Networks, Inc.</organization>
            </author>
            <author fullname="Eric Voit" initials="E." surname="Voit">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Jessica Fitzgerald-McKay" initials="J." surname="Fitzgerald-McKay">
              <organization>National Security Agency</organization>
            </author>
            <date day="22" month="March" year="2022"/>
            <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 [TPM1.2], [TPM2.0], as defined by
   the necessary.

Original:
   [TPM1.2]   TCG, "TPM 1.2 Main Specification", 2 October 2003,
              <https://trustedcomputinggroup.org/resource/tpm-main-
              specification/>.

Current:
   [TPM1.2]   Trusted Computing Group (TCG)), or equivalent hardware
   implementations that include the protected capabilities, as provided
   by TPMs.

              </t>
            </abstract>
          </front>
        </reference> Group, "TPM 1.2 Main Specification", TPM
              Main Specification Level 2 Version 1.2, Revision 116, 1
              March 2011, <https://trustedcomputinggroup.org/resource/
              tpm-main-specification/>.
-->

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

        <reference anchor="TPM1.2-Structures" target="https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf">
          <front>
            <title>TPM Main Part 2 TPM Structures</title>
            <author>
              <organization/>
              <organization>Trusted Computing Group</organization>
            </author>
            <date>n.d.</date>
            <date year="2011" month="March" day="01"/>
          </front>
          <refcontent>TPM Main Specification Level 2 Version 1.2, Revision 116</refcontent>
        </reference>

        <reference anchor="TPM1.2-Commands" target="https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf">
          <front>
            <title>TPM Main Part 3 Commands</title>
            <author>
              <organization/>
              <organization>Trusted Computing Group</organization>
            </author>
            <date>n.d.</date>
            <date year="2011" month="March" day="01"/>
          </front>
          <refcontent>TPM Main Specification Level 2 Version 1.2, Revision 116</refcontent>
        </reference>

<!-- [rfced]  Normative References. FYI, the date of [TPM2.0] was updated to "March 2024" from "15 March 2013" to match the information provided at the target URL <https://trustedcomputinggroup.org/resource/tpm-library-specification/>. Please let us know if any changes are necessary.

Original:
   [TPM2.0]   TCG, "TPM 2.0 Library Specification", 15 March 2013,
              <https://trustedcomputinggroup.org/resource/tpm-library-
              specification/>.

Current:
   [TPM2.0]   Trusted Computing Group, "TPM 2.0 Library", Trusted
              Platform Module Library Specification, Family "2.0", Level
              00, Revision 01.83, March 2024,
              <https://trustedcomputinggroup.org/resource/tpm-library-
              specification/>.
-->
        <reference anchor="TPM2.0" target="https://trustedcomputinggroup.org/resource/tpm-library-specification/">
          <front>
            <title>TPM 2.0 Library</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2024" month="March"/>
          </front>
          <refcontent>Trusted Platform Module Library Specification</title>
            <author initials="" surname="TCG" fullname="Trusted Specification, Family "2.0", Level 00, Revision 01.83</refcontent>
        </reference>

<!-- [rfced]  Normative References. There is an updated version of [TPM2.0-Arch] released on 25 January 2024 (available here:
https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf). May we update [TPM2.0-Arch] to the most recent version?

Original:
   [TPM2.0-Arch]
              Trusted Computing Group">
              <organization/> Group, "Trusted Platform Module Library
              Part 1: Architecture", Family "2.0", Level 00, Revision
              01.59, 8 November 2019,
              <https://trustedcomputinggroup.org/wp-content/uploads/
              TCG_TPM2_r1p59_Part1_Architecture_pub.pdf>.

Perhaps:
   [TPM2.0-Arch]
              Trusted Computing Group, "Trusted Platform Module Library
              Part 1: Architecture", Family "2.0", Level 00, Revision
              01.83, 25 January 2024,
              <https://trustedcomputinggroup.org/wp-content/uploads/
              TPM-2.0-1.83-Part-1-Architecture.pdf>.
-->

<!-- XML for newest version of [TPM2.0-Arch]

<reference anchor="TPM2.0-Arch"
           target="https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf">
  <front>
    <title>Trusted Platform Module Library Part 1: Architecture</title>
    <author>
      <organization>Trusted Computing Group</organization>
    </author>
    <date year="2013" month="March" day="15"/> year="2024" month="January" day="25"/>
  </front>
  <refcontent>Family "2.0", Level 00, Revision 01.83</refcontent>
</reference>
-->
        <reference anchor="TPM2.0-Arch" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf">
          <front>
             <title>Trusted Platform Module Library - Part 1: Architecture</title>
            <author>
              <organization/>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2019" month="November" day="8"/>
          </front>
          <refcontent>Family "2.0", Level 00, Revision 01.59</refcontent>
        </reference>

<!-- [rfced]  Normative References. An updated version of [TPM2.0-Structures] was released on 25 January 2024 (available here:
https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf). May we update [TPM2.0-Structures] to the most recent version?

Original:
   [TPM2.0-Structures]
              Trusted Computing Group, "Trusted Platform Module Library
              Part 2: Structures", Family "2.0", Level 00, Revision
              01.38, 29 December 2016,
              <https://trustedcomputinggroup.org/wp-content/uploads/TPM-
              Rev-2.0-Part-2-Structures-01.38.pdf>.

Perhaps:
   [TPM2.0-Structures]
              Trusted Computing Group, "Trusted Platform Module Library
              Part 2: Structures", Family "2.0", Level 00, Revision
              01.83, 25 January 2024,
              <https://trustedcomputinggroup.org/wp-content/uploads/TPM-
              2.0-1.83-Part-2-Structures.pdf>.
-->

<!-- XML for newest version of [TPM2.0-Structures]

<reference anchor="TPM2.0-Structures"
           target="https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf">
  <front>
    <title>Trusted Platform Module Library Part 2: Structures</title>
    <author>
      <organization>Trusted Computing Group</organization>
    </author>
            <date>n.d.</date>
    <date year="2024" month="January" day="25"/>
  </front>
  <refcontent>Family "2.0", Level 00, Revision 01.83</refcontent>
</reference>
-->
        <reference anchor="TPM2.0-Structures" target="https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf">
          <front>
            <title>Trusted Platform Module Library - Part 2: Structures</title>
            <author>
              <organization/>
              <organization>Trusted Computing Group</organization>
            </author>
            <date>n.d.</date>
            <date day="29" month="December" year="2016"/>
          </front>
          <refcontent>Family "2.0", Level 00, Revision 01.38</refcontent>
        </reference>

        <reference anchor="TPM2.0-Key" target="https://trustedcomputinggroup.org/wp-content/uploads/TPM-2p0-Keys-for-Device-Identity-and-Attestation_v1_r12_pub10082021.pdf">
          <front>
            <title>TPM 2.0 Keys for Device Identity and Attestation, Rev12</title>
            <author initials="" surname="TCG" fullname="Trusted Attestation</title>
            <author>
              <organization>Trusted Computing Group">
              <organization/> Group</organization>
            </author>
            <date year="2021" month="October" day="08"/>
          </front>
          <refcontent>Version 1.00, Revision 12</refcontent>
        </reference>

<!-- [rfced]  Normative References. An updated version of [TCG-Algos] was released on 24 August 2023 (available here:
<https://trustedcomputinggroup.org/wp-content/uploads/TCG-Algorithm-Registry-Revision-1.34_pub-1.pdf>). May we update [TCG-Algos] to the most recent version?

Original:
   [TCG-Algos]
              Trusted Computing Group, "TCG Algorithm Registry", Family
              "2.0" Level 00 Revision 01.32, 25 June 2020,
              <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
              _Algorithm_Registry_r1p32_pub.pdf>.

Perhaps:
   [TCG-Algos]
              Trusted Computing Group, "TCG Algorithm Registry", Family
              "2.0" Level 00 Revision 01.34, 24 August 2023,
              <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
              _Algorithm_Registry-Revision-1.34_pub-1.pdf>.
-->
<!-- XML for updated version of [TCG-Algos]

        <reference anchor="TCG-Algos" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG-Algorithm-Registry-Revision-1.34_pub-1.pdf">
          <front>
            <title>TCG Algorithm Registry</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2023" month="August" day="24"/>
          </front>
          <refcontent>Family "2.0" Level 00 Revision 01.34</refcontent>
        </reference>
-->
        <reference anchor="TCG-Algos" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf">
          <front>
            <title>TCG Algorithm Registry</title>
            <author>
              <organization/>
              <organization>Trusted Computing Group</organization>
            </author>
            <date>n.d.</date>
            <date year="2020" month="June" day="25"/>
          </front>
          <refcontent>Family "2.0" Level 00 Revision 01.32</refcontent>
        </reference>

<!-- [rfced] Normative References. [BIOS-Log-Event-Type] and [BIOS-Log] reference different versions of the same TCG specification (see <https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/>). Is this intentional? If not, may we consolidate these two references into one reference?

The most current version of "TCG PC Client Platform Firmware Profile Specification" was published on 4 December 2023 (see: https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-2.pdf).  May we update these references to the most current version?

Original:
   *  'bios': Indicates that the device supports the retrieval of BIOS/
      UEFI event logs. [bios-log]
   ...
       leaf-list event-data {
         type binary;
         description
           "The event data.  This is a binary structure
            of size 'event-size'. For more on what
            might be recorded within this object
            see [bios-log] Section 9 which details
            viable events which might be recorded.";

   [bios-log] "TCG PC Client Platform Firmware Profile Specification,
              Section 9.4.5.2", n.d.,
              <https://trustedcomputinggroup.org/wp-content/uploads/PC-C
              lientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf
              >.

       leaf event-type {
         type uint32;
         description
           "BIOS Log Event Type:
            https://trustedcomputinggroup.org/wp-content/uploads/
            TCG_PCClient_PFP_r1p05_v23_pub.pdf  Section 10.4.1";

   [BIOS-Log-Event-Type]
              "TCG PC Client Platform Firmware Profile Specification",
              n.d., <https://trustedcomputinggroup.org/wp-
              content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf>.
-->
        <reference anchor="BIOS-Log-Event-Type" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf">
          <front>
            <title>TCG PC Client Platform Firmware Profile Specification</title>
            <author>
              <organization/>
              <organization>Trusted Computing Group</organization>
            </author>
            <date>n.d.</date>
            <date day="7" month="May" year="2017"/>
          </front>
          <refcontent>Family "2.0" Level 00 Version 1.05 Revision 23</refcontent>
        </reference>

        <reference anchor="ISO-IEC-9797-1" target="https://www.iso.org/standard/50375.html">
          <front>
            <title>Message
            <title>Information technology - Security techniques - Message Authentication Codes (MACs) - Part 1: Mechanisms using a block cipher</title>
            <author>
              <organization>ISO/IEC</organization>
            </author>
            <date month="November" year="2011"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9797-1:2011"/>
          <refcontent>Edition 2</refcontent>
        </reference>

<!-- [rfced]  Normative References. ISO/IEC 9797-2:2011 <https://www.iso.org/standard/51618.html> has been withdrawn by ISO and updated by ISO/IEC 9797-2:2021 <https://www.iso.org/standard/75296.html>. May we replace ISO/IEC 9797-1:2011</title> 9797-2:2011 with ISO/IEC 9797-2:2021?  -->

<!--  Updated XML for [ISO-IEC-9797-2]

        <reference anchor="ISO-IEC-9797-2" target="https://www.iso.org/standard/75296.html">
          <front>
            <title>Information security - Message authentication codes (MACs) - Part 2:
      Mechanisms using a dedicated hash-function</title>
            <author>
              <organization/>
              <organization>ISO/IEC</organization>
            </author>
            <date>n.d.</date>
            <date month="June" year="2021"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9797-2:2021"/>
          <refcontent>Edition 3</refcontent>
        </reference>
-->
        <reference anchor="ISO-IEC-9797-2" target="https://www.iso.org/standard/51618.html">
          <front>
            <title>Message Authentication Codes
            <title>Information technology - Security techniques - Message authentication codes (MACs) - ISO/IEC 9797-2:2011</title> Part 2:
      Mechanisms using a dedicated hash-function</title>
            <author>
              <organization/>
              <organization>ISO/IEC</organization>
            </author>
            <date>n.d.</date>
            <date month="November" year="2011"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9797-2:2011"/>
          <refcontent>Edition 2</refcontent>
        </reference>

        <reference anchor="ISO-IEC-10116" target="https://www.iso.org/standard/64575.html">
          <front>
            <title>ISO/IEC 10116:2017
            <title>Information technology - Information technology</title> Security techniques - Modes of operation for an n-bit block cipher</title>
            <author>
              <organization/>
              <organization>ISO/IEC</organization>
            </author>
            <date>n.d.</date>
            <date month="July" year="2017"/>
          </front>
          <seriesInfo name="ISO/IEC" value="10116:2017"/>
          <refcontent>Edition 4</refcontent>
        </reference>

        <reference anchor="ISO-IEC-10118-3" target="https://www.iso.org/standard/67116.html">
          <front>
            <title>Dedicated hash-functions
            <title>IT Security techniques - ISO/IEC 10118-3:2018</title> Hash-functions - Part 3: Dedicated hash-functions</title>
            <author>
              <organization/>
              <organization>ISO/IEC</organization>
            </author>
            <date>n.d.</date>
            <date month="October" year="2018"/>
          </front>
          <seriesInfo name="ISO/IEC" value="10118-3:2018"/>
          <refcontent>Edition 4</refcontent>
        </reference>

        <reference anchor="ISO-IEC-14888-3" target="https://www.iso.org/standard/76382.html">
          <front>
            <title>ISO/IEC 14888-3:2018
            <title>Security techniques - Digital signatures with appendix</title> appendix - Part 3: Discrete logarithm based mechanisms</title>
            <author>
              <organization/>
              <organization>ISO/IEC</organization>
            </author>
            <date>n.d.</date>
            <date month="November" year="2018"/>
          </front>
          <seriesInfo name="ISO/IEC" value="14888-3:2018"/>
          <refcontent>Edition 4</refcontent>
        </reference>

        <reference anchor="ISO-IEC-15946-1" target="https://www.iso.org/standard/65480.html">
          <front>
            <title>ISO/IEC 15946-1:2016
            <title>Information technology - Information technology</title> Security techniques - Cryptographic techniques based on elliptic curves - Part 1: General</title>
            <author>
              <organization/>
              <organization>ISO/IEC</organization>
            </author>
            <date>n.d.</date>
            <date month="July" year="2016"/>
          </front>
          <seriesInfo name="ISO/IEC" value="15946-1:2016"/>
          <refcontent>Edition 3</refcontent>
        </reference>

        <reference anchor="ISO-IEC-18033-3" target="https://www.iso.org/standard/54531.html">
          <front>
            <title>ISO/IEC 18033-3:2010
            <title>Information technology - Security techniques - Encryption algorithms</title> algorithms - Part 3: Block ciphers</title>
            <author>
              <organization/>
              <organization>ISO/IEC</organization>
            </author>
            <date>n.d.</date>
            <date month="December" year="2010"/>
          </front>
          <seriesInfo name="ISO/IEC" value="18033-3:2010"/>
          <refcontent>Edition 2</refcontent>
        </reference>

<!-- [rfced]  Normative References. FYI, we updated the target URL for [IEEE-Std-1363-2000] to https://ieeexplore.ieee.org/document/891000. This matches the DOI URL for this document. Please let us know if any changes are necessary.  -->

        <reference anchor="IEEE-Std-1363-2000" target="https://standards.ieee.org/standard/1363-2000.html"> target="https://ieeexplore.ieee.org/document/891000">
          <front>
            <title>IEEE 1363-2000 - IEEE Standard Specifications for Public-Key Cryptography</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date>n.d.</date>
            <date month="August" year="2000"/>
          </front>
          <seriesInfo name="IEEE Std" value="1363-2000"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2000.92292"/>
        </reference>

<!-- [rfced]  Normative References. FYI, we updated the target URL for [IEEE-Std-1363a-2004] to https://ieeexplore.ieee.org/document/1335427. This matches the DOI URL for this document. Please let us know if any changes are necessary.  -->

        <reference anchor="IEEE-Std-1363a-2004" target="https://ieeexplore.ieee.org/document/1335427">
          <front>
            <title>1363a-2004 - IEEE
            <title>IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques</title>
            <author>
              <organization/>
              <organization>IEEE</organization>
            </author>
            <date>n.d.</date>
            <date month="September" year="2004"/>
          </front>
          <seriesInfo name="IEEE Std" value="1363a-2004"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2004.94612"/>
        </reference>

        <reference anchor="NIST-PUB-FIPS-202" anchor="NIST-FIPS-202" target="https://csrc.nist.gov/publications/detail/fips/202/final">
          <front>
            <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
            <author>
              <organization/>
              <organization>NIST</organization>
            </author>
            <date>n.d.</date>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="NIST FIPS" value="202"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
        </reference>

        <reference anchor="NIST-SP800-38C" target="https://csrc.nist.gov/publications/detail/sp/800-38c/final">
          <front>
            <title>Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality</title>
            <author>
              <organization/>
            <author fullname="Morris Dworkin">
            	<organization>NIST</organization>
            </author>
            <date>n.d.</date>
            <date month="July" year="2007"/>
          </front>
          <seriesInfo name="NIST SP" value="800-38C"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38C"/>
        </reference>

        <reference anchor="NIST-SP800-38D" target="https://csrc.nist.gov/publications/detail/sp/800-38d/final">
          <front>
            <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
            <author>
              <organization/>
            <author fullname="Morris Dworkin">
              <organization>NIST</organization>
            </author>
            <date>n.d.</date>
            <date month="November" year="2007"/>
          </front>
          <seriesInfo name="NIST SP" value="800-38D"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
        </reference>

        <reference anchor="NIST-SP800-38F" target="https://csrc.nist.gov/publications/detail/sp/800-38f/final">
          <front>
            <title>Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping</title>
            <author>
              <organization/>
            <author fullname="Morris Dworkin">
              <organization>NIST</organization>
            </author>
            <date>n.d.</date>
            <date month="December" year="2012"/>
          </front>
          <seriesInfo name="NIST SP" value="800-38F"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38F"/>
        </reference>

        <reference anchor="NIST-SP800-56A" target="https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final">
          <front>
            <title>Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
            <author fullname="Elaine Barker"/>
            <author fullname="Lily Chen"/>
            <author fullname="Allen Roginsky"/>
            <author fullname="Apostol Vassilev"/>
            <author fullname="Richard Davis"/>
            <date month="April" year="2018"/>
          </front>
          <seriesInfo name="NIST SP" value="800-56A Rev. 3"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
        </reference>

<!-- [rfced] Normative References. NIST SP800-108 (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf) has been withdrawn by NIST and updated by NIST SP800-108r1 (https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final). May we replace NIST SP800-108 with NIST SP800-108r1?  -->

        <reference anchor="NIST-SP800-108" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf">
          <front>
            <title>Recommendation for Key Derivation Using Pseudorandom Functions (Revised)</title>
            <author fullname="Lily Chen"/>
            <date day="1" month="October" year="2009"/>
          </front>
          <seriesInfo name="NIST SP" value="800-108"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-108"/>
        </reference>

<!-- Note to PE: Updated XML for [NIST-SP800-108]

        <reference anchor="NIST-SP800-108" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf">
          <front>
            <title>Recommendation for Key Derivation Using Pseudorandom Functions</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
            <author fullname="Lily Chen"/>
            <date month="February" year="2024"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-108r1-upd1"/>
          <seriesInfo name="NIST SP" value="800-108r1-upd1"/>
        </reference>

-->

<!-- [rfced] Normative References. FYI, to avoid reader confusion, we have removed the section information from [BIOS-Log] and [CEL] because other sections of [BIOS-Log] and [CEL] are also referenced in the document. Please let us know if any changes are necessary.

Original
   [bios-log] "TCG PC Client Platform Firmware Profile Specification,
              Section 9.4.5.2", n.d.,
              <https://trustedcomputinggroup.org/wp-content/uploads/PC-C
              lientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf
              >.

   [cel]      "Canonical Event Log Format, Section 4.3", n.d.,
              <https://trustedcomputinggroup.org/wp-content/uploads/
              TCG_IWG_CEL_v1_r0p41_pub.pdf>.

Current:
   [BIOS-Log] Trusted Computing Group, "TCG PC Client Platform Firmware
              Profile Specification", Family "2.0" Level 00 Revision
              1.03 Version 51, 1 May 2017,
              <https://trustedcomputinggroup.org/wp-content/uploads/PC-C
              lientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf
              >.

   [CEL]      Trusted Computing Group, "Canonical Event Log Format",
              Version 1.0 Revision 0.41, 25 February 2022,
              <https://trustedcomputinggroup.org/wp-content/uploads/
              TCG_IWG_CEL_v1_r0p41_pub.pdf>.
-->
        <reference anchor="bios-log" anchor="BIOS-Log" target="https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf">
          <front>
            <title>TCG PC Client Platform Firmware Profile Specification, Section 9.4.5.2</title> Specification</title>
            <author>
              <organization/>
              <organization>Trusted Computing Group</organization>
            </author>
            <date>n.d.</date>
            <date day="1" month="May" year="2017"/>
          </front>
          <refcontent>Family "2.0" Level 00 Revision 1.03 Version 51</refcontent>
        </reference>

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

<!-- [rfced] Normative References. A new version of [UEFI-Secure-Boot] was published on 29 August 2022 (available here: <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf>). May we update this reference to the newest version?  -->
        <reference anchor="UEFI-Secure-Boot" target="https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf">
          <front>
            <title>Unified Extensible Firmware Interface (UEFI) Specification Version 2.9 (March 2021), Section 32.1 (Secure Boot)</title> Specification</title>
            <author>
              <organization/>
              <organization>Unified Extensible Firmware Interface (UEFI) Forum, Inc.</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used 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 for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract> year="2021"/>
          </front>
          <refcontent>Section 32.1: Secure Boot</refcontent>
          <refcontent>Version 2.9</refcontent>
        </reference>

<!-- [rfced] Note to PE: XML for most current version of [UEFI-Secure-Boot

        <reference anchor="RFC8174"> anchor="UEFI-Secure-Boot" target="https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <title>Unified Extensible Firmware Interface (UEFI) Specification</title>
            <author>
              <organization>Unified Extensible Firmware Interface (UEFI) Forum, Inc.</organization>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract> day="29" month="August" year="2022"/>
          </front>
          <refcontent>Section 32.1: Secure Boot</refcontent>
          <refcontent>Version 2.10</refcontent>
        </reference>

-->

<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.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-rats-reference-interaction-models">
          <front>
            <title>Reference Interaction Models

<!-- [I-D.ietf-rats-reference-interaction-models] Active I-D  -->

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

<!-- [rfced] Informative References.  Given the size and scope of the Linux GitHub Repository, it may be difficult for Remote Attestation Procedures</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-rats-reference-interaction-models-11"/>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Michael Eckel" initials="M." surname="Eckel">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Wei Pan" initials="W." surname="Pan">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Eric Voit" initials="E." surname="Voit">
              <organization>Cisco Systems</organization>
            </author>
            <date day="22" month="July" year="2024"/>
            <abstract>
              <t>   This document describes interaction models readers to find the specific files [IMA-Kernel-Source] in the future as the repository expands.  We found the following repository 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 typically used Integrity Measurement Architecture (IMA) maintained by corresponding conveyance protocols are
   highlighted.

              </t>
            </abstract>
          </front>
        </reference> Mimi Zohar at the following URL: <https://github.com/linux-integrity/ima-evm-utils>. Would this be a better reference for IMA?

Original:
   [IMA-Kernel-Source]
              "Linux Integrity Measurement Architecture (IMA): Kernel
              Sourcecode", n.d., <https://github.com/torvalds/linux/blob
              /df0cc57e057f18e44dac8e6c18aba47ab53202f9/security/
              integrity/ima/>.

Current (updated according to RFC Style Guide guidance <https://www.rfc-editor.org/styleguide/part2/#ref_repo>):
   [IMA-Kernel-Source]
              "Linux Integrity Measurement Architecture (IMA): Kernel
              Sourcecode", commit df0cc57, 9 October 2021, <https://git
              hub.com/torvalds/linux>.

-->
        <reference anchor="IMA-Kernel-Source" target="https://github.com/torvalds/linux/blob/df0cc57e057f18e44dac8e6c18aba47ab53202f9/security/integrity/ima/">
          <front>
            <title>Linux Integrity Measurement Architecture (IMA): Kernel Sourcecode</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
            <date day="9" month="October" year="2021"/>
          </front>
          <refcontent>commit df0cc57</refcontent>
        </reference>

        <reference anchor="NIST-915121" target="https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=915121">
          <front>
            <title>True Randomness Can't be Left to Chance: Why entropy is important for information security</title>
            <author>
              <organization/>
              <organization>NIST</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="yang-parameters" target="https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml"> anchor="YANG-Parameters" target="https://www.iana.org/assignments/yang-parameters/">
          <front>
            <title>YANG Parameters</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="xml-registry" target="https://www.iana.org/assignments/xml-registry/xml-registry.xhtml"> anchor="XML-Registry" target="https://www.iana.org/assignments/xml-registry/">
          <front>
            <title>IETF XML Registry</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
      </references>
    </references>
    <?line 2469?>
    <section anchor="ima">
      <name>Integrity Measurement Architecture (IMA)</name>
      <t>IMA extends the principles of Measured Boot <xref target="TPM2.0-Arch"/> and Secure Boot <xref target="UEFI-Secure-Boot"/> to the Linux operating system, applying it to operating system applications and files.
IMA has been part of the Linux integrity subsystem of the Linux kernel since 2009 (kernel version 2.6.30). The IMA mechanism represented by the YANG module in this specification is rooted in the kernel version 5.16 <xref target="IMA-Kernel-Source"/>.
IMA enables the protection of system integrity by collecting (commonly referred to as measuring) and storing measurements (called Claims in the context of IETF RATS) of files before execution so that these measurements can be used later, at system runtime, in remote attestation procedures.
IMA acts in support of the appraisal Appraisal of Evidence (which includes measurement Claims) by leveraging Reference Values stored in extended file attributes.</t>
      <t>In support of the appraisal Appraisal of Evidence, IMA maintains an ordered list (with no duplicates) of measurements in kernel-space, kernel space, the Stored Measurement Log (SML), for all files that have been measured before execution since the operating system was started.
Although IMA can be used without a TPM, it is typically used in conjunction with a TPM to anchor the integrity of the SML in a hardware-protected secure storage location, i.e., Platform Configuration Registers (PCRs) PCRs provided by TPMs.
IMA provides the SML in both binary and ASCII representations in the Linux security file system <em>securityfs</em> (<tt>/sys/kernel/security/ima/</tt>).</t>
      <t>IMA templates define the format of the SML, i.e., which fields are included in a log record.
Examples are file path, file hash, user ID, group ID, file signature, and extended file attributes.
IMA comes with a set of predefined template formats and also allows a custom format, i.e., a format consisting of template fields supported by IMA.
Template usage is typically determined by boot arguments passed to the kernel.
Alternatively, the format can also be hard-coded into custom kernels.
IMA templates and fields are extensible in the kernel source code. As a result, more template fields can be added in the future.</t>
      <t>IMA policies define which files are measured using the IMA policy language.
Built-in policies can be passed as boot arguments to the kernel.
Custom IMA policies can be defined once during runtime or be hard-coded into a custom kernel.
If no policy is defined, no measurements are taken and IMA is effectively disabled.</t>
      <t>A comprehensive description of the content fields in native Linux IMA TLV format can be found in Table 16 of the Canonical Event Log (CEL) specification <xref target="cel"/>. target="CEL"/>. The CEL specification also illustrates the use of templates to enable extended or customized IMA TLV formats in Section 5.1.6.</t>
    </section>
    <section anchor="netequip-boot-log">
      <name>IMA for Network Equipment Boot Logs</name>
      <t>Network equipment can generally implement similar IMA-protected functions to generate measurements (Claims) about the boot process of a device and enable corresponding remote attestation.
Network Equipment Boot Logs combine the measurement and logging of boot components and operating system components (executables and files) into a single log file in a format identical to the IMA format.
Note that the format used for logging measurement of boot components in this scheme differs from the boot logging strategy described elsewhere in this document.</t>
      <t>During the boot process of the network device, i.e., from BIOS to the end of the operating system and user-space, all files executed can be measured and logged in the order of their execution.
When the Verifier initiates a remote attestation process (e.g., challenge-response remote attestation as defined in this document), the network equipment takes on the role of an Attester and can convey to the Verifier Claims that comprise the measurement log as well as the corresponding PCR values (Evidence) of a TPM.</t>
      <t>The Verifier can appraise the integrity (compliance with the Reference Values) of each executed file by comparing its measured value with the Reference Value.
Based on the execution order, the Verifier can compute a PCR Reference Value (by replaying the log) and compare it to the Measurement Log measurement log Claims obtained in conjunction with the PCR Evidence to assess their trustworthiness with respect to an intended operational state.</t>
      <t>Network equipment usually executes multiple components in parallel.  This holds not only during the operating system loading phase, but also even during the BIOS boot phase.
With this measurement log mechanism, network equipment can take on assume the role of an Attester, proving to the Verifier the trustworthiness of its boot process.
Using the measurement log, Verifiers can precisely identify mismatching log entries to infer potentially tampered components.</t>
      <t>This mechanism also supports scenarios that modify files on the Attester that are subsequently executed during the boot phase (e.g., updating/patching) by simply updating the appropriate Reference Values in Reference Integrity Manifests that inform Verifiers about how an Attester is composed.</t>
    </section>
  </back>
<!-- ##markdown-source:
H4sIAGRzp2YAA+2923LbSLYg+s6I+YccV8RIqkNQJHWxrHJXFU3RtnZJtlqU
q7rPRIc2RCZFtEmADYCS2R53zG/M23zLfMr5krMueQVAUpIlV++ezXCERTCR
l5Ur1y3XJQiCWh7lE3koOuLPnXdvxFGYh+I0GcqJGCWp6I7DyUTG1zI4l9ks
iTMZXIWZHIpzOU1yKTp5LrM8zKMkFmdpMpDDeSozMc+i+FpcnJ1mtfDqKpU3
h9R70H3bOT/vUM/04zAZxOEURh+m4SgPIpmPgjTMs2ARxtdBPpsGg3GYpmHQ
3qndXh+K885FX/yWpB+x+zdpMp/VYPR4eBlOkhi6ydO5rEWzlP7K8naz+aLZ
roWpDA9FXw7maZQvah9vD8VxnMs0lnlwhAPXBmF+KLJ8WJtFhzUh8mRwKBYy
gz+zJM1TOcrM98XUfq2F83ycpIe1QEQxPHvbEK+i9OM4mfwdmvLK3sr4o/s0
SWEdr9NwHo+TkUxF//gCnmoolX6Q0zCaHIox9NK4Ur38jHBqDJI4Dwc5zglm
KGEB52MJ08jTMMukeL4HvwxgIw/Fxv5u+8XeBn6H9R/CHqdTANswpxbzOE/h
4RuZTsN4oZdy2hC9wUc5Mes4jWArACv004etY8q9NCT28nMW5Y2RadkYyida
TB/2ZQxoEqaRWU9/fCvzcej+QEu6GCfz63HenyW5sx7/qVpMxl00rlQXP+fc
Cg5KDtsz1cP3GuLXJMrN0L00GugnNGY3ygaJ6C+yXE4zZ1R6bseTN/DOzwN8
6Hb/qiH688nfZWwGeBVNJvbZfYa4yuit8iAnDfGnKDQjnERwQPGJ2IStjj9u
6XHezsNbGYkLORjHySS5jqQ7Gv9qh6N3G9DNBPv7eUw/07AWEVrNlugno/wW
jrHo3Mh4Luviz3Nom4eROIqgXUTHgPHhXRj/FagDfE/lNZClQ/Fv2Hc2txjU
bjWbrfaGizDdcRSHeq0XDXESjkZyYZZ7kUztI16nvJ3IPBdn4eBjmA5FDwnK
LI0y6S73rGfXmifTxoT6+Hk8ky5s3zTEazkEqpbcmhHfzBei6z2nYf9tHkcz
OFTvZH4LP7iwVT/ZAa9H6uWf/8o/NYDgeYC127SAhaQfxVEa3UgDyt+AtAOp
HlrINVsHB/sbDmxP4XiGg/E8A1gAPYwTOHc59IFU9Px1FyC9q/7cb7ab6s+d
/YMD/fTFi9ahILrPJH8xI4SBnw52dg/UT8ADhrj96p32bku9ftDc1Z3C07bp
dGdHN9jd3T80/dnXdtrmz9Zz9Se8tXsoiP2E6WAc5XKQAzerwa/HwVGDZgIQ
BLo7Cj5KOElJKtUE9Ve3KXWELIwYJr6JOxYM5U00kEFIjBPI3PGvOABww1aD
5gTcJ0yvcX/GeT7LDre3iZXJISDMbJ4Dal8j32sAOmwDq03m6UBu4zCw6XGQ
zeQgGkUD4sjb3B3z92cwhIAxYMuiWPTdds+oneZlgj6B+l+oI9F9Yx6oI8Gz
El09LcWPscUwzKEFcN+doNUMgAObFQZ9WA2BNbvvYm9nAbI8Gefb89kkCYfZ
NvQZ4HICQN48aAf43Q5weQMDXsLZaLX2L5st2PNmq9WYDUclsBBIsA/RxnkK
28czZ+qwUmAqw8ef+I7p+iFT3hH6bT3ZdqP5VZg0ia7SMF2sQyYYBvgANf1G
+NTaCRCl9uw6gw6c1MfYkO6bS+zxMm3N9l5cImBblx2HClzO5lfljVBzPpuE
SCinKDjPJ9JAJeAdAgrnduVs0+Mfh3N5E2DH6kTY/oNmq7Fz8NAltA8rDgWO
84tcPNLM2zPqLQtgGsERU8njIbQCXhQAegeOrgHnBHaqjZsCvPyg3WxXnxJE
UeyTNA7uU+g+BfTp6i910GluWu0nQ952i4jhAQGv+yboTK6TR9l16OsSOwPl
Zjy9PAfODBx+gZi8065G2+4bYV4Q+gXa1VfH7/vBSXId9EDQyoMLYMePdLrO
ut1JBA8vz16f4dyae5c37Z2l8zvrCm5vMfN1lE5JCARFcxQBjhaIDjLf/vvg
uNcNXjx/8TxoVc/89va2EWUJzZWURxAutveaO8/3GuN8OvFmcipBvLkGsRPQ
AbGGh4JtHoKSu3na6WZbcEJg1G0YVahRkWaXZ7OEuVfPprXfOniU2bTLswF5
urV/j8ns7+5VgUYPw93BKM9x7HjEEiBMKzeyZWn4g2DnPhN4DiOUJ3AkhwgB
OHXjMBsHo3k8wHEzBwR6LJjdgT+J3YOD+03i+f7OQXsFFFSHOBJM4Ci6jvJw
IrLoOg6JZopbOGwinM1kPIw++ZPZe7G7fy9s3d/bPWiumIzqECazf8dNAYl4
517w2Nvd22mtmILqEKbQhCn04kG6mNEMQk14mI0c93o94FLDoLWzvxOAyLhE
dNEDZyBcS+nPxbxaMR/oXpjfERj4oK/e9CkIc4mz+dUkGiAnEl2cc3KdhrPx
ojzZELvcrZ4tzvETEL9U2ukOk8F8ilSxtbOzt9t+7s3TdvgVc4RXOzDCEEch
oWM4jPAlQERS9KK/zRXzfnfcvwjOPrwKXh+f9WHYJcRpkKWDRgzcoXGd3GzP
aFSexvZQgvY92R5Fs2wb3oc/YBhvSf23nWDHLONQnMl0OmdWG7wiG+JbOLfE
hXufgF0Mw6uJDN7Pc2Ao4rU+zXa6/bODZjPYOeg+dK7ZbJt7GFTM9lwCK0Pg
8TlBKL+aJIOPohvNxqBwnxKRTUbiPSjS1AY0+rEU3e4p/UZvFAgzLq0L2mJE
Ekc4AaGjvJyjr17O8JGW8yacJFG23UWbiGoiNt90T7doIW+Av5Rn//qrZz96
pNmfSpDYhnw+8GD8BkdiBoJJcc57+52vnPPefgj60k2wc7eZn4VRGvwWZRKn
FfSAakHP2ZgOaX8wllNYygeylx9F2SCVOQjfyXXIwlmJBDkraTUPqlcS30xg
+pldDP6BT7ZP5HU4WGz3z+gR6XfhxFmq6rYkkVUsC2F8JNPohh/xCs4yOR8m
KeBLMi2c4asoyQJgPI8gTp51A5YNNWm81DLipRINL+EL6nOXoFRcKqPn5c1e
hZLwEFGzjncJtOoXjd3GXqNNCxzIySOJyse/vbns9k5IyWnOdluVQnI3jJMY
JjQRJKojzojXxOft9HYbOzS1D73XxwHdf8jgVZLk1fOcy1HEjBU0VUT6UTif
5Nu4/swYCLJt7OwS4XHZvnxxiXrNZXPnslVGmg8xQEwq6p5FQN0tXOn+ZRSC
OraJ/W35ABa/yjTD/9uNFyDYojWOFKgtu7SddqMlNnlNAte0BSuNtKTDBkjf
FJfKkUxlDFplhIOH1E8wxauuTJn9yj8Q1z/tAKtNYzkJ+gSDavCBxDeGfYJt
3s6T9CacwG5Oonj+aftqklxtD0fNwWDvuWzuPR+1DuTu7jAcHMj9QesgvAp3
n4dXezuwxNGL7UzdU23jbK75r2nom19OsF8CIjUA4hdmAAiiKa6pQWzC5LcO
BU9f8PTRlmtpyYvWXqu9RPjMM6ChWSVR3IaGl7DjjcFo+hM8v4yGf+CuiuYF
Kc6JHsSgvQjA2v/vf/6vXFwBkZOjXOQJXjHCphyK30CAgfmnyWwhokxE01mS
gvCQE7WJHBlWA4jWQFbjWZiCGg57t0SfJgk2jEPC7jBDqRxBlW0X3i5+b3wq
CpR0R3pmGuAMPk0nQap06HsO777qfSkPfNy7eC3+dHpi1PVaLQgCEV7hFdkg
r9UuxgA0LWMKOLwRAJznq+5qzf0s7MJkAhrj+RlqjMjcQzGStwIt29H1nDmq
iInJpvJv8yiFUww7BbwpjeSNFKFz6ytvULyBgxxeJSC4GaQVU4uTwJVTYAih
YON3HbZ0MklukWOgDJVoLg7EjOjhJ72AIfSHliZ16axuPbQlR63LHgMgG4aG
NMgYM6Hx0ZDlTEcAG8oEkqFwkiVilia4hqG4WtB0GGYAm7oATeUaeDxZdGgJ
SQzTTcUUJHuRAtUhKYQIPKGpO8jm+cVpttUQF9DllI1qelEKqDAHmAu8klO/
2kDPl+NkuwpBb5STCf4fAmjSlC7hh+py3V6LgZQN0tHmRb+/hZMW2D9QIJyG
vjvBA6WgwYpEPg5xuwaTOch5uG6AA5INmN8gnIVXEcirEc4x8yCE9/ar5pXp
OWU4p7oegXYSR2EUEMgNYdGxguBYPUHWo5uYvchkegNSH+B3Oo9jHAS2l/F/
Gg2HE1mrfYdYkAKUiXgXTwP8zQiU8ByuZQwYNwFtOJ1G6v7LQThs8vlzULoJ
+vKFDss8k9ld8Ba6OD/+FV+y0MLXHC4jiMtQry6FkxN1bPzelvCoL18YyYAq
An/LJwuRzWdIPMk0onZfE02FinD63/ZP8fSnDOgldmBohxu+BcPzLYiCAX0F
DOXVqYsCe4SW2EOhs+4bOBLvGdsJVacgY0SAmYxYCvoD2C3Ei5B6YKw4UrQD
Z2yoErRP0iEgB5An2BeLM4UTR/06KNEQvRCECjxEEbqrQBPCZTzT/pHGez00
usFx7m9549GNn8hIunTg65CAnqKNDSE6ADR5xyFTibuHUINBz/1BK2mwMw4h
Pi0UYAy7wZ44oSFq3AcaAnJ4+rc5EtDbcQQTk58A0JJnNJngW2hX06ezan2Z
GMvJkPEZzgAgHhq51BbCOuGMarGOjppm6rByIqarz1h50zQtOVRme5nWK/DD
AGPt6PYK426j9kCMSTPeWlR/Nnu/ALk9jiNU7j1XKPr1uIM/u4/N1QP93jnG
30+SQdXLJ/AyrOC774DLEa4zwOOEGyGFk+IjtASGCFrvs9MP/Ytndf5fvHtP
f5/3/vjh+Lx3hH/333ZOTswfNdWi//b9h5Mj+5d9s/v+9LT37ohfhqfCe1R7
dtr5M/yCQHv2/uzi+P27zsmzMuiIuiQo7UXsHyFzQvsaiBaDNLpicL/qnv2f
/93ahR35r+Qz0HoB+8FfDlrPd+HL7VjGPFoSI5rRV8CyRQ0tqiHKh8DLJ8i4
0O4KnBup0ji5jQFFU0CFlz8BRksR7P/0Yw25xYWmE+q6i0wMYQaostKxrVZ7
7wgARLEI4LBAOYXVKD5XJlvMbRUfzSoPr7iJwnvQL1wBKTd4Y5vSpAO3W7cX
GaNtjXl1kckmIK5+lJozwtFnwhs7ZwxXNAAuP0RBnQ3Z2Ha1C+Am+uohf3G0
keoDzxvLIoArSQyM72GqfA8rWOcStl3FJR3gdYAESCBuoELrFcGKAZdA+0ij
EFYVTtEMhqDQOsnnz46+BL3pjUdmO4kK4uOADQou5eZNgD2AQZJRAP9oDqQW
0QxwlQAT2pJxNYEvyap6k4xkZGYwDPOQOFRDvJ6n8DitMwrxmjULylH+lWRB
ALYzCRc4LghumRJcyapGxwMtQPOYpGs1TionLEuOoxlBCvlbBJsHU5yj0RlY
HfJJTYUV6xha4c9lGKUjA1NEjUIzoAGIW/zFPQdEIp2TDEf0WJ2VTJkKmH3d
kMTnnArWABT+UD/fiY0VJ2pDSZXuwWKOkpkeNVsrODQhBcMdBkiPok9iA3/Z
qJuGWkgrNhvfOo20i1Gx0cdsgw+QmvvgOggn11mDxoC3oVng/VLsIA/DDRRQ
zGXBZFEXxljCUJqGQyIVnz8r7yk8tepL67n5go5X/KXgMmMeapcN74H1LPAe
E192Ois20xZF/lZxc02kxcrenz9H09DIrzGwImCss+AK5C/uhpHgO/Fa8p2d
2nC110qoZhneKrAj1fgQFBKxMQXc2UD3Yr6bVFqWL+MmviIEhEd1LRjp3JPf
QJseiGYhKm/qAKsR0XkRpC+gQFpsQak5Q+aIO6aHJL43wJsz2knY9QzgU+fD
SogQoQ52GyuJDRaBgC0vwpmzBwolkcLhgsOJu0AWQsE0BTXthrdXNAJsxAMH
sN3yYcMG97KG1YEWSI0LW7xgjQuXiAsPnJjuQ2Af3ur7drz1uKdExOiO2Efk
hRi2Z5LRgx+qzawzyBWh8JerR15pJVJU1Rm6TiYS4gxXST421gscwZgvnEnN
rGhQortIeeHgtNpBmedXkWDUY0KcB4o0bPTR2hFrNmhikzyPs+45LOJ7/POP
qO18b9X2LW2W0nNHvoSeyLmg6+qE5pxlSdoQv9GpIgio48dnHbkUyhk3Usun
Vj7cGEhQ48ggJQN0FKLWIMIbNl4nqXXt8CggQDslGzV0rAb68YphFF6n4dRw
RoRNRBYa3iokTP/4xz/ExXmvV/t/giD4JO4CavEZ+MIhtfzyU00IfPMWiAyo
8/Dtf+gH3JXznu2WmwndcjZIQSobyk/fC/OBZ4VWJJwEcKTm0rS6iuIwXRQa
FkGLvRafocnfvKY/n2HKh7h1ellpgmIGr0voJ+V1aSB9L/77X4z3FzcujiuW
z8V9bT4L8mgqf3JnNwfBdaddaIgXWX/88P6i17ZtFVBgZ90T1G7+jicIT/zv
eIJWDv/4J2gtqM0JajcJ1QpHyDtD0NmyM7T2eLgnxGvM/eK5y+SEZWGNvNys
MANyo0L3HMSySJkqFNoWXqg4zHyW157RFUdj1TmtOKj2pBagV3lSVxzVdafV
nsI+H8PL43ev35dh7zYmw1pg3L9+Wtm4ihCIEi3QjWM+mrSxhAmZv9ACZFbt
auEFr0ezxX7XXmP63dn8FV3+JHya1Ym1VKvMDXjqDN5rMkQ+BUh+msFzTWrQ
r6i9ty+uwvijkoEnSfIRBN2P0hdR+NzWXqYz1D3JdzKIhn941mq2nuG1XZz9
4dk8jQ9RPTqkW7/sEB4fxtmhivM4xGuDw1aj+exHWN/LNSdViDW9ok52uELF
pFFgnCI6/qh63+T9I1pN1nGkewbJ2ByIEj0bdD37QJSpPkiQVJo/vlqyNaDh
YIvnsV09kZdEhvSkmp9kc7e103zebh4MX4yeH4z2rlpXV3IwbL2Q7WFrrx0O
d18MZXs02AufDw+GV6Pn+y9G+1cHo9FQhlcv1FhOpy8rSJce7mUBrR28uzPw
lSb87EfzMrLYzsmbS0AuwC091HZhLDMHg/w/Nl9u2y/ln1urf26v/nln9c+7
q3/eW/3z/uqfn5d+1uAobYv+ofJg/Fh7uQ0H8Ed17AH/BsiSR3PNjTNHk+Ur
MLYR+9yXTnGAJqpF6SzX1m/+Xc+zntKTHmeDdXftXtt+nllCEKP364CIZ9d2
T+EI2hb6i3przWF2l49n34yRhrclwlAXUUM26vqGh/ncDyw3qXuSrK46CKcJ
XtWi6dG93az7ZujoGsVNWIYi+XgHCRRfd4IDEWWoe5rlgNwBnV4bepXVy3lZ
YMhmkZZ6JnjHXHxb3Z/p5X6UmnkbSkymWOgFNwkwUk+jYryqY6LxTZ0SRvAf
rVgvNkCND4yhYa34Hg7osogmbIzGzA5u4UhJcrQla5FrmNVS/lfIxbhqlo29
CWtUL8i++DHCJL6Adgx9KiqEFK8t054kdcUeT0i2ombxg7HCFBtcemmTCB3N
Y+snvwEPfrg5CbM8wNuAxVapgZ2gaWTlnoLY5/dK467rkCcXz6dXMsUeUTTc
363uEEVJQK/prNypWa1p48qcRG8wWomirbBJFaBwB3h9f5uHtE+mD5xVa9/Z
8qLEbh/zrXlAlio0gGVOC9MIPZDoFJYEXKdN6ArO/v4WmvpidlG69poyDmfz
SV5qYNps8jmWw0taxSW8c0noU/WKUJuD1rgtQebQLz8tafg/9AhkNF0GIre5
qHiD9ggAx98YdcpAdLswvbivrADVincRDgzn+7xr5A21RRVaRfWLzESCSZTl
lahSeMkA+E660aoOeGBFbIrK3aoZM5iy6O8PABO/y+di7bhMY6YhIB1aoNfi
HDS6H8rZFx4R45yPT+pWd4NzAbIymwARK2jTSyhDZTfo8UxWgDGM7fdz325w
l0h/8Lu5D6p43QQmfOqne85Gw+Uxu3n4oopH3fnc+dSXrCt3nAodCe8OBA6H
933pMTFj08XN2nOy5I37HJRCLw89KIVuHnpQCt089KBUdPOQg7Kqm3tgeKGb
hx6UVd08fFEPOiiFPtYfFKtvUP6vd+j6rVQN7UVhfZfEOLoeiwmgIrrfoB8X
R3YqRw1Sm9h5nFJURcYvxfcvJ1u/40GbXP0Vhsqsf5F2tJATvgWnGwEOxcrq
YoaO05Iuc/3GeJ8tJyP2mbXeD5UaOt27dnmWcKA2yHdIXbUGmfE32ABN55Bd
K8eJcf/NJOmtruMue8TgcpOKy3y6LNVO8A3lqqmUZquMqZtm0Mk2s626cY2e
o3bPkd7ZHNQ5UMPs1f4WOhVYqx+/i/YV2DHrXmVDbx0P4XCQJhkvaKZ8f32Y
AOQUAM40CqzeSLVFtFryMrCDkdMvL1kjBW7MSIUFBTcc91Nnoy8vaBou0DRE
CvWw7prqdQvy5M+yZBBROLhCoDDn4YxzGbtHe1PFjZmD2vt+hJdK0nhD33MQ
0JvJuc4xxJCi7LcOxSyEBoP5JGQPfxc1PspFXXyMk1ugYdfS+MQ7PRp931Pb
lXelsUY0/LuqlC53Mn2DQt+A8yDR1hyHnzuXIebjkTstMbOrkgrIYBqSJHAW
Y6/dbLzIMDjNpV0k4orP49tDldRjGl0ZTqteC/NxkUhVzEKdhwDPg27mPsPr
m+IFknl5GsbzUUgHO/1p2Ri3ooiTtIKSimCA2mr7Ny1u2+JdevFFIORZ6SLN
baOMrnjjAZtXMEr/RZRuGoUR6Et3e9XLMK0rLvYQjP6cEnVu/H2SIJWok+XN
3z1L/mWW91sBK91WRdysYMPcUNtJcf9xEwAtRwT/j9lhmC2mUzRLDcicWhDx
FKyM2lpeErHIgSWLSvtPA0PdCL7ZBgbw6+OoiQeGmZI3vUOCiaDcAKUkt1Ak
lhjAoJzD+N4GaaQhyqITK9oFTek2mwMeiIk4GR4S4AvTKPeGKg1ztWD3HWj9
1zmFAgBdp4gK5GrGs2oeR4j+fEeHXnRIg1TGDXcAHfbRfdMo2AQVZJdBq1bY
AHa7sFuFogtA4fv1B6p8Fss2wLt3gWbaO8/COXblU3e3WVAXRRRzSRrh1W9j
SeiREn8heQhYUGyixwxwlaeg7QuTw+GfqyUXvhUsShwVjMxlQUqQUeyJGX6B
Qyn2tMC/+UB4a9sAkQ242CSJr7Ml+OOBooK0V3EGpCjIDKKhR1Qc22I0LO5N
mbQ4zctMbSVLK77umyrXjjZJOJCxZN20wrrj91yrfT4U360Tdxm4+FrtZff9
UU+86r05ftf/kXQn8WzFq+RP/HN7N2g+D9ov6NuzmvaCXhGG8LmmYnQ1G201
Wj/UOG9WNsMA8AffrmE3yokZWvyAsbjsj13MJ0mTMG3xOb76pdDehMp5rce3
VW01o/Hbfsyq2urbZr8tnHtuXKPMnmEc/d2yzmcU7UvJjjd1lMVFhStlf8tP
hkwgsXmBoaPf3ojf5JUQh+KljkZG/Qxjhj/KlKLjORPB9TbqPtvqXgxeO4mA
LcBrmEs0Tw7x1591c9WqQ0nSsHOT0Va8LCSpLTX18iHDrLzExqWEwKXXvTTE
MLvV+YRLrxez/oqX65L4lrpwkuuKl6V8uaXmpUy54uWIst5+Kme9Lb1s886K
l+X8saXmmDRWZ4wVLyvzv/5IOOKo7YwnHS+swY1WqfLrJeGfB6/Qcg16muDD
sqMcv1wdCasvW4ujkvMhvzhLUcQB2cRqc8g56LduMlukEeyg2BxsYdqINgfP
U0yqGQBeyzAK2mpO/DaGZBI8nbjkISjrHfQexF4xJJ4CkkHVojfO5ZByEF/N
jTY8p1AlwRkz6AnbWci/IaszF02USI1fMM4FAOBkGAGOOsPoZHKGmM3TDC/b
YGNYn83mZCyB79wHznMSDSQ6U3Cso2b9eNVbV+FaNxHqbK/6R4CU3DaT6oIL
JoaRALGTOmSgAWCht5EJzCAzYUsAkvNMw8DaPaj5kYrPUb9v+rlQpCU8atYB
yiJbegtJoNAMQ18/e3E3GenS+Nv56674E3wKA2HOhXQ0CGBzgFDTUDjENjzD
1ls/GMsRdKCwke1GKCKP5rDdE1pqnIDKLjM7NTfscgODwNC7Xodd4t867BL/
pmhL8wd3oZpxxKX9y75uAi3xayH2ckM5Rmycdv6s/fl1AObGPQIwqZNiFKZo
7QLDAYBiDOYW/4kRmFuVAZgG9RbiblGYz4hHp5JRh45m0NwLWs8VayxSJWSE
KrhWIQMRL2Gjk3QzjQQPLGOgJbC11QyeGZ69/X3xs01PoRcdPoQ9qqfltvBY
u0GjILscAhdLg09KhBdOgw770StC2skrLTpEN+xa9ETw9vj+E6G3KNJl2e74
qZ/g86DMSPrlR8j+BJ9iBqcSMKJpeD9Y3CH+iKCkZ3AaxgtxAxJHqJJgHJ92
OLBJfkLZy+TLgPUvOGyVkxYAaMk+r/oh2p9cU5zqQiioZTrZRDH4ksPIWQm7
lsa9ATVV7RYUsvUVOnDyCvQVtTSbSwrbLZ4u3QdqoY5PL1upY54ubO5S9MDL
qCrsQBL+IAxZlUPL7vxeo9XYL++7dxF4/9Pgv77yWJSiwAwENDkDiqQShopX
dyI9GPU4lKO1pCfndmjuU0skByy8QjxQD2DCIXpiP2s2GjsttYYvy8DxK8iy
iD7oD65uJ/myA1AJg0vdhCE2SAN+5Hf0wtk/TYX2NYOdFr6bM09D3x3oECZK
Wc+Qst2S3+g4vEFDhe7DmkVANYcR+g6l0+suG4stEIzRUHWINmnxDH33Dpdc
D9FvnoXimWPoVO+6v9MDZYFYB1mShWhiTsi2PYWhTfESk6Aq3iFboJsJY5O3
uX/QFESysU78g2HvE8rfQeK0XvwsAVRQAl2oewH5lIbNPVmMTERMZhacNUSn
nDEAqtqBioiLR9gFvOzQf1RtgmOLLj7gTYGprNuRDs9QXQux2UurEQPDiUOX
99pRGqvOsT3INgx0+UnmoxyZdObV7mjLSRgmYXVe1yGlOEs07P7dLIXpfkj6
0u144eCVHtPLegO8BJgDWirDjxKNk242CWf9ZmjLahFcyxbyw9L90BGvtNxU
YqYKFmmBo1aN58g5jzBg0TpqQqCrhq7iLk8wB50orYdj0aZgisSVuGdQjyxJ
gAgrMI8Q71q1K90wreSZA5vQFIQSc4VgKBvdLCgLQFs5JZM+aMg7avEYKqDv
KNDrD7FUX5Q4183JjC0D6kQjTVkyW0V1PNO8IR+0QWiox7d+UI+/1Jz5bDTE
H8Qq4rTh0qINarnsSkSTLzXLDWciMk2TNFDhD4o1mGUPE8mhkTqbQGGlz4oz
L++Q2iPag4xS06oscZm/P6Gq/sDc3d0duz8Uxom0I8mksyVXC7wHN44G5jUd
HYpJP9i2YdbDymVdScOUlFRwCGTieGpiHotDP4xng6/J4P3JouFQ9S9F9HUv
bx8PfdF+RQhcQL+K0f4J0U/N8qvQz13pY6Ofgm4R/XRWnt8b/Vp3Qz5OxrMU
5TpC5VJWMjUacSh+A0BxPQ/hx1xKYfMIoYFGXfEaFm1NZaFK8RMMZa6UoKkc
gKQcZVMPSd0wYw9B2YypdxJTu+Bt9ILqLv6wal87/smhZHGchRF3xV8kC1bZ
GIV7C2DciivKXzKMBjkZp2dplFDUC2YwiTI0kQ6kDhPlPp33uXM1KHljqfzU
nOnIn4NCI/v6EFNd69RxpNVyVihl40XFBXPg6ftTI+7UbBeOYK72PeMcUaRz
kz6DGKMUnAl5PbX2mxgMb2MShfbZQ99zXDfemgKL3NSJ/9r0Aqg+VwuYQmNL
9AE+I8zvKtNlfXCCSMwK42SIUueA5oSADzG7me2B5AzAFnLk+rtMk0wncyI7
PZrJgfTEGmQmJaDpwE04hDMkvY0m7c1HmiRdPI88jaZTdyIK4tNEZS0gQRvg
6i1xHfn3YhpXnUcTbIV5e3SyBDdlAeq0HESt7IZRbsiTzY0FSx6ASI3IX0z9
54bzbXa6WwZkF6UMaXbGo2iSqxSpUqX4sVnjdAd6ze5Zp6AJJ5jbO+7weOWp
xhnxgcm26XVpbk1YcjsG2V9tM1qPF3bGdv/gBbI30ZG7QfAubNod5alADWyA
ILnO2B6y+RW2K7bnhJZE85UtzSzYvruKaxZaubol+Sr9QbkUbm79xeGa6M21
CtuKEbR3xjYd21eNbXXHT5GteXr6QHWlCsJUktury6PjNz0A9yCZmtTGWuhu
MKaVdkrL2dpRiI2E6jqNSnnYmlIlPDRzQfpSwkPseTlkBLohwdaLZ8sk2krk
VOZh5ayrZ29m7c9YZXpCMLtU39AwRdp88DXMBIq2PUHlx6oKvNHnqy2cZNi/
S603a+5sNRsvGs/NjNmL2Yen/m0VXShThmrw+9TBpQoMaYusV5IOBnkkOGRd
aF8jEvm89M2FaQPCunTG7cIjOXemNG4PBaJTTWuEJn48lr+Msp8fjem5UBWE
4zLdWGEuq7o1s/6HBa9kRGHtvOKJfKXEKB4jqBr+AVLg/eZVST3dyVWSTEUr
UJxCy5P2tvfE29L62LNq5dw/cL8q3bOVXakztnUvGbNK6h/KYD4ji/bSpXzg
3yMqeJCgVVwdIrLzuutRga3+kjiicPWSqkcgCXAonTTUKCOi29AaIaro91W5
LBVZgERYuFkMlEqX5QvMdsfZpwp3lsYE5Fxl4eEnDZHSsLKNm1i+zpNjRHEr
hNmkAWpBRAydTXFgixSQIlpW6EFLZSPWoLSgR44bPCemAiqoQWxSn6g8Ai2h
5EKgQb4/v9hyaJlNu7ABU8Lr7Q1Hr1PAI8m7bX1iBMcwr+NT5eK29FGdDtQv
gsvSin+bg/Dabjaf22Isrf3GXpm73YezOaLWvWvjevZ62jTlLUBOJQ/bOOV7
Qh3Y7el2zi5/7Z33j9+/o21askHqbay795+btHST4Cg8aG/UEaJDiZV13JQk
JtKtcl/g1//cj/J+VGkoX0vKfydCTojFqVfWEe17Ga/cSgjoJ5/lrp6/qbUg
PyyCjJZONggWeem2mq7HfAOJc0dm2IMWJwtSaYX68h9NFWm1G60ySSgkzbk3
eaCj7CREMxDmujV81LV+a1rdhg5srWBnM/+gv1859M+hMa4ou0FpKv9j7QfQ
iMJ2LJGIUCesSEBoNqpyV5yTAqImBYjgI4xmU7Ej7JKgnAhTOZzD0VTJ4e2y
tH1Ca991cTXPWZdSSaQw4iWcYHylE9ha9IgT+lLxbXijHByUKlh4gXVFfQ1g
X48lErEwjTATGZZOiHJYVLZQSoCXjWk2S0Os/EgxVh7KTKM4ms6nvhJpw3E0
rcjQdzq+xrisKFY1kTAjkGuiGEiyTHuWCVjlHB1AOPvWbbio0809G9WdWXr9
JDHbvthBOkWOaG46yLETZ6msu+gByr6griEOAMqAc6fuxMNcJFgyZsZKxpiq
IdfR9uulKiSQYyis1ZGhR9uJtnd5L6HlRoWo4w/kgG0KESjsu4mcuW5U4DHm
wRevFuQeFKZ8/EvhdS5BD9nbASsoRMk8I5s9wOUGvaFCisOKCC1ngFiRVv+d
SbjIQkHV6dRb1kbm0qkxBulIjO7jkmQ1F/LW8K3YbET3AvbSgePGFAbEWA8B
zemhiwEo96j88QBOw3jNAVYeQMo/i5bP0dmVaOSa/p06D9gb6z2abTrJ0m1H
xyMb6RYa1yPKA6elCjNhfVYQ+A6eMHDVLHThpCH7WHJ0HMbHoy2TspFTQIEl
3CstZNo4VqB/gnjFM2M2M50tNZKdKLskGnUNVXReM0po0QxXZYhbNooiwq57
njvGl/Jo/t2fGc3nwWsHpF7ckarYIbVexRLx8whsET9fazW1sFpmqMPMYU6W
1vUmOiXtLbi4CTrysr++wVdPtjW58u7qN7DSr8hxI7i7NFy+hiqUVvTntNwK
5ufQWQ6qI1XL0gk7dbWN0Cl4wE7Qeq5IX/yZqrtCl6ArzwL9DnugakLlgt5L
vXNvUxtbD3miqg9tbOOHKtlFAiyb6/pOnAwxwPvRAU9m9iLiGoiVs3Il1U7D
TyRW0HNHZuERNfHnq/QURTHkUXFCN4e3qmI2IM7go8foEMRhOkFk1T1pj4pG
WYq3KeDuDSb0naNKxlzTGN2ZK2Tjh8rF3TeXZ12OHbg8e312mbZmzb3Lm/ZO
2Tkczv1ulYbywItSjcKa/3EXii0bFNDZOf1hkUE4Ce5Wy9pvlaLKHTo2WzX/
suPRShKyxPnIZRkrLn9WOfLg5qVSJZ6xs3WuCvFDyoLWu82tlBb3Ma6jeHUi
yu0KKy3ysHULUMM7c7SaodX1uZU79w0D6w0RXqOdJBcbtpeNqksf7wRhdsB7
n6A+vlSacgmRGUA2k+CDLHG2f6fwZKgdL8w9ugUKRoXg/DbsAjec3E6k94QO
2WK98Mpx6jVypHHUcmRgKcV/17FGf7ERPoq0qrREjnwY0Y0czcUkGyqOuIJ9
edk5l7Ov0wJ31NcBKmdGwV1YHfhiIk+zPyRfuqxo9SX4+5QFXH39jYlIbNSf
4R6ulh1aQmTvbJXsrorZjaXDm24lRzZdG8KlZGefvy8Do8kfeRcBgA4k8Xlm
0/wiClAYPOWaE//Jgo12Gzt3lyX2d7+JLFElMlRKCq52t1pkKEsKzvFcITK4
+QjvfTP7Dm9gFckznRCfoQxkRrm0U6HnDZCZYNw6DY71rPB/0CzLs/PSHN57
eq9Ra6db4k0/8xmGtGwpbwhQXnV1xArweJkN702qtUyge0GX0PlsyESI/Crm
M/ascCBUnUtxzdRsw3tDqeO7UlMQttt1eeQleRofY2Sv6zUj33s78KVNb211
H8O2/inETnVF90BL/BF6XYYTzivjmbAGYyeVpItw8TXGp0eKnuOU6WV2D6o6
HEv4yIO5sYkWUjy4kNn4sVgwRjs5VQxh4Mq+iIWaKSz1JOFAn0DqQJ/grlr1
CkAsiR4ibqF+08vzm6j6HcgZWJ8YWI9oZND8M7qF6veRq6ZhlrutYDZs3K2e
hyuvmOyZaM7UtcmtVFe6WXOST+ouKIQdu83y8Jr9V1Ekq9NYyOrxLZkPyJkV
FBa2QdLtHFak1d1onavSAVfDBSSLK3MgTUFbHE53o/pAywWCgr/6kmEhj/Bj
oeUSYFexzwLK1h2FyExa7/U98dmmVF7l46UrQBhKgQiMMENHJSRRetjBOMEI
7dWhkfeyfvWMqYl6wEiKdGr21DnXSl60AMDqrG7oIeHvKNBx55QlYb29uKrA
qvOWzfhWKB7gKfVLjbZreteCvdf1MtuoWrEN7iwuGH5Zv16LUG4svb9UP2f9
3Va6vN8iqt5hjVVRncXVem3Wr3vtcazedD8t+d1AoYcyPKRUwrYMnXV8Z63B
vCKc2YtCxWIzNreTWB4EbeJRscrb3Sqb1op7Y1JBqoUuC8OnsjuDgZypZA9U
z4aI0EW/75ZxZd8fXTXbkaxDk9fT9xHlnvR22Q1dUV/V2dylJiwvB2SBWbpG
cMkON7oqr4sfSvO3GQfK0K3I4+WkBcFPVWHrrmeZVxdp5BCufL3dDjRsjVHJ
XNnBBBz01Jd2xZCeQgsKKfIv2dgittQNuoQyKgOldzTW+krjhyI275bJ4Jl3
UE0WA4w/wf+LKYr/sGEQeeMvS971MiCsb1OMc3nmAaQUEvoO4yVjx91ducN1
jn8pJ0HQny/O30uJFKU+nSUzdu5QGc3gOFJYGPkhXEsMrGMXICUX+Muj4usV
fjyZt2eb2VbV3ahro+WaRgYSOnxlScFgB2I6jqWIIuvZwcVYq116dPazo0NB
9YFx3dvmr3aFpIsfrQnaoAjK6UVeIg5o/GrinATI7WYq89C7XFDnakWYwpr9
daPeynsUZWUAV99gOwTAaVu2tH9xWMYdSvkuYxnt5lezDFW3mFmGf40Az8Jr
ck/gigFdLJsXw0k8JkXeeFeYlCv8QsoZXnUnJmWelz0G/xhKrnPPORaB0jt1
+WhIU4aPzWXZFJ1n3x13s7quwzzAsnlWL1/Bx5YViPy/jo/hht+JjxW4lOOQ
soS3/avxsXbzn4iP4bb9U/MxL9P+A3nYkvKUT8rD2pdqsUjOdCrz8n0qxSSx
AdEvvqkSaVGCfCrS3bm4wODWigtIYbkiwBhPfz6uY4a6cJYpt1FyrjAWy2/L
4Hzor2ZwftsVDM6rx7ncqnKC+mIvxnZMvmTEQcMW1jdRSF6VAzSTpfSVTbkF
cxo6qHJxGu2cyrZDe1c1IYuJcc/2w26pfIF+x3WMottlZdJxwnVFOL/mcIFq
LkQQ8/2yfnDR3q0pup4Zvcczql2NbIWHqcRji+kb3NhpAT0AS3H9ToU2fw+d
5Kyuo7qmCHxGir6ATN5LJL3ismMlNuo7MzeW3EZOZl4Yo/LFjApVzlR+CEpW
mZFXplm1uj2czTVNo7tjru/kd+KXHch06SIeM3KysNAwdYSw38Hf5uFEJZ6j
iXN+DVjNhl+qZgPNG+EkIwtfYSE60SZlc+TcExx30dAVF6KsKnMBfvQGk5ev
2ljy+tX5KhwvU8wtjaiDZnG/l867IxXuHC+UNF7GIdN/NWFQB8PWsb0bXToJ
M8d1zpzYOp84x2O0johiCsf6rI+sYLb0bYG5Lhtb8QQiF/yedvVBc+4kleFw
UfaD1B/2hyyU2y2MvNRtdfW0VGwTSpIUKUbgcW/Ww3wA2Cpahy21baUO9Gni
19ibxEnK7fhDs/PeSVJRV06TmHCUk9sF3ribdCxZZs5N+U0dtp4qF/BD9LK3
u+xIqXi4eK71cjc0JIXLM4Wi+30UlYqb4co+X4qIUXZdXokT77DoDjl54msm
6qqApgor6iIpVcHDbDTLscWtpVyNLr4PxvoZu3gce5O3HC+0k2+U4fz/SixM
JcOYKvLAAQM1S+UluJLXUUwl9OzhqOih9wiocp89NYSgAEK+IF/yo4JvudD0
/WBteldhCFT2ToONrmE+5UqNYx+X8qJjaOKgkwM1O3f8kpRfveLcRKugtZrk
3Wf6SxSMgsd+uSZ3WTjg4tx3Eg4Kspoj6/jSSgOZdMI1CpDn+StldEaRiBF3
ek+VxCr8pWLhdzEZSCd1B3m9qOPjOqtX3qawgKVLj3uA1LpPQd9ZAcqevRAk
IkBKDKkYpmgExnbRAn3w+TqOzvsgSkNrfYDUkfI9TTGErwhbW+n8fkzbAlfj
himX4ZpDkFgVDgrNy+7lagS/263R0lukLhWqFP9NvMdYNrTDqTgsriO1+lap
8pbJQm6J0WO5hoVgQ5TiykHW7sO1Vsh4pMLBSL0C0XjhKFZUO5KP4BCLzdyw
I6Zn/tKhiVRoi6vDGdpXUS+AKsBhjGIyS1EbtYkK7SoLhbdUbystSNVOaMlk
6BUfM8nTrxj7s+2Btm5mxcRlomSYVDl0VKpJMhjYQjBmJmwKc4tFWhwndwk/
Bzdhpz7iumKXf8+K2DQCNcI5TdMoDpTdMRNt+3wJZeoIs07Pm7m0QmIM7skx
eeaXLddkb+TSZl+jHx4f2fNsK8HVhS49+yoB7Ur0US2ZiHfrIsoqqqctNUh6
tdTKVklVcc2brUpU32o02q3d57sHO/u7z5cwzmWbuIYbwozO1PSV6V05nrjQ
uVOgG6b233+xs3OIEhsVizh+JTZ/VflGdrdEUBpsDVwfzRawaj1VA+sCdV81
+InuZCW6ZZMkXxG46EoR3p3Dmsj0ElEiE4IOsSomLafVKztpiZD4lEJTEXTx
XW8Y7Vj3fBx/KUUgmodV4VwQKhsY5m/imFucvgukJQKCCgfyyvmWNlKV9v3h
Duen2odq5d73i7m0yLho0OF2zGkLcx1Z4ssh5tKL5+6lUSvHtP4rEp/Ckr8N
zaFCDHc48fde6hEjOfVPGXGXZHJToUaI95xgwEcLlcUhleiQVHkNojPeVcsF
d74eK5QQeaIzcsxHQvkXemVZtU806wdRtuYIuHWvn2QDcaO8QZDgrJhQqcJ2
aVLLghKdsMRCZqFlB+8hkLfJCnOT+d0MJDpnx8Q1bFiLKKQix09E5QQTlM85
pzND1W6btTtjdjgTdeP3ciV1Lo21Tg9VAZ6Cs3U8UzmsA7Q7BAndII82i7tQ
F44X0ZaH96tc5viT0r07HRsv9/v9dMtCGiVUdW7RBp4peHEOdhOtUUzZiZ8k
NkdCueSpkkOFbbybgSVwXHwwvW8Jtj7mVMK50dh+VFDfK/vDhY7j0/ZrSi6u
7Ew2T4cBmA/OO0HPgZifzhczWjw6wNrN9QAzvjn8ITltWQbhldBbkUk4tzlQ
XHAWbdJO6oJCpmQHUR00LcC/AHWsp0VQpQtRN+W1yarrd2DiOXVBVjImYKKk
tHDY/rWSdawp+cKfNZxmaQg8fnyjL9fiuGMdDv6sq8ax9IXqAjFqux+lTEzV
Cu9CuFXAPxqwbyRlREKc8wt4lMm1vYa2pWWyZdR5XYpq/NC2IqQKNHLlInTA
HKU2MhWICimc2QhuTvsdbfRodJtnZRlH0o1RWZEW9Iu18xjfDfvhG8/mvS+q
UFBTrlBYegGE5TnfMMVoSUQpBYSR0quc1B2vZFE6J5dGEloUXaJeKa9TVrT4
LiMkPCEmJlgn87A85lem/NAfDNImT6O0Ndt7cYnUpHXplubUEdvlVw1xaa88
GbRZcRIH6zesdb8NQ8/MTLkl5eg9ZIwieGE0n+HBycbzfIh1dktGQ/7MUql8
JlVqN5UgTHsRV+/b0gvAx1NvCBXH0QzdHUYBJdbkg7LEx8HapR1ft7s5OijM
3/CcuDLHT1r0POe+gkyJqF4s1bHM4U5bnh2XLx8VqmxGqyZP008lu0PRVYu3
fu0HRfcb7KhVxAH2YUH8QUO1u2pdYtlZXPHlQlmSukCr3WRl5ZLyrXwvHiZp
xhdvhdaVl/UluyYto1pXXQ07LpcXplcRkGzATuqZrQtI/1jPW6hS9XZW5WNU
8NuDM0mlwJ3aEKtvhWldOs19yXUQP64Y+zE7HODlWjgJzDtGPCiR2MKbYbaY
TtFJYkAvl5pXFtm0H1VuEzrSQ2+XOy0/elaGGbvjQssKdC/CZ90mOt7bZCEy
QrV70iglWNXe6YnSpinnm18KNQeq58VSZNGlyoBxOQvHD3EGaZE/WE4W+LOE
ra8DD4GoeMg2e79seefSjY71P8t5NPWs+DR0WsGm8XMvVl3dhWbgKPm3ZzRY
FoDUGrBtMFBVURdB9evoTeLQJErH0moja281mwftZrtVzeLxo9n8TqPVqgBP
EU/VtkZMO/3Ahjttb0kIwM/a7a2g1YTNm8ed/9zne+5zUZ7Dz5Jtxpuuh2xy
+0GbXM1cN0/+c4ufYovvxYFeq5KBfkVJvq1zdoYdu4yLZ4U+slpSWOUH4wrB
y6wGq289HcM224tQCA9tJaxywSJ0JaFQQTtHG8hsqmnaS9KCydSREShPcXzt
nBk2TTca2/CvMl7oflGvFqjrTKh3S3to516ljyy50D3Txpa+QRO0q7ZdISSs
yN1fTmFoDen/cUB2z0yRZ+W6zQws3zK5DkwYD/Nt8Iyi0lYCzbM8f3M8azcf
hGfKCPgfB2SPgmcArDV4xs6HX2ovu++PeqL37qj/Y+0f//hHrfbdd9+JjUjm
oyAfXCPhzTZqNTK2DpPBnERwTEoOfDjRuRQx/aK1/Tuhn6i1fP4MPwf4c/bl
Sx0rx0R0Ldpq7LQbmJbeTR+HSYUwvIYr4YZ8ETAL0Y+Con85eZbrYKYnVZmT
nmNO6EUKfCU/wwkG2KIJma+eid3bGmHUriH6WgczQge9+/nz+etuu9XcxaXQ
l4Nm6zl/Oe6/D4573eDF8xfPg1bFs7b/rNVstfbLjw6CncLD3YOD8sO9F7v7
xVFaB82dHdOy1+sF/XwYtHb2d4J2s9mseB7iD2ox7477F8HZh1fB6+OzPjxv
O4/7ZwfNZrBz0K14dlTx7HXp2d5+p/Ss1TzgZzq9KX6DTb+VWGIa+P3naBp+
+UJGqs+fdaoZzslCrTl+yg07ob0+pT0kVP5OvOYjmSESUwkADE+7TazNSZ3Z
zJ6gQ7FBtHqDRt6g87TR0OSI8yxyGCG7d8HJNZ1EjmcD1UQu3rCrUXRqqUIm
bxUXiCcK5Re8jqcQLEq9xdKK9d+ChbIn6BTD0eoclIaXDrqb4tg6dsLKQYUe
FcyUGBsVoObb6iLTyPh20eE5rNVaDdH1SsrrotRZsWi5J6T9IHSNCzLrwjZY
ir9RFxveF7okqlP5K+SJ+GcYJ/FimsyzS+chnF2cCorbOD18BJ2Mk+FGnbeX
I/goddYGR2cWKJiTrjljSMB6Lwh87RKFAxACWSM3CkVCVK4fSo4AqyX4wdJY
TuEpMC+p1XYcwmM9BdQbPZyG/1RlBFA3O4MlIFcXuQbyvG5TjkUjS2nODVW6
Cq/V0DGe6uMyVscimqpyVsaxLfSKfzKu6ds4jJcoLKihKj9b+ktwzsrrn0Z4
86cWyZcGDP2dKuh/PhTfAdEOPBb2RSG2Jg/ziawhu/sH55RgJviq9+b4Xf9H
5jHPvPd/BnLYDppAR3caGOfzrKbzT7itxOf/AlwVfzfOP61G6wd8iGbCbBYO
oON5Gh/ia4fI16bZ4afp5DDODil8yOvuGb05Q++TTygawFd8AIpqGEd/J7j/
F+Llz457F6/JhVJsnrNDfOfC6tl0/odAnfpb4rck/YiE5g3qvDwAKV6DXHX1
2xvxm7w6hD9fan0Zvfu5kG3awAmyqny9jbfB2z/yewLew6If8OLLKRCXPKHL
4p91e92sM4ejl2L3PRTjfk2Aa+sX5A18+3mAYQANIGo/8vQcuUdN8UKRGoS/
PgAOMaJiNJWSIsNPYADFbJFSTuzNwZbAvRUEwgu0DJgCLjPYQzw/TsxKmKke
QlqHEx4ylHDqAcupW7xSzGSK4Z2q/bk0kTE6Pc084yKlyTxVjlIqjQCKc1j4
Giat3ibSDQPOc1y3OaCUrmSGmfowVknM5mmGgVIgqNARVy9ncw5pVrkoJ9FA
Yu4DzPBn84+gl6pK24ACmtQvv+ofwb7yG+iSAXPLxzhtmwJ6oIFgQbihwXQi
r8OJOMMI34xo0TlGRquaFdT+SMlv+o1N30ojLcapiVP5yy0NV/UfoYQ+c1qU
03KfyhOjSySi3+if4FMcEP060tEggJ3Kk5SGxKG24Rk23/qBUrETiKCHKMe7
PT0+JfZFwXVCCwaKiekESpPkomu3STrMxAYGoCI3okDUd+/p7/PeHz8cn/eO
8O/+287JyUZdvcxfdbv+2/cfTo7sX/b97vvTU5DmsQv9JvwmvB9gzM6fNft7
f3Zx/P5d52RDFEVqjeomnp8SyQA9yjnq22Zchzdfdc9EaxfoD8Cm3Wq92NLg
xQcHree7W6R4ad4Dggp/xazrukYaXjdNJurFQTjDXLsZSYTZGK+BURJpPFNk
0CgSljQz/a0gGY6NWSEJ0xbHpmgaavQ4FB3GIKxKyyIlbXPXJNg51zmV2FWb
Ka/ux7N0nmkKnClfJfSI5yl84dWUg7W2+TH0pCVY7FU/rmiNP2j9k4SLVeCg
A6NbW5nVMt3MEXaVVzZl5QIpwSwxJOrjkIIDW/LY9aMyL2AnWM9ToKuCoBRf
wrYzzR7kHoEmWdODLRraDvAHO8iK0qHOdjhwBFX6seFIOXeWwxHms0uA5OUL
o+Kz4AL0+AovfM3rBMwW4Kvj+QGCpNROR+yF8nXQtVt4V5+Tu6K31TXWo7c2
nrj8fcXmdEiPwiwFoA38nYhWWSxQqQ6Ae15N8Lnhmyh6RTdoeQCi3VhOMIz4
eejbQc7lNbL8BXJUNHYIrTPU77EVgLEkH9gNUNIhDxKkapBtnMWlGfxSD47b
tEM3DN5+GEA+DI5LwcilE58KcNVLYPPePWZfcMTmnDuqcA8psxivTVHSeWLP
qK67o0pHpu5pF6xRclfkts5FPZ5+8cYifJ/dU+849Q+eeJYlxfx+p1a/XZ75
0wO4YD6418Ttu2QZefrJKjS8zxzVK9r7DlA5zD7q4DWcubYjPP3sHUPMvZag
Ujapi+MnnmTRpLZioq8oS4x+seCQlS78iIOqsTwprhC/1WrrpdLNQTFgaPms
lBWT1qhNcFgpeQXklgt0XylLeOXd7yypue9fdk7evD8/vnh7enl8ZGroOhLp
Ushaua4AWbyzeTTIroFrIeDgEeF6hxCDatAooF6e9ztLUY9yZpUgRT8VHrSb
7gPnOtB56pz7FdDF+TwBx9rxJD5SVput5w2BIDg+OhTNT81ms7UaVBdHvf7d
jmkJREWAVNKRSTL4KAbRjIpeo5h1E6ZYmJmsCVhuLhObFylV9yZltWf4jtVG
NSDq5r4Aq4pP8Lqw8k3Qy9DvOR1umT444xYWdboKYzYZ6Ui0mxe7T7Ulx/33
28e9rlCXW4Wd2Vm9M/23ndY9sZjuX++K1ZVkAMe04mUgjrB0CickHs7JlhLF
2Xw0igZYs9M32zu6R5JLnezpbXKLl5b6jjPL0bYOcuZozjaJwl2v6YSLXtuu
itb8R2SXSzaNLzQLm7a7etPenna6j056ituqRMkV+0ghbacq3Ajt1pJK/xAc
uygKbuJEt56EKNVLkOQbZLKeqSvoAlD3VgO186QkCk2bOEJBHSzRqScFUTWF
2F8Nl9M3r5dRiDKOrUYpFqVXQImi0dhYiFJ2UCFlPw2Aer0e0POhMK4AXIrJ
fcyeAA3zjgfD56th+Evvz72jt53+20cC5N0Egk7sKlh4s17UDk1gKOCf0vs5
c15mzbR4OYo3MX96f84X+16XYSyIGo3c7mPcPmt+CyeZk3w+VGnZlE6irixj
5S+g+4iT1LyvR4yvH5Mc16t3cok8rHcSofDklPeO9ATn4uzGU+j8O0vwvbNW
qmjv7X89si9bOfQvcIAnF3dXs+lXa6Gwc7D7tFDAAX5nKHTXQmFvqZL+SFDA
AX5nKBythsK7Dycn94dB1Zqpp6dYbPVRbzXXbO/pzuXTnvXTnXKygm+yw4ft
ZuvA3+bWEqOXhcZDz/tdiD72bm8Wrhyt9+nRYI0eed7v9JfaQ9atvdrqsV4B
0cYI0TeVZq1oo2rBkAeJUu4OGm2zuE2e8dkv3X4ruGld7m09vcnEh+gaJQ/m
t1QjeRhAC5b6RwTs8wJge/3gmwLWg+saPQ+md9Z/XMCux9SzcDj0Je9K9Gxp
tBQwxW8NtzV64PtO7+x3Qsc7Qe+5Az2c67cG3xoVsNc9+ub0ser0ssYnJxNs
O8B8IDfStbBh7HC3+2TAMyyWffYLMFyjfAEMH6pBV4NwrUGiLwcpJnsbhyln
s6F8Ed3uU4EHff+FiQcoQOfFWuh0nhLDuGHxonoF8HoKyQJGMrbrlO+qOXHQ
U0FUBwqgS9GE/YKKTtwekNdptqcPVWXuDOJqunhHfIXpBfDLTHK4BJaRwUuw
T3ldR2RgKY+KjbHmkKxMNer0ljU18JZRZRiyHQn5iRMVmk7QpJ4MksnTC6Zr
lPBet999++79+TKzzVPR3krk7w/GcZKmbp2xpwbPGu281z3946/flqZe3CbB
bEyY7sMIE4n8HnR1jer+y9Hr1iW9ewnvfitTeDeJ8UYstskeKFvikxnDV4AL
ZHqqFnCD5HuSyxQndSNbW0b22muA7FqNgO019gOA7iMYh+4G01++LRTp+sBe
HQhaqgZZa6fR9vGwveYS3cHDVvNAw4xW7gJzxfo7RTxiiH0DLMIJB8brZA9E
dZhqYflrTCsgdT0qnbrbHcpZGk2lGEVyMnxKuc+IxRy1WoDMujv8P592j8/e
9h7K4r4CPO+tZxmHFT29feprpLv2GttAt3PaOzk5fiiRv+vFTTecIusLv6HN
uurmt71G48f7i6ez7RaMrUAe8m95s0PE6ezDK4HB3BgiU4DNGnWeYPOvcbuz
DhJrlHKCxL/GDc86SKxRwLvL3XIeRILXKxlMYrtEYpXfxEp/HJzhk5t2OL0D
Xp60nD72fFjuvF4Dy4tH5WZ3tzV2kzkG8ZE/+re4Z9r34bK7Rlx+//qVJ/k9
9vLfczG+11IOr0LArd8LDGtk4e6rRz1p90APdjJlj9PuOIzIhPV7QWmNyNy1
yPK7QOl3x6I1gnOv+zvBp4c1ntMkBikZCfNVkvx+MFpzDdntnj4dT3sgbSbX
ycqTGFSzPwMIxQa7p0/GBR2ld+eg68N6bw1xf/NPBOs34SSJsm0N8lMC3Jtv
BbijAuDWmUZ++6eBG17ao53ptzScic1ffvs28CrYUvbWMIZffnvoVe4TA4xO
tr7uBeg93S3uSvCt4xudP/3zgM8SOjkMnPCU0yfkJyuBt4ah9I6+/UV4DysG
DjN1z3AUXWPiDMe5xa5/8wy+94YwxSf2H9gpKJf7ljeUcg7+o1bD0CJ2lsbw
FMwWtSyZFWYjMcmodBbXq4X4d06dNMOQeMzD4eY1ppRN/96wYTRoiqF0LU65
Yky4sCSrFOeyglklt3o4PMP4GsCZkoT4yb4wj5o47rzrYKnmDHBEFbUtJlLk
6H2sjEwzSnAEcg832aI+nB+r9Gqy9vnzp+nERPxjXjzOG0F5CHf2Dw6+fDms
1eCNw9qhWJ9lqhJUWAxa7TNmEupybihMqHxI+WuOe/03DWz0p9MTfvpuu0N5
25za2TAFKuIUYyu7mMY9JqdSYD3xdO64HU4iIbMZehsA+pTwi1Yi8WW7MSah
xy6jFGzTfrPdpG3C8rQIijV78U7Pllf3Fbt6RnnEuBtoxZBVR5+fDtNwlHPe
NCr0ROvCDgfjME1DTuWDiUi2itN3duveE3be9aYYhl85xe8Q/vMUiXP5FEo/
O9Qa2qGPN7tkeUmSTAaykN0GQiJKnD1CBX8AyQZSzIWiCvVMRCzz2yT9iEVm
QK6nDrVvQWaC8t/1Lrrv371WGNTebQGKwSDnvb7z/KC5C5jFWfUAbzFVhX5v
Ei4AGyNdE3hAmW3gQGWUmYZ+rZusZ6bcTZAngcnyV34Nuuvzs/4Y83Vu9vtv
t8wU24WpmLmauby9uDjrP2jYi5O+WvLu7j7l/LM5KkNVT5lqseMmcIV3x6Gu
lBqMMxrCu1iNETnA9iAFpk1/DeVEckD3ZtSQjbr4XlUJwlJA39dVBsXIK+G4
1eAQI3d8lYJxoPAQk3BI+BPvmXEnb+YTjATDcSgj3FQaxJDxTQSqNKVIa4AU
iYWTbZV0sSkb1zgtTFoW8Ny+31Kp3vwp6ARygF5Im5ygUKyzMw5vCHjymi6/
hRyN8OYLftUTcUqzq/VxTlAqdp+nEo8A7KUzopPJFZpFqVkzHMltveRoAt+A
HnZN+veN7SVl5raXlpOD93VGzYp02ZjwLDcZx9W3ysTaOieazRu9wVn9BlTB
FHZwlszmE1Mqx80vb9DIqUJny6HOY9j2CSV/0EWb6WYvioHOUBi2akgpbgn1
b6i6Coyv/tJ1VAESOOecmisA4o6bGqwwmB3fzrDhAPlwBZQxH7aCKPLKjUOA
AKLO9VilYYP93EhvN0w0cqHeNaEHUPIkldTEln9lADr5mQHxGK0Sjp0bDvE0
IBEmbEQAqRqe0iyPqbLecKcaJ0z02E8B7QGFSt5RhB+XuItMAlS9aVzSz1SV
vFropWXJKMcE4A1Vo5nWM49jiYQ8TKMJhxDidHW+poxn6NazqpzfTKdG9Is0
qZmZqoY2SzDBKfayy+miE1xQo3P8y5abEVklbqurcMZSAY5OuTleN+NwUhU7
bIjjWDEjIBYZbCumDsjUVM7PulrYMkm8K0sYDTT6Yp1bGE557MWJSFUmPfa4
M98Uisxj+Qnnosqh12o4ojrRA5ONT7/lMm9G4wuSBgcS1qIzNqtJq3GowiX8
GI0WfIwJ35yZR5meC9d/FABkwG3iCMW2mBz9SsqYUS+d6kzHAJd0SEkoMX2Z
QjZdeVFniXN3J+ENycP0Wqq140Y66wfk/73W7y3fSfelV22yAuPvVIfPcbx0
0M2bx11ARzLUJOEMouS2Sag/AXE8j2BYrH2moQqkhfLmrYMq4LuG6iS5BkgC
fZU34YTBd25xOwTxBd4TN8kEhD9cHrTPLI3SebQNqpOeyho8ghIFGiYphk4Q
wyGBQ1Ix+BiTVELHmD42YiXlOMZV8PRBLpzwUcjHKdFkBUXo6Aqpph75RkI/
tJnmLKrUl5S0VpM0Ht4lrZyKOR7OkgjzMqvsaNipzmAkXN6NefsIpgnZf3Bx
mccBaG6KB1yZZBS8te86aBImUW6HpFqVi08Xw85knqt6jjD2IkDDAGbwj6YR
I6lDyzEDtbPPJIdcLVRGOsrWS8mifkU0jwASANnXKidjWRVQSgkJ/3UBwiga
YpDGD0hQxAoSmcSNiKxy4KUapkMHAEyh1wEVj9SecSXjwji6Hk84azDvF4p/
jmBhYeeIj5hndrBgcQVTYYEgEw8zm5UblVj8LRwmM/oyhM265tKoiNpzwjeT
Bj5yUExrHddYoZwEz3CClRWHc5Q78G/qeBAO5ZQKJGQyTOGVK9pwBy6hE7St
TTWIz0EQCLw3IyMJTPWadLRTgDEQBxJ93HySYvP4tAOKxXdYCwAOw2lHsWhd
9TOKB5jAhvBWdTIUrxLgmgBnmwBT1RFQOov6/UPv9XHAjwJ8BI1UmuSTKJ5/
0kIvbjKhdh1T1bIYF1FG5WID+t3kfMcBMZs4IBvO29A3nYrYDhQZOIA0rbry
GnyEvZATICVYJrDdbL4Qm+qRTnvcbuw3dpqsfQgcbirRaz3KkNqoCgJWzvRw
Pva5dqhzxaQAEq01SVEYb6/R2sd6Eqed4Bf6JegTSUONjHYpRtQytVlzi/9q
fXbNVwtN2MgwbjIUkW0yZc0ZYDel3YUmWwRZLHFI19MWc0AhUlmNupMwmmpr
jY4SwMFNrvQtKv6Au6NRV34CTOAzkBhGSJ63zgCqKilVfkZNAFVnS9bnQCEx
dADGZVuCR5RMJnaFEEC6aIqa/asdR3fkMMqYEfRukO7Cpm8qZTNWNW+dWanV
biEgVXkTBIwxnohfKTEaQYz300i5lOwe5kipyUlsPb7bfOqMY6BOoEpB5rUk
VcQJi3JsEi0H4W445xMhM4K4B0yqNUq4QzYjFif6PEuXIJwkgBb905OtOgsi
wAd452iXSHmlgzXV57+8o3RwsPvSkb3VVYdBd6kZXQdX5+611p9JLdG6T76Y
oSrHCgABFjDtr7qcmuJmVPUBhZXBWDEci/kKwrA0roU8DtMh1RqyfFKZQHDv
8OoXq/Zh71oAM9mBuy4XV1ZTpPybqPlssaah9BpMP80YqJ5m7iyuEpi2ykVP
9YH73eNjS0MUbVMni6lTpi1thE4Krt/rp6Pse7H579sZ1lal3d7Wv2wDUd/+
960G03V4CcuuGXuNMsMiY3IApRfOx4F8lzNVlYNOxpAhCZIZccYUNrX3KZwS
i8BmNEWsBFvnP1HNr+P+peL4qC4oxR79xWvRUiuzveXnhvAFWHemtx3T5cOs
AWra+qTXp9akODSmj6G7BbQhDoDJJlPVQK801EAgASDTIpHtjmHgGR1gOo3a
hW4xJ68BD2GHaKye0rygOdbUAehccy5+AE+mKttbwk9nQ0dHYLkZZ3cGxOsz
sm8iCgdcHArwPNFL4k4UoOxOM4s0e0jwZe3Y5zqqTAIVWqh1MlYTQUasAxND
O1QBFrp29HBo+ddoTpmxGddmyQTzrxlU09ikscRQEg6KzBVPpdeAyIJcOAeQ
Nmqv5tEkD2AE06EaWoEQWb4P2wJQuwweb06qC403CZKuIXE+zWFQU66AdehD
G4A9QhKsZh0ZQ2gdn3qUmIx54UfJtSlwNtCarYC03SBAZsjP4TTVOipd8hi3
6ka6d5K2IAblptTbAfBhvFH0Avu/OPnVRZ8rRKZ5PLTlXUC8UL11MaySbGa9
G8MOur2TrYLI8vnzQE605Rl+L/xMGBpNJijIqhJNLNU7h4n2h0UXe9gB2AxX
UiH8yWduNQyQiUAKI8EWGiGreqfMpz1j1yPR8wT1xs/flWta1Wr6DWsJRPCw
eQ0PrmMcBz0IFFIcy+EX9q4UVqKtcgUhScsLoDPOWZMiJFVZTrmaz5BKmjLV
Y3j4tarK8k2jtmq1gDNXmqi7sgsOACu/VlSNJoL4lcSMmFgvosiynd83mcez
rGkE7i19HvD0TiRxAyLZxBsU2rFCi2ilzqTaNPit4VxJO3SOuDxuq56wu5CK
yRvJmiJK4QzBgUodgwG1130xVl4vnMIaQDAlJ3Es3jsBkh0xRajaPXymDfe8
j5qX0NCvjt/39ZolwndULRmpMjWpls6s3MVAhxmqo2vIpd5NS3ZJKlRDRKkV
yRq131CPxiZaKVeVpzmn+jL5OTO3HmXjV9VLYfn6RwNxq+5Byp44pISZthWl
yUTVX7cGHjKbhCTu3ciFhqVZh9I+bGr5KCsjPuKkf0dSOGEguKmUxmJTi91b
fDjZEHrhjkk8mCV1WZAyUaMCITxEPkLSCRf68bWDLVODy2wunRhSzqYzThEQ
5Znda06Fv6xD4I3ksq+gaEVxQoi6DzCGJWY5RjMYLrzQm9i8Qn0QaPRCIz3A
b0vZr3B6Uqnk+FNRd1D7kVyZYkdlQR3fw4GNwkVKZ4b4xphLyZhvsQASXvgq
OU/ZyZU1EkHOHEPflgFxQUREsaNM2OfZnEi6AjiAFiQaysbr0xC8PAdMn6gL
iHGCPBXvBUhLHlo6UDrBmBmaL53Ibn+FCgxyQVASY/dFoghMRbAlnE0GSZSV
UNaYFeoVBwf3EQ/PirNTZ6WDLbgeEpBhtgBkLDSYZx6Ba9Q+GJmsMLm6te/R
VDDxLhyHiU2/LqYw8zAfjLEHXA48TiNm+1GMSRxnCUouEW1MDnoDqbR2PxrK
a8RaVwigSvhGUg/cMo0SdfqpXtdCUU0FFENFzJ0hGn3QzMz2OX38hkUCT2Hl
ivjNZ0Pa6e2ZWg1p/xlKBwvzo1HfEyBBKAaUTAJR7DxzrHGwtBFMUq2C7YMO
cFlwGCe3HlWkyzEAVIZi4v8P1rRGnYZfAQA= [rfced] FYI, we have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed.  Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: "native".
-->
</rfc>