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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

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

<rfc ipr="trust200902" docName="draft-xia-rats-pubsub-model-02" category="std">

  <front>
    <title abbrev="RATS Push">Using NETCONF Pub/Sub Model for RATS Interaction Procedures</title>

    <author initials="L.X." surname="Xia" fullname="Liang Xia (Frank)">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhuatai District,</street>
          <city>Nanjing, Jiangsu</city>
          <region></region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>frank.xialiang@huawei.com</email>
      </address>
    </author>
    <author initials="W.P." surname="Pan" fullname="Wei Pan">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhuatai District</street>
          <city>Nanjing, Jiangsu</city>
          <region></region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>william.panwei@huawei.com</email>
      </address>
    </author>

    <date year="2020" month="February" day="27"/>

    <area>Security</area>
    <workgroup>Remote ATtestation ProcedureS</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This draft defines a new method of using the netconf pub/sub
model in the RATS interaction procedure, to increase its flexibility,
efficiency and scalability.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Remote attestation is for acquiring the evidence about various
integrity information from remote endpoints to assess its
trustworthiness (aka, behave in the expected manner). These evidence
should be about: system component identity, composition of system
components, roots of trust, system component integrity, system component
configuration, operational state and so on.
<xref target="I-D.richardson-rats-usecases"/> describes possible use cases
which remote attestation are using for different industries, like:
network devices, FIDO authentication for online transaction,
Cryptographic Key Attestation for mobile devices, and so on.</t>

<t><xref target="I-D.ietf-rats-architecture"/> lays a foundation of
RATS architecture about the key RATS roles (i.e., Relying Party,
Verifier, Attester and asserter) and the messages they exchange, as well
as some key concepts. Based on it,
<xref target="I-D.birkholz-rats-reference-interaction-model"/> specifies a
basic challenge-response-based interaction model for the remote
attestation procedure, which a complete remote attestation procedure is
triggered by a challenge message originated from the verifier, and
finished when the attester sends its response message back. This is a
very generic interaction model with wide adoption. This document
proposes an alternative interaction model for Remote attestation
procedure, by customizing the NETCONF pub/sub model
<xref target="RFC8639"/><xref target="RFC8640"/><xref target="RFC8641"/>. YANG push <xref target="RFC8641"/> is 
basically an extensive NETCONF pub/sub model mainly for the YANG datastore.
With the nature of asynchronous communication, the pub/sub model for
remote attestation procedure is optimal for large-scale and loosely
coupled distributed systems, especially for the network devices, which
has the advantages as: loose coupling, scalability, time delivery
sensitivity, supporting filtering capability, event-driven and so on. The pub/sub
model can be used independently, or together with the challenge-response
model to complement each other as a whole. Note that in which way these
models are combined together are currently out of the scope of this
draft.</t>

<t>In summary, by utilizing the pub/sub model in remote attestation
procedure, the gained benefits are as below:</t>

<t><list style="symbols">
  <t>Flexibility: the verifier does not need to send the challenge
message every time. The whole thing of the verifier is to subscribe a
topic to the attester and then to anticipate the period or timely
on-change notification from the attester about its integrity
evidence.</t>
  <t>Efficiency: once the verifier has subscribed its interested
topics related with its triggering condition to the attester, it
will get all the condition triggered notifications on time, which are
the integrity related evidence for remote attestation in fact. It
will ensure any integrity change/deviation of the remote endpoint to
be detected with the minimum latency.</t>
  <t>Scalability: it will save a lot of challenge messages by
replacing with single subscription message for one topic stream, and
decrease the total number of stateful connection between the
verifier and attester, especially for a very large scale network.
Thus, the scalability of the solution will increase.</t>
</list></t>

<t>This document is organized as follows. Section 2 defines conventions
and acronyms used. Section 3 discusses pub/sub model of remote
attestation procedure.</t>

</section>
<section anchor="conventions-used-in-this-document" title="Conventions Used in This Document">

<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<t>This document uses terminology defined in
<xref target="I-D.ietf-rats-architecture"/> and
<xref target="I-D.birkholz-rats-reference-interaction-model"/> for security related
and RATS scoped terminology.</t>

</section>
<section anchor="pubsub-model-for-remote-attestation-procedure" title="Pub/sub Model for Remote Attestation Procedure">

<section anchor="solution-overview" title="Solution Overview">

<t>The following sequence diagram illustrates the reference remote
attestation procedure by utilizing the NETCONF pub/sub model defined
by this document.</t>

<figure title="Figure 1: Pub/sub model of Remote Attestation"><artwork align="left"><![CDATA[
[Attester]                                                      [Verifier]
    |                                                               |
    | <--Sub(nonce,authSecID,assertionSelection, event/period)      |
    |                                                               |
collectAssertions(assertionSelection)                               |
    | => assertions                                                 |
    |                                                               |
signAttestationEvidence(authSecID, assertions, nonce)               |
    | => signedAttestationEvidence                                  |
    |                                                               |
    | signedAttestationEvidence ----------------------------------> |
    |                                                               |
    | verifyAttestationEvidence(signedAttestationEvidence, refAssertions)
    |                                          attestationResult <= |
    |                                                               |
    | ............................................................. |
    |                                                               |
collectAssertions(assertionSelection)                               |
    | => assertions                                                 |
    |                                                               |
signAttestationEvidence(authSecID, assertions, nonce)               |
    | => signedAttestationEvidence                                  |
    |                                                               |
    | signedAttestationEvidence ----------------------------------> |
    |                                                               |
    | verifyAttestationEvidence(signedAttestationEvidence, refAssertions)
    |                                          attestationResult <= |
    |                                                               |
    | ............................................................. |
    |                                                               |
    |                                                               |
    |on-change/event happens                                        |
    |     |                                                         |
    |    \|/                                                        |
collectAssertions(assertionSelection)                               |
    | => assertions                                                 |
    |                                                               |
signAttestationEvidence(authSecID, assertions, nonce)               |
    | => signedAttestationEvidence                                  |
    |                                                               |
    | signedAttestationEvidence ----------------------------------> |
    |                                                               |
    | verifyAttestationEvidence(signedAttestationEvidence, refAssertions)
    |                                          attestationResult <= |
    |                                                               |
    | ............................................................. |
]]></artwork></figure>

<t>In short, the basic idea of pub/sub model for remote attestation is
the verifier subscribes its interested event streams about the
integrity evidence to the attester. The event streams can be in the 
YANG datastore, or not. After the subscription succeeds,
the attester sends the subscribed integrity evidence back to the
verifier. During subscription, the verifier may also specify how the
attester returns the subscribed information, that is, the update
trigger as periodic subscription or on-change subscription. And when
the selection filters are applied to the subscription, only the
information that pass the filter will be distributed out.</t>

<t>More detailed, the key steps of the remote attestation workflow
with this model can be summarized as below (using the network devices
as the example):</t>

<t><list style="symbols">
  <t>The verifier subscribes its interested event streams about the
integrity evidence to the attester. More specifically:  <list style="symbols">
      <t>The event stream here refers to various integrity evidence
information related to device trustworthiness, which can 
be in YANG datastore, or not. The basic event
streams may include: software integrity information (including
PCR values and system boot logs) of each layer of the trust
chain recorded during device booting time; device identity
certificates &amp; Attestation Key certificate; operating
system, application dynamic integrity information (e.g., IMA
logs) and the device configuration information recorded during
device running time.</t>
      <t>Periodic subscription is mainly used by the verifier for
the general and non-critical information collection, which are
not strictly time sensitive and aims for collecting the latest
integrity evidence and checking the possible deviation. In
contrary, on-change subscription is basically used to to
monitor the critical integrity evidence (e.g., integrity
values and log files during device booting time, or integrity
values of some key service processes). If these integrity
values change, notifications are sent immediately.</t>
      <t>The selection filters may be applied to the subscription,
so that only the event records that pass the filter will be
distributed out. Some specific examples include: event records
of a component (e.g., line card) in the composite device, the
event records in a specific time period that includes a start
time and an end time, and so on.</t>
    </list></t>
  <t>Consider how to send the existing parameters (i.e., nonce, hash
signature algorithm, and specified TPM name, etc.) carried in the
challenge message of the previous challenge-response model to the
attester through the subscription message of the new sub/pub model
in advance, and the follow-up usage of them. A very important
point is how to ensure that the nonce carried in every
notification message is different, and both the attester and the
verifier know the correct value in advance.</t>
  <t>Both configuration subscription and dynamic subscription are
considered. More specifically:  <list style="symbols">
      <t>Configure subscription is for the important security event
stream. For example, it enables the monitoring the important
integrity information by using the on-change mode.</t>
      <t>Dynamic subscription is for the normal integrity
information, that is, periodically receive those related
information during NETCONF Session. The corresponding
subscription RPC needs to be established dynamically. This way
can reduce unnecessary NETCONF sessions.</t>
    </list></t>
  <t>In addition to the update trigger of on-change, the other
possible update trigger may be certain pre-defined events
according to <xref target="I-D.bryskin-netconf-automation-yang"/>,
that is: When these events occur, the specified integrity
information is triggered to be sent, which is the relevant event
stream plus optional selection filter. The events may include:
device startup completion, device upgrade completion, specific
attack event, active/standby switchover, line card
insertion/removal/switchover, certificate life cycle event
(expiration), etc.</t>
  <t>The attester notification delivery mechanisms thus vary as the
above subscription mechanisms of verifier vary.</t>
</list></t>

<t>The following sections describes the above key steps one by one.</t>

</section>
<section anchor="remote-attestation-event-stream-definition" title="Remote Attestation Event Stream Definition">

<t>The event streams here refers to various integrity evidence
information related to device trustworthiness. By definition, 
evidence is typically a set of claims about device’s software and hardware 
platform. So, the remote attestation event stream is composed by the claims.
For remote attestation, the basic event streams may generally include: 
system integrity information (including PCR values and
system boot logs) of each layer of the trust chain recorded during
device booting time, device credentials and their change, 
operating system and files integrity information (e.g., IMA logs) recorded 
during device running time, and so on.</t>

<t>The event streams are created and managed by the attester. And
their formal definition should be conformed to the information model
definition like Attestation Evidence or others in
<xref target="I-D.birkholz-rats-information-model"/>, and the claim data model
definition in <xref target="I-D.ietf-rats-yang-tpm-charra"/> with YANG data
format, and <xref target="I-D.ietf-rats-eat"/> with COSE data format.</t>

<t>More specific, for current RATS claims YANG data model in  <xref target="I-D.ietf-rats-yang-tpm-charra"/> ,
the following event streams may be defined if necessary:</t>

<t><list style="symbols">
  <t>the rats-support-structures datastore node, or its subtree nodes like: tpms, compute-nodes. 
All these nodes can be subscribed for pushing their values periodically or on-change;</t>
  <t>For all the YANG RPCs,  whether their output are the YANG datastore nodes or information
stored in the device with other way, the event streams can be defined for all of them, such as: 
tpm12-attestation-response, tpm20-attestation-response, attestation-certificates and system-event-logs. If needed, the more fine-grained event stream can be defined for the substructure of the above, like: endorsement-cert or attestation-cer of the attestation-certificates, bios-event-logs or ima-event-logs of the system-event-logs.</t>
</list></t>

</section>
<section anchor="remote-attestation-subscription-definition" title="Remote Attestation Subscription Definition">

<t>NETCONF pub/sub model provides several subscription types in which
approriate one or more types are chosen and possibly used together to
meet the service requirements.</t>

<t>Particularly, periodic subscription is mainly used by the verifier
for the general and non-critical information collection, which are not
strictly time sensitive and aims for collecting the latest integrity
information and checking the possible deviation. In contrary,
on-change subscription is basically used to monitor the critical
integrity evidence (e.g., integrity values and log files during device
booting time, or integrity values of some important files). If
these integrity values change, notifications are sent immediately.</t>

<t>Besides, both configuration subscription and dynamic subscription
are considered. In which, configure subscription is for the important
security event stream as it lasts even the NETCONF session is closed.
For example, it enables the monitoring of the status of important
security event stream by using the on-change mode. On the other hand,
dynamic subscription is for the general security event stream, that
is, periodically receive those related information during NETCONF
Session. The corresponding subscription RPC needs to be established
dynamically. This way can reduce unnecessary NETCONF sessions.</t>

<t>For the remote attestation event streams described in the previous section,
some relatively critical and not frequently changed ones can be subscribed 
as the configuration and on-change subscription, so that the verifier can 
always receive them very timely. Some examples are: tpms, compute-nodes and 
attestation-certificates event streams. In contrary, some normal and frequently changed event 
streams can be the dynamic and/or periodic subscription, the verifier just want 
to receive and monitor them occasionally and reduce the processing. 
One example is ima-event-logs event stream.</t>

<t>Furthermore, certain pre-defined events according to 
<xref target="I-D.bryskin-netconf-automation-yang"/>, can be the update trigger
too, that is: When these events occur, the specified integrity
information is triggered to be sent, which is the relevant event
stream with optional selection filter. The events may include: device
startup completion, device upgrade completion, specific attack event,
active/standby switchover, line card insertion/removal/switchover,
certificate life cycle event (expiration), etc.</t>

</section>
<section anchor="remote-attestation-selection-filters-definition" title="Remote Attestation Selection Filters Definition">

<t>The selection filters may be applied to the subscription, so that
only the event that pass the filter will be distributed out. Both the pub/sub
and the YANG push selection filters can be considered.</t>

<t>A concrete example of selection filter is limiting the delivered
event stream to those originated from a specific component with id
(“xxxxxxxxxx”) of a designated vendor (“xxx-vendor-device”).</t>

<t>The other example is filtering the event records in a specific time period 
that has a start time and an end time.</t>

</section>
<section anchor="remote-attestation-subscription-parameters-handling" title="Remote Attestation Subscription Parameters Handling">

<t>Most of the parameters carried in the subscription message are not
changed during the remote attestation procedure, like: hash signature
algorithm, specified TPM name and so on. Their main goal is to enable
the dynamic negotiation with the attester about what information the
verifier needs and how to construct them together. A very important
point is how to ensure that the nonce carried in every notification
message is different, and both the attester and the verifier know the
correct value in advance. For this purpose, the basic idea is to
ensure that the nonce in two sides of the communication is
synchronously changed, and the randomness of the nonce is maintained.
Specifically, there may be several ways to do it:</t>

<t><list style="symbols">
  <t>Verifier sends a seed with hash algorithm to the attester in
the subscription message, and then perform the synchronization
operation on both sides.</t>
  <t>In fact, the nonce does not need to be random every time. As
long as the receive endpoint (here for verifier) can identify
duplicated packets, other means may be used. For example: The
timestamp and increasing count.</t>
  <t>The RATS TUDA mechanism <xref target="I-D.birkholz-rats-tuda"/> can also be used
here to ensure the freshness of information.</t>
</list></t>

</section>
<section anchor="remote-attestation-notification-distribution" title="Remote Attestation Notification Distribution">

<t>Basically, the remote attestation notification is the event stream in the YANG notification structure, 
and the event stream is defined above with the same YANG structure as the corresponding the YANG datastore node or RPC’s output.</t>

<t>More details are to be added.</t>

</section>
<section anchor="summary" title="Summary">

<t>Based on the above discussion, this section gives some examples to
illustrate the overall application of sub/pub model to remote
attestation procedure.</t>

<t>Below is a configured subscription example with on-change update
trigger, with specific contents as:</t>

<t><list style="symbols">
  <t>There are 3 integrity evidence related event streams as
follows: pcr-trust-evidence, bios-log-trust-evidence and
ima-log-trust-evidence. The subscribed one is
pcr-trust-evidence.</t>
  <t>The other parameters of the subscription include: pcr-list:
{{1, 3, 7}}, tcg-hash-algo-id: TPM_ALG_SHA256, nonce-value:
0x564ac291, TPM_ALG_ID-value: TPM_ALG_ECDSA, pub-key-id:
0x784a22bf, tpms: {“tpm1”}.</t>
  <t>The selection filter is set as follows: a specific component
with id (“xxxxxxxxxx”) of a designated vendor
(“xxx-vendor-device”).</t>
</list></t>

<figure title="Figure 2: Configured On-change Subscription Message"><artwork align="left"><![CDATA[
<edit-config>
    <subscriptions
           xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
        <subscription>
            <id>100</id>
            <stream>pcr-trust-evidence</stream>
            <stream-subtree-filter>
                <xxx-vendor-device
                      xmlns="urn:xxx:params:xml:ns:yang:xxx-vendor-device ">
                    <device-id>xxxxxxxxxx</device-id>
                </xxx-vendor-device>
            </stream-subtree-filter>
            <pcr-list>
                <pcr>
                    <pcr-indices>1</pcr-indices>
                    <pcr-indices>3</pcr-indices>
                    <pcr-indices>7</pcr-indices>
                    <hash-algo>
                        <tcg-hash-algo-id>TPM_ALG_SHA256</tcg-hash-algo-id>
                    </hash-algo>
                </pcr>
            </pcr-list>
            <nonce-value>0x564ac291</nonce-value>
            <TPM_ALG_ID-value>TPM_ALG_ECDSA</TPM_ALG_ID-value>
            <pub-key-id>0x784a22bf</pub-key-id>
            <tpms>
                <tpm-name>tpm1</tpm-name>
            </tpms>
            <yp:on-change>
                <yp:dampening-period>100</yp:dampening-period>
            </yp:on-change>
        </subscription>
    </subscriptions>
</edit-config>
]]></artwork></figure>

<t>Below is a dynamic subscription RPC example with periodic update
trigger, with specific contents as:</t>

<t><list style="symbols">
  <t>There are 3 integrity evidence related event streams as
follows: pcr-trust-evidence, bios-log-trust-evidence and
ima-log-trust-evidence. The subscribed one is
bios-log-trust-evidence.</t>
  <t>The other parameters of the dynamic subscription include: tpms:
{“tpm1”}, last-entry-value: 0xa34568baac79, log-type: bios,
pcr-list: {{2, 4, 8}}, tcg-hash-algo-id: TPM_ALG_SHA256.</t>
  <t>The selection filter is set as follows: a specific component
with id (“xxxxxxxxxx”) of a designated vendor
(“xxx-vendor-device”).</t>
  <t>Subscription period: 500 centiseconds.</t>
</list></t>

<figure title="Figure 3: Dynamic Periodic Subscription Message"><artwork align="left"><![CDATA[
<rpc netconf:message-id="101"
       xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
    <establish-subscription
          xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
        <stream>bios-log-trust-evidence</stream>
        <stream-subtree-filter>
            <xxx-vendor-device
                  xmlns="urn:xxx:params:xml:ns:yang:xxx-vendor-device ">
                <device-id>xxxxxxxxxx</device-id>
            </xxx-vendor-device>
        </stream-subtree-filter>
        <tpms>
            <tpm-name>tpm1</tpm-name>
        </tpms>
        <last-entry-value>0xa34568baac79</last-entry-value>
        <log-type>bios</log-type>
        <pcr-list>
            <pcr>
                <pcr-indices>2</pcr-indices>
                <pcr-indices>4</pcr-indices>
                <pcr-indices>8</pcr-indices>
                <hash-algo>
                    <tcg-hash-algo-id>TPM_ALG_SHA256</tcg-hash-algo-id>
                </hash-algo>
            </pcr>
        </pcr-list>
        <yp:periodic>
            <yp:period>500</yp:period>
        </yp:periodic>
    </establish-subscription>
</rpc>
]]></artwork></figure>

<t>Below is a configured subscription RPC example with pre-defined
events as the update trigger, with specific contents as:</t>

<t><list style="symbols">
  <t>There are 3 integrity evidence related event streams as
follows: pcr-trust-evidence, bios-log-trust-evidence and
ima-log-trust-evidence. The subscribed one is
pcr-trust-evidence.</t>
  <t>The other parameters of the subscription include: pcr-list:
{{1, 3, 7}}, tcg-hash-algo-id: TPM_ALG_SHA256, nonce-value:
0x564ac291, TPM_ALG_ID-value: TPM_ALG_ECDSA, pub-key-id:
0x784a22bf, tpms: {“tpm1”}.</t>
  <t>The selection filter is set as follows: a specific component
with id (“xxxxxxxxxx”) of a designated vendor
(“xxx-vendor-device”).</t>
  <t>The event which triggers the intergrity evidence delivery is
defined as: id: 1001, type: master-slave-swithover</t>
</list></t>

<figure title="Figure 4: Configured Event-triggered Subscription Message"><artwork align="left"><![CDATA[
NO FIGURE YET
]]></artwork></figure>

</section>
</section>
<section anchor="the-yang-module-for-subpub-model-remote-attestation-procedures" title="The YANG Module for Sub/pub Model Remote Attestation Procedures">

<section anchor="tree-format" title="Tree Format">

<t>To be written.</t>

</section>
<section anchor="raw-format" title="Raw Format">

<t>To be written.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>To be written.</t>

</section>
<section anchor="IANA" title="IANA Considerations">

<t>To be written, possibly.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC8639" target='https://www.rfc-editor.org/info/rfc8639'>
<front>
<title>Subscription to YANG Notifications</title>
<author initials='E.' surname='Voit' fullname='E. Voit'><organization /></author>
<author initials='A.' surname='Clemm' fullname='A. Clemm'><organization /></author>
<author initials='A.' surname='Gonzalez Prieto' fullname='A. Gonzalez Prieto'><organization /></author>
<author initials='E.' surname='Nilsen-Nygaard' fullname='E. Nilsen-Nygaard'><organization /></author>
<author initials='A.' surname='Tripathy' fullname='A. Tripathy'><organization /></author>
<date year='2019' month='September' />
<abstract><t>This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams.  Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.</t></abstract>
</front>
<seriesInfo name='RFC' value='8639'/>
<seriesInfo name='DOI' value='10.17487/RFC8639'/>
</reference>



<reference  anchor="RFC8640" target='https://www.rfc-editor.org/info/rfc8640'>
<front>
<title>Dynamic Subscription to YANG Events and Datastores over NETCONF</title>
<author initials='E.' surname='Voit' fullname='E. Voit'><organization /></author>
<author initials='A.' surname='Clemm' fullname='A. Clemm'><organization /></author>
<author initials='A.' surname='Gonzalez Prieto' fullname='A. Gonzalez Prieto'><organization /></author>
<author initials='E.' surname='Nilsen-Nygaard' fullname='E. Nilsen-Nygaard'><organization /></author>
<author initials='A.' surname='Tripathy' fullname='A. Tripathy'><organization /></author>
<date year='2019' month='September' />
<abstract><t>This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.</t></abstract>
</front>
<seriesInfo name='RFC' value='8640'/>
<seriesInfo name='DOI' value='10.17487/RFC8640'/>
</reference>



<reference  anchor="RFC8641" target='https://www.rfc-editor.org/info/rfc8641'>
<front>
<title>Subscription to YANG Notifications for Datastore Updates</title>
<author initials='A.' surname='Clemm' fullname='A. Clemm'><organization /></author>
<author initials='E.' surname='Voit' fullname='E. Voit'><organization /></author>
<date year='2019' month='September' />
<abstract><t>This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore.  Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.</t></abstract>
</front>
<seriesInfo name='RFC' value='8641'/>
<seriesInfo name='DOI' value='10.17487/RFC8641'/>
</reference>



<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.richardson-rats-usecases">
<front>
<title>Use cases for Remote Attestation common encodings</title>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='C' surname='Wallace' fullname='Carl Wallace'>
    <organization />
</author>

<author initials='W' surname='Pan' fullname='Wei Pan'>
    <organization />
</author>

<date month='November' day='4' year='2019' />

<abstract><t>This document details mechanisms created for performing Remote Attestation that have been used in a number of industries.  The document initially focuses on existing industry verticals, mapping terminology used in those specifications to the more abstract terminology used by the IETF RATS Working Group.  The document aspires to describe possible future use cases that would be enabled by common formats.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-richardson-rats-usecases-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-richardson-rats-usecases-06.txt' />
</reference>



<reference anchor="I-D.ietf-rats-architecture">
<front>
<title>Remote Attestation Procedures Architecture</title>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='D' surname='Thaler' fullname='Dave Thaler'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='N' surname='Smith' fullname='Ned Smith'>
    <organization />
</author>

<date month='February' day='4' year='2020' />

<abstract><t>In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence.  The evidence is typically a set of claims about its software and hardware platform.  This document describes an architecture for such remote attestation procedures (RATS).</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rats-architecture-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rats-architecture-01.txt' />
</reference>



<reference anchor="I-D.birkholz-rats-reference-interaction-model">
<front>
<title>Reference Interaction Models for Remote Attestation Procedures</title>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='M' surname='Eckel' fullname='Michael Eckel'>
    <organization />
</author>

<date month='January' day='7' year='2020' />

<abstract><t>This document defines interaction models for basic remote attestation procedures.  Different methods of conveying attestation evidence securely are defined and illustrated.  Analogously, the required information elements used by conveyance protocols are defined and illustrated.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-birkholz-rats-reference-interaction-model-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-birkholz-rats-reference-interaction-model-02.txt' />
</reference>



<reference anchor="I-D.birkholz-rats-information-model">
<front>
<title>An Information Model for Claims used in RATS</title>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='M' surname='Eckel' fullname='Michael Eckel'>
    <organization />
</author>

<date month='January' day='8' year='2020' />

<abstract><t>This document defines a standardized information model (IM) for Claims that can be used in remote attestation procedures (RATS).  The information elements defined include attestation Claims which provide information about system components characteristics, as well as commonly used attributes and attribute structures that are required by protocols facilitating remote attestation.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-birkholz-rats-information-model-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-birkholz-rats-information-model-01.txt' />
</reference>



<reference anchor="I-D.ietf-rats-yang-tpm-charra">
<front>
<title>A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs</title>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='M' surname='Eckel' fullname='Michael Eckel'>
    <organization />
</author>

<author initials='S' surname='Bhandari' fullname='Shwetha Bhandari'>
    <organization />
</author>

<author initials='B' surname='Sulzen' fullname='Bill Sulzen'>
    <organization />
</author>

<author initials='E' surname='Voit' fullname='Eric Voit'>
    <organization />
</author>

<author initials='L' surname='Xia' fullname='Liang Xia'>
    <organization />
</author>

<author initials='T' surname='Laffey' fullname='Tom Laffey'>
    <organization />
</author>

<author initials='G' surname='Fedorkow' fullname='Guy Fedorkow'>
    <organization />
</author>

<date month='January' day='7' year='2020' />

<abstract><t>This document defines a YANG RPC and a minimal datastore tree required to retrieve attestation evidence about integrity measurements from a composite device with one or more roots of trust for reporting.  Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rats-yang-tpm-charra-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rats-yang-tpm-charra-00.txt' />
</reference>



<reference anchor="I-D.ietf-rats-eat">
<front>
<title>The Entity Attestation Token (EAT)</title>

<author initials='G' surname='Mandyam' fullname='Giridhar Mandyam'>
    <organization />
</author>

<author initials='L' surname='Lundblade' fullname='Laurence Lundblade'>
    <organization />
</author>

<author initials='M' surname='Ballesteros' fullname='Miguel Ballesteros'>
    <organization />
</author>

<author initials='J' surname='O&apos;Donoghue' fullname='Jeremy O&apos;Donoghue'>
    <organization />
</author>

<date month='February' day='20' year='2020' />

<abstract><t>An Entity Attestation Token (EAT) provides a signed (attested) set of claims that describe state and characteristics of an entity, typically a device like a phone or an IoT device.  These claims are used by a relying party to determine how much it wishes to trust the entity.  An EAT is either a CWT or JWT with some attestation-oriented claims. To a large degree, all this document does is extend CWT and JWT.  Contributing  TBD</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rats-eat-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rats-eat-03.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rats-eat-03.pdf' />
</reference>



<reference anchor="I-D.birkholz-rats-tuda">
<front>
<title>Time-Based Uni-Directional Attestation</title>

<author initials='A' surname='Fuchs' fullname='Andreas Fuchs'>
    <organization />
</author>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='I' surname='McDonald' fullname='Ira McDonald'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<date month='September' day='11' year='2019' />

<abstract><t>This documents defines the method and bindings used to conduct Time- based Uni-Directional Attestation (TUDA) between two RATS (Remote ATtestation procedureS) Principals over the Internet.  TUDA does not require a challenge-response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence.  Conversely, TUDA enables the creation of Secure Audit Logs that can constitute Evidence about current and past operational states of an Attester.  As a prerequisite for TUDA, every RATS Principal requires access to a trusted and synchronized time-source. Per default, in TUDA this is a Time Stamp Authority (TSA) issuing signed Time Stamp Tokens (TST).</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-birkholz-rats-tuda-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-birkholz-rats-tuda-01.txt' />
</reference>



<reference anchor="I-D.bryskin-netconf-automation-yang">
<front>
<title>Generalized Network Control Automation YANG Model</title>

<author initials='I' surname='Bryskin' fullname='Igor Bryskin'>
    <organization />
</author>

<author initials='X' surname='Liu' fullname='Xufeng Liu'>
    <organization />
</author>

<author initials='A' surname='Clemm' fullname='Alexander Clemm'>
    <organization />
</author>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<author initials='T' surname='Zhou' fullname='Tianran Zhou'>
    <organization />
</author>

<date month='July' day='5' year='2019' />

<abstract><t>This document describes a YANG data model for the Generalized Network Control Automation (GNCA), aimed to define an abstract and uniform semantics for NETCONF/YANG scripts in the form of Event-Condition- Action (ECA) containers.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bryskin-netconf-automation-yang-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bryskin-netconf-automation-yang-03.txt' />
</reference>




    </references>


<section numbered="no" anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to …</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAKaFWF4AA+09aW8bR5bfCfA/1CrA2grY1GHnYhRhZclOtGtbWkuebDAz
GBS7i2SP+uB0dYtmHO1v2d+yv2zfUVVdfVCXg9nBwJogIbvreO/Vu98rThAE
w0EZl4maiPc6zubi7cvL47O3r8R5Nd25qKbiTR6pRMzyQrw7urwQp1mpChmW
cZ6J8yIPVVQVSg8Hcjot1PWEB51XeiGGgygPM5nCylEhZ2XwIZZBIUsdLKup
rqZBiisHiSyVLocDXcos+otM8gwmlEWlhoN4WdBHXe7v7n63uw+7FEpOxIUK
qyIu18PBag47qjQvlTi6xHVkE7CL4eBqNWGgM1UGJwjIcBDKciJ0GQ0Hy3gy
HAj4XMQhPHuyVvoJPijzsPktUstyAY+e0wO9Tgs1094QnRdl61GYp0vZWBWw
rh9mOTyTVbnIC4AhEHEGk1+PxX/BP7HE4Uy817GEY4FH4umrQmZX2/gqLwDz
nyq5UrGBXylYdG93T1zks3IFhBJH1yqr1Ej8Ui0qWcpYnMSM54igAwJOxFuZ
/RVOfST+HXfRFb4p1ByICBAaLCIA4sn+3u7u3r55UmVlAZOPF3FGgC4XdGo8
QaUyTiZihrCO4cwTXPnfFgTrGNB3uP48Fufwj8xqXH9WsX3wSRj+PRBcxQmg
lo6XMgMYGwhmeZECJ14rYq53r46//frZd/Xn57ve5z34HGezxozT4GQMaCxk
Eek8Y6GptAqlVtoNiFU541eyCBdxqcISON69nsbF1SJPfuUhwJqqUFmogrgW
YJbADTMcTJ1x9cZrIGlQLtMAQS1kzwgFkta/fllF9YRpsdZXcRaAjIZ5NgtA
LHKzN+4B44BrgkDIKZyvxPPF/10uYs26RURqFmdKCykytRKpAqmKRD4TFem0
cqGEWVqA8tkBORwOCCngRHpLassjjVhaFTIC6Yc3IWgerURcajFL1Id4GifA
XyBJajaLwxhIuxagwIQOZSL55dhCncZRlCj89gWqoiKPKtoEnxjtJctaewFS
qG5l+LcqLiz46jqO8PyABHlVimtZxHmlkXVKNUdlKLwDA+HLU2BzWlpl0TKH
YRoRkRpYSCMaoPZRs65Aby2QdFo8lVdyJKZqIa+VpYv6sAS+UpFIZZapYnss
LhdK1+CA3l7kVRLBNIYM9Opalyol7QdCk5UCR5ZILH6mYwIRDodHgjq2Q/VI
FHkOkMJLgm7Us5pFuPsOV8pm8bwqiAojkS8Vf5SJQOoqPqJc5BkczsePt8nZ
zQ0wlQ6LeApsBVDreJoo4Ccl6DXYngXMtET2zw81E/MdHmMUz0j0EPKoQvWk
AM0kvkJRBaaEA7iCna7jEJ+/Oj05E2gUkGShOUxYJc8SOCQgisw0cyiw3nGx
Xpb5vJBLAEX8h1qLIw8MnJbmwIqqXt5H3xKgX48A+olco0DNQBtG0pwZMCxK
ij/ScCRyyxWAQO+LPAGqPY3HajwCA52skRrnsiCJ+YMq4lmsipEBVxUEF7Jm
AV+26RsulwJXyjksBF/WwIpwUNkcBFJqsVJJAtZTAzYp7wtHH4KN1mPxAs4H
hB8ECS0dI3lvbQh4a2B5BBCQHw6mUgNtYeckUbA5TNXAbFoFU9rFVxmp85QQ
eGYMgNE7Ek+pMPdIYt5ElaqPkdxwUAkorvF8DmCDrK1xogXJkgksZjwHe4XS
SvKPUFw7WgNRhwNQkrFewIAVMBgNkPYINOgJUgzCougWnsrwCgUfFFNMRIFV
12KuQCEAbbokWMXlAv4VwepRvsQXZjY4hFVKggqogUwhiUFeEvTOyPptoGdX
SdIKlpZAjxAkK0/jX626tF6s0fa8FjKDMcY3N+bj8936497NzVj8cvT2R5gG
Dqz3GPE2vABUR00P7FiqTCPMvXuBwowzGGnZgZYFMZIAZ6FA/H5GIpFhkiRF
oPKkXmfhosgz0OzIGGmVGR0wopHNDWDl4eAOrhFI/lQyFRNZAAOjgWI9mORw
AskatWYFPBiBqkL1NK2Qg1i3gspQJA6EtcWlo7WImYeDhdTMU9G1zEqSXAl+
Hu0jaBPyxDwTCXjFKeqnJEaeAmuCNAVOYP1eLZdgnkiTxsgk+CmUSzdZgf9X
BlEBkzNPt6GNatv5EI5sSvobhRa8eWB3mJzAKohVPgeXAaRgZU+lK/F2JbCi
LLTIyUJJEOOc5krUlivQMmos3uKplAuJWt/I+kqucWW3kCZDAUtNQbNHNQj0
tCoKgk6gakVrCCDpEOwZf0F9QI4P6fHTDEiVprJYkyxUJZDHSUKTaQCaLss0
hAnnzCWBNAUJn6FGQJAAu6lK8hX5Yl+KV7UTNGloGhByOPcsL4FNCC3SLE2a
ottnlYsiZYJswOdGBEQUAX6DuFs6Jh8GsGG7LCQHZ0vQQvC8oc6MDcnI6UFb
Gi8lHQlQBJZD77CgXVEAINrIArYuCDlsFnp+VHNdMnZIFOeIUExg/KExU+el
cwonAu1SEw2UE4dE5BYrcIfIoYSKOCFtTkyJo4wJIDHIs4gdqRbmIxiJa2B4
Ajq6BPWaMPXrGc6S+MhqNJlIEWecCjoonFt7mRYm54+iUujRQsBoM9DjY3Fa
QwOyTf5CtvYWZLLvoC6xToZnP533CmjiOlNUFiW7pE5WU7BqaZUKhAxIbs7g
olYzE6AJg6DRt5WgkkiqOjYUeHzNEeIykSHSmTZBZw6Y0pzZkq2T4V/2zpRh
QwxTZWqsrQBYTdyAYJZ5CZo4q9Ip8AC6v+iRzqoETyZTbPOmoFoVm2ac71iG
HCR3wi2dLAXJEOl3wfrdqOgxLnK5qPTIaBBHEqdU8qSinYk8Ns4Z+wGWMdpk
Toq5zOJfFXprsHUC+gAcrgsD/L4LwwAjVM3IVeABIewhmLV1qkkB1zOeoc0B
242eQFNRAXi3elAGwi/Ecb2VeM/anZ2NE+dsICLsJAJNwMnZevP+4nJrxP8V
b8/o87uX//n+9N3LE/x88dPR69fuw8CMuPjp7P3rk/pTPfP47M2bl29PeDI8
FY1Hg603R79ssfO9dXZ+eXr29uj1FkdYPn1Ry4IwT40XtCxUSYQe2DiEcHtx
fP6//7P3HLyTfwH3ZH9vD3wZ8+XbvW+ewxf07Xi3HD0Q/oou9EAul0oWuAoq
BbCkMXCkJocawrhVJsD+qHHP0Vd4QAATSFqe5PO1OWgE6M4wgkTh4V44MrY2
iT6rdZiXKMIgYxj5MDmOODeM9KbtP/rRkUsR0pwvxIWVgzOQpetYrSzbMJej
KtDqbxWpvCiWEHSlAiQGAzpMYBqVZRC6nXW7NrrfgzQ0Br9z3eQUg+l/w99w
8EcbRP1ZPOrvjzYc+zPqCiF+e9wy7u83u8xBEFxU06cZ2r8RhrQg9KcnIw7z
gCAXKmEtYPy4HbbL261lPhmaEA4QNjqy++qnXRC274vUD4fCzdaPgYaX+bQ/
WEbH88xj55fGGj+t6ezBORJ0CG0kfaRwPRX1rPj3RIqX2QxKcOff4e8ODVng
dR+pN8I5QkVQs9v2gyHytMY7paukFAc//O6IjT/l77N43r7MZ/H8LJ6fhtg/
inj+nsu4IHuHDD7EweCP3l9OG9A8HiZ/mT/9tvMJy3xWXZ9V1+Oh+ay6Nqku
Dmw+TgQ1pvzw5BWW9JTYm7jQzuUIupHdE4ijKfcRyATo+MNWombl1o3Nky7y
ouRkCFd2gLASF+rk1nuTWliG8TN5LounW1k8DmlMOkjXJTK/YOtSaK0MHudB
mwuY9LWpyg4HzXIC5bCzvByLoxkmKSmx4yerdBWGSkV6xPC3ij7e8KmpabUg
xAqQAZOqP4T9WJxUlIv0txo1U52pXAuZ6NwU1dZika94FQdDocqqyHqgcOXs
kcmkmyxWtQTElSuIYfaCQ0fMv/lYU2bO5nX9N0CnjGtgTA9ttbWpM5iM93KZ
xJzCbhN0xKkVc6B13Z3gXIJ+pBm8GGfWMHHplVeAHSiKfwOnhxlNGScqGrki
KhBmqVuZUJ8Rkb9nSb4aDkwSNNaiUefgeoDN1FHiXjxtNEP4FRyqpHK5X2Jl
Y9sk+S8/kddFHy91uJ1oYIquVF6j3YX4siMHlJ/iNAtVAkwXRM8urIv8o7GJ
a5jGWItW/4NNeyMFeToL3CZRu3Q6hEDkKZYIyPdxFiYV9hZp26/U36zxlAfC
2fAa58fvALOkouqorcSJaZ6XIsnnehv5gspOiVxzJpmyy4gNLwAcT3WeMC8i
LOuxlBqscR1igzhV39uHtkXDzEf7QmUBAOFfG2kzbDLwXn9vWyws7AzsiGXH
FFGidSZTUyjuwV6N5+OROH1zxCswirYFwMDX6OtoHWsDy+HAzCiqLLNojnll
5qnzXlWB8sMFW6oQUsbN432qteIaVB3DwrdMCMYMFQzghIzbgMv4hqQrGuUU
QbUxblNLuPAlbNWT67IyTrkDyK5hhNZ2SjJnd+QKp4YLFV65yp9tWnG1lbE4
zcwR51lZUMGwX0MiQepyN9EE5Tbn2WmexaUpBnvYd0AyZ9uolAmft+GwUUvC
t81MShLXvwQWUWz/h8a0LUylNCsWFLYB2xlXXJvTzWTbTdKsgaGYaqp2pKmK
gGwqWRP/1Bqpay1Q2qe3GwwjHjmbCGs9jHZjJta3mg9eoG1DxAXib5Wn1d+6
1j2NDXgN7DTwGqrMIVF/USiLaNt6GbZby0rhyCp10QIb6wk1DMTRpsZqKuAE
C1bHQY0UhoNpGLF7JqhATEfdbFBCG3QMpwLsVLDn4FWT1QegBTLJUhYyVXQQ
puOIc85YZ11Q7yj4gdxkIZN5DmywSM1OptMnEpfnb6gFdSRUGY63kRBFzAUX
g3RPvw0r3mUB1KGOjU7LgHAdA2YR5/SUiyKv5ouup9ZaHLsZ4f3Osu5hEURv
bLEIDcFKV6YIqiUIaz0/BU+Hi4Nxiq0Uku0UV1RBxA1NTWGWTot2pZq1RwPF
3RmiWR23sGJpwna5MUTT3JRm2/X4RlHzKmNnEDitAF4qWTI99Ewl9wWu1jQB
DZrh2tbINF+wyg0NC2HlcbOzcWw26CpC2/fiaFgXpjqmfyxewWgjh1iLB+LK
aWIqREZxWg3dOBSxwUBitcg5brW2Rm4YW9hP+rD3IKeG5KStRftdbOtLk+aH
Y1Fol8oF9vC4MlzbuTLa29axLoAxYtuIQ4eL8lB7OA0w350fU6uINsVP9DWm
CbepmVNFUEwL2UpaJ0Wi8Y8qYNQKy+fIi8DnFgTNIGinR06Rq5otExxI2HYI
FBlHXnbFqa+HBcb2fzanGMWPHhG6XKAKAlsZJc4gjStDVJN0grkwhdDb+51v
bkbceUFHMhE/m249bQwGWL4QGNAU9Z0Saxyvfzyx9no+mMqaZJU9k9iWLxOF
jVs1Uxuve5lU3EnGjbQt8+eFq02/lxsgyCiT3gfdZLodieHMq2o5L2SkGq+s
fBqVicEnrQ/KJUQ3aYcui4BgaAh/wkV+jU0RzoAx9iZJsoPRE+iVHX+o58HC
tBlMW4eJqvF+qj4sY9Y022wR6njIabSGKrQdbKATkYFinSJNgWzXyJQcXRE2
U4CgrfHdDOBApxxxomvDaJahQ3ZV6vZk0rS0shc8ZlRohv/YwvgXfXXwl2TJ
L/igT5B3Y9ua3s1CPCD8elDoNRYvTEtBzAwwHDgfEplzvbR9l4A9d+4k5CVz
rMmLPtF1oIUWAbu66ctwsIT9ERx0l0abYupGoBlr4/7UwQBvCcR81Zsc8pNK
TaqhTJiYIfGiwuHARHZ3RYWtgNDNu1dE2B8MujCp6WjbaAvUBMaDMtHWbseF
85eHAxfz2dgUB7Ebf1eMZ+B14AAgDcffD9va3mCXH6lVEj5Sn0xGlxTAH3En
VqcYjpBsjMaMTWHNbaK+wYC6GF7XLryPhHG/vInYxN8SJsO0mHlC26G9Bpk7
rteAznfOHLEa5Rx6doXTbHfctO7hYA8QpoVc5mI44M14h/ZsoJ+dcXx28ZL3
5Ql1jsqq5BFHptyfyq04RhbdbnWr6T0ANRnJWr11ZYd6/ky70Uw4U8+Xglia
cW3TLRzA1Ip6j3SdtQFlHZlAsqTeS7xNRg81X8UQAJTmCyoQWwX0Zkwx3xG3
T2o73CXYXKYSCYIN48ZHiwsrrA1Pyk9Gfo+AoxqxvZlEO3CEAARMS1IfMC8F
+g0g4t6wThu5AYniY8dObLjzwkUvVrbohLlVGbyokRd/trLMltozA6GJJbAh
G/MYekKEAYrt7QeeBnRhzwjf7e9ueOc/bWSa6mRXwI3dqCsoiEf30KZHU8Qb
4QvAb6g9Lau4e1CwMZblC6sfyWKaqzgYguaFpp5uggqJ2oLUzduAwEhM41x7
sNPBpLLxxHRddtC8zUZf+O5C00b3d44tixw1EXA6Bm7os/krgDklTW3b9uUS
xheY6iCnga4NIbvRMFKx6PxzmGUcYZcSMj3rmBhKleLo0WZiCoUX2IikjB9e
AIrDKpEFtt335+xvT8SRIvvEJBw6bnjd+LEJON/N9je7Z/6tTr2BIX1A7q0v
59ZbTWon3e6RbxsONifc2rm2OgimhSjLRjrcT7M9Ksc2HLxQGKejID0y4qcb
4o14/9Sw+cgtd4/4Hu+h+AG+VS4SSx/ABhqMCL5oNG+aiJNcxwQdR+Mq3iMX
YLUCyHtFlL4TktuSAuIsq6NXcIOzCFitNz/i4W7lqXc7zg4At90rPXBLZmA4
2JwauHdWwCHTTAs8KCPwqnFLb2McUAdZzpi6dJ+Jw4C2JBeEPNACqOJ0ESsn
kJSCWodR3fBBYWt2ry/hKnFN5udm7j5lMXI55UbBgotYMlnhHc76lMBXd9dt
kHaUPXZJY5CdXkeItm80MzcNd4NiTR3HOsOknyhM6JKCp5NK9r0Q8lwM18LM
HfSy+kxGq+L8Vwx6VpJWBNaxuFN4UKvQFDMoUlNGI+Gb24Z1+IyphgBMiT7g
WeZohBLTsug+8sxaVYGCl1KxcHNmqJkWckHCnYkhnzzNbBTim7tE3mOyRp+e
MzLqiV3NB2eMnDl6ZL6omSwCjr1Htuj2VNFwcFuuaEOiaKMf5+jwyhSOugmX
RxWXrA5Aj6JRWHpQPwLn2cuFd3fSBqT1pdgufIYfPaOLuBzRhWy8wuJkBz2I
1mxkoyROY+dimTwaKvmGvSOs0ca0Lzl7hae6pMUX5mCNp1sf3N/WNle+QKFR
PQhWuCavX9CogL8EzGZb2y7lwGbUUwD1XdRuBW9zKQx9JFnS3T9TB+stgd0/
EDivy14/wSIJpXUwWtfuxqhXGWsWtPprTs45tprZGO8NhtK7NMoxFNbb6mIb
mh9XbetW2lr3deOC/H4xz9GH11yVQmeJ8wPWEGRqDq6kaYKJO0UmSgeuuOjo
d+V4XUvGq6AMIVe/kHMpNmTDYIOavtLZ4wpnDfcXA6UHl826NTPsPt1QNBPs
3MR4pa7AFGan343oCxLWCz1yyCoX5IlbRmpcRqc2OO+qem3K6wxWAR/ylH5W
xFYyc5PNxWMuKXIHXr/wKnEEJsBjFJ6NXcmFwdRxDh60aUz6g2tKogY2TAvb
C6HEhI7zOveC48zeae0TAYdAhmKLHGTCdUY2/tVlWNxPi+CtWTo3ItjYFZvw
9uvIw7xzLXpqqdS4An1EJaMkB7GT1sSyB+Nuwj4lKqHjbrlim5QwN/HMqPoT
Vdx/A1stwSIq/GkVVmSpkpkzKnwb04tSJiiLRCGABgQ9XRJFzL1QvnhcmRto
XA+hFODl+5OjupAh+hKe+Hs/NzcEKDUEmt1xL8LHlyaFbqJeWPbxZNmox00K
8q1fkzmx9s2Y1xc2pt5YAmiUdIyH0ywLZLU5bAx2ySXMj1shaFcUrAPIpRqn
vjRqQ1qyTlG5KMAPkDYkADFch3DpiTbJQvRZG52F2rtaKqPIWGi+9si/G2DI
wz+bUleTzOVc42THLuYRc2BI89srLnpAjVLfiOQIlCQ4aXSDoRfgNzQIctLv
uun7gjoY8ddH6jg+aoqwtdDse7pgqdUtOjI3umunAdxfcsd13fRYsC181tfT
VF+Ab1QiSGzNjeiJWIZFQOWXQLnWbUoOQsjQemGvimNY0X3LrrIXIGKGLqbN
unt4Usmy7tl/m2JohP/W7calILbmn+r608ePeyPxbCS+wWijDOcBqtQAVWoQ
RxM04H85ev3jXy5+Otr/6mvTbBOQFaL5ux+++vq5DPe/g1Xs2NMTM8A9eXl8
cnE0Qk8zuFJrXJjnfvPtc7m/P51RDhko+XEL88xbNx5ufU4klgXrK+mTXreQ
f4eAPENxL8eQSsEbfUPuUj9QUVwGzJOH3Jlw4BPZ9FyZvw9pkukftqoim2BR
ZEIHpCfweJLpCf3UGRVL6gMPGqmzrcN6ucY2h41txEEcHe7t7h7swH9bb5hj
D7vcc7BjXvVOCEzRJGCatwbRwA6humM6VIA5fUToLCW2enakXfk9MNBhfaIH
O/XTHkB3Osu3cd65D9IHVmz69oB3myDGaTFo9FDpw72DHf/rPWY8e/CMb+41
wwn5hgE0qK0NDpvK4GCnM2DDbju3bUfwdo5kA7UPPP1zWOuegx3/eWtKWy0d
NrTSwU7nffvgndY6rDXWwY73uDUBdVkfolgKxWDoEJUcUM9+bePeM/9gvZw4
K9e3NryPwCIqrKcHHISyTuh70d5ww+IHOz1Kp/kQ4TzYaWrFDRd69id1010k
zpzJboS5b9gzv+Vaj+cb9Ga5MZXccA5cGvGf1jfYsN49HIT+OoF1FMgm4wbW
LI+oGhIo/L1Ua+J3P8hnz7/6+tuplOE3340EwbFewhsEa2R9F3I40NvYH4nn
I/HtfbyNfzwv4MsmtzJrTcRXu7sixHAMPGbw3rXvMRTL0P4a6cTEnYDqD1t7
u3tbTtTIRk7MsI0eg10Gf4xwsjfetVbywJVLgmZ5rJbx39cVYc9hA9v1eBb3
8iru51H8Xt7EAz2J272Iuz2IPptwD3vQsQUHbQE8bMrfwU5ngD/ZyCYdHQy1
X70hm+xuv4fT8Dz27/I8GqOfP2j0t3eOvsuj+V28mc2eTNuL6fVg0Epbc9Rj
4I11/sqY7Y6x9p66+WB8e4Wf7DLons32+NnENZK7W1KPt8Wb4vSuOa5rYybr
r23+o1ng+uexz59j9/9vq103k3I907CYNm2fAFqLd1yHN5+gy+UBwEhZ/PX4
kWA3J5WYag50Iq9VgMVEqiXWHsDbM/Hq9Mf3716KX15ebpTG5w3vmPq0g7oi
+0C5/IIQpuThmzyqEs4fX5hEHP9S2m2/kqZNvvAS+yZfUTaW6mOUU1wBpUAQ
xzYvK1e3D3H/Bw7ucpc0qZL+4adHb49aQ8XHL/DpTWfKyLWouZ9fx8vrvNBR
iOWTREVz7kojqvMPMipwwLKciXUJYcgV1RzGY1jl/wBBwYl0JGMAAA==

-->

</rfc>

