<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-linker-digital-emblem-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <front>
    <title abbrev="PS-DE">Problem Statement for a Digital Emblem</title>
    <seriesInfo name="Internet-Draft" value="draft-linker-digital-emblem-00"/>
    <author fullname="Felix Linker">
      <organization>ETH Zurich</organization>
      <address>
        <email>flinker@inf.ethz.ch</email>
      </address>
    </author>
    <author fullname="David Basin">
      <organization>ETH Zurich</organization>
      <address>
        <email>flinker@inf.ethz.ch</email>
      </address>
    </author>
    <author fullname="Mauro Vignati">
      <organization>ICRC</organization>
      <address>
        <email>mvignati@icrc.org</email>
      </address>
    </author>
    <date year="2024" month="May" day="02"/>
    <abstract>
      <?line 68?>

<t>In times of armed conflict, the protective emblems of the red cross, red crescent, and red crystal are used to mark <em>physical</em> assets.
This enables military units to identify assets as respected and protected under international humanitarian law.
This draft explores how one could apply the protective emblems to <em>digital</em>, network-connected infrastructure using a <em>digital emblem</em>, and defines the requirements of a digital emblem, emphasizing security requirements.</t>
      <t>Notably, a digital emblem has a unique combination of security requirements, namely, authentication, accountability, and a property that we call <em>covert inspection</em>.
Covert inspection means that those wishing to authenticate assets as protected must be able to do so without revealing that they may attack unprotected entities.</t>
    </abstract>
  </front>
  <middle>
    <?line 77?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>International Humanitarian Law (IHL) mandates that military units must not attack medical facilities, such as hospitals.
The emblems of the red cross, red crescent, and red crystal are used to mark <em>physical</em> infrastructure (e.g., by a red cross painted on a hospital's rooftop), thereby enabling military units to identify those assets as protected under IHL.
The International Committee of the Red Cross (ICRC) recently posed the question: How can one extend such markings to <em>digital</em> infrastructure such as servers and networks? <xref target="DE-REPORT"/></t>
      <t>The goal of a digital emblem is to prevent cyberattacks on humanitarian infrastructure.
Parties to armed conflicts are bound by IHL, and are thus required by law to respect the protective emblems.
Other actors may not be bound by IHL, but could still respect a digital emblem.
Either out of respect for the humanitarian cause or to avoid unwanted attention when attacking marked assets.
A digital emblem can only serve this purpose, though, if it meets a unique combination of requirements.</t>
      <ol spacing="normal" type="1"><li>
          <t>Digital emblems require authentication as assets must not be able to fake protection, for example, by transferring emblems from medical to military infrastructures.</t>
        </li>
        <li>
          <t>Protective emblems must be decentralized, i.e., there must be no central authorities that govern the use or distribution of digital emblems.
Under IHL, states themselves determine which parties and assets may display the emblem under their authority.</t>
        </li>
        <li>
          <t>Systems with a decentralized trust model are prone to misuse.
Therefore, a digital emblem must be designed so that parties can be held accountable whenever they mark unprotected infrastructure.
Protection under IHL stems from law, and laws must be enforceable to have an effect.</t>
        </li>
        <li>
          <t>Those wishing to authenticate assets must be able to verify protective emblems in a way that does not call attention to the fact that they are screening potential targets.
We call this property <em>covert inspection</em>.
This is analogous to looking at a physical emblem from a distance: A flag of a red cross does similarly not raise attention to the fact that its being looked at.</t>
        </li>
      </ol>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" 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>
      <?line -18?>

</section>
    <section anchor="the-problem">
      <name>The Problem</name>
      <section anchor="legal-and-historical-background">
        <name>Legal and Historical Background</name>
        <t>The Geneva Conventions and their <em>Additional Protocols</em> (APs) constitute the core of IHL and establish legal rules on the conduct of armed conflict.
These Conventions and Protocol establish the meaning and usage of protective emblems, namely, the red cross, crescent, and crystal.</t>
        <t>The emblems have a protective and an indicative function.
In its protective function, parties to conflict may apply an emblem to assets that exclusively undertake medical functions, such as vehicles, personnel, or buildings.
These emblems inform other parties that they must not be attacked.
In its indicative function, an emblem signals affiliation with the International Red Cross and Red Crescent Movement.</t>
        <t>Since 1949, the Geneva Conventions have been revised.
AP I contains additional regulations on how parties to conflict can communicate their status using technical means, like radar transponders and radio signals.
Recognizing that technology may progress rapidly, the amendment process for AP I is streamlined.
For example, this process could begin through expert consultations convened by the ICRC.</t>
      </section>
      <section anchor="problem-domain">
        <name>Problem Domain</name>
        <t>The concept of a digital emblem touches a variety of stakeholders.
First and foremost, there are <em>emblem issuers (EIs)</em>, groups that provide medical services or conduct humanitarian operations such as military forces or organizations like Doctors Without Borders.
As part of their activities, they may display the protective emblems on their <em>protected digital assets</em>, such as mobile devices (tablets, smartphones), servers (both virtual and dedicated), or an intranet.
Prior to commencing their operations, EIs must seek permission from competent <em>authorities</em>.
When they are given permission, EIs can apply digital emblems to their protected assets, which <em>present</em> them to three types of <em>agents</em>.</t>
        <t><em>Regular users</em> of an asset do not pay attention to the emblem, for example, when they visit a website.
<em>Verifiers</em> pay attention to the emblem and only wish to attack lawful (under IHL) targets.
They are typically part of an armed force engaged in a conflict.
We can assume that most verifiers (typically military units) will be associated with an authority (typically their nation state or an ally), and, hence, that such verifiers can obtain the authentic public keys of their affiliated authorities through secure, out-of-band channels.
Finally, we define <em>adversaries</em> as those agents that are willing to violate IHL and search to abuse digital emblems.
For example, they may seek to issue emblems to non-protected assets.</t>
      </section>
      <section anchor="requirements">
        <name>Requirements</name>
        <t>The digital emblem's requirements were adapted from the ICRC's report on digital emblems <xref target="DE-REPORT"/>.
However, whereas the report introduces requirements on a much higher, abstract level and without a detailed consideration of security, we present a comprehensive list of actionable, technical requirements.</t>
        <t>The purpose of a digital emblem is to prevent attacks on protected assets by informing other parties about their status under IHL.
(Note that IHL also permits the indicative use of an emblem, we subsume this case under the protective use of an emblem for clarity.)
The digital emblem's requirements are derived from two important insights.
(i) A digital emblem critically requires adoption by verifiers, which (by definition) intend to attack assets not protected under IHL.
(ii) A digital emblem should comply with existing IHL, which facilitates the diplomatic process of adopting a digital emblem.</t>
        <section anchor="covert-inspection">
          <name>Covert Inspection</name>
          <t>A digital emblem <bcp14>MUST NOT</bcp14> reveal who is inspecting it.
We call this requirement <em>covert inspection</em>.
If verifiers were to reveal that they are inspecting digital emblems, their targets (potentially unprotected) could use that knowledge to protect themselves against an imminent attack, and verifiers would therefore not inspect emblems.
In particular, covert inspection implies that emblem presentation must be <em>active</em>, i.e., verifiers will be sent emblems and need not query them explicitly.</t>
        </section>
        <section anchor="authentic">
          <name>Authentic</name>
          <t>Digital emblems <bcp14>MUST</bcp14> be <em>authentic</em>, i.e., a digital emblem only marks assets that are used to provide medical services or conduct humanitarian operations.
If it were not authentic, verifiers would risk that their lawful, i.e., unprotected, targets could avert attacks by displaying fraudulent emblems, and verifiers would again not inspect emblems.</t>
        </section>
        <section anchor="decentralized-trust-model">
          <name>Decentralized Trust Model</name>
          <t>Compliance with existing IHL implies that there <bcp14>MUST NOT</bcp14> be a fixed set of authorities that can regulate how a digital emblem is used, i.e., it must follow a <em>decentralized trust model</em>.</t>
        </section>
        <section anchor="accountable-display">
          <name>Accountable Display</name>
          <t>Systems with a decentralized trust model can suffer from misuse.
Should a digital emblem be codified in law, it is crucial that any unlawful display of digital emblems can be provably attributed to the respective parties such that they can be prosecuted.
Hence, a digital emblem <bcp14>MUST</bcp14> provide <em>accountability</em>.</t>
        </section>
        <section anchor="removable-verifiable-presence">
          <name>Removable &amp; Verifiable Presence</name>
          <t>A digital emblem should work just as the physical emblems.
Just as a flag with a red cross can be displayed and removed at any time, a digital emblem <bcp14>MUST</bcp14> be applicable to the widest possible range of use cases and digital technologies, and also be easily <em>removable</em>.
Additionally, agents <bcp14>MUST</bcp14> be able to <em>verify the presence</em> of digital emblems.
With physical emblems, unprotected assets will simply not show the red cross.
Likewise, in the digital domain, these assets will not present an invalid emblem, but rather no emblem, and verifiers must be able to determine when no emblem was shown to them.</t>
        </section>
      </section>
      <section anchor="use-case-scenarios">
        <name>Use-Case Scenarios</name>
        <t>In the following, we list a number of use cases that a digital emblem should cover.
These use cases were derived in collaboration with the ICRC and a broad range of international experts, including the medical sector, the information technology sector, the military sector, and cybersecurity experts.</t>
        <t>It may turn out that there cannot be a single design proposal that covers all use-cases.
Nevertheless, the number of ways in which a digital emblem can be distributed should be kept minimal.
The more interfaces supported by a digital emblem, the greater the burden on verifiers, who would need to check every interface to ensure that they are not attacking a protected asset.</t>
        <section anchor="personal-devices">
          <name>Personal Devices</name>
          <t>A digital emblem should apply to general purpose, personal computing devices such as laptops, smartphones, and tablets.
Typically, such devices have no stable IP address, but have a powerful operating system and support complex applications well.</t>
        </section>
        <section anchor="constrained-devices">
          <name>Constrained Devices</name>
          <t>A digital emblem should apply to network-connected devices that are constrained in computing power, bandwidth, or cannot be easily modified, for example, medical or IoT devices.
Typically, such devices are deployed in a fixed environment, however, due to power, hardware, or legal constraints, they cannot support complex applications, or their software might not be modifiable at all.</t>
        </section>
        <section anchor="servers">
          <name>Servers</name>
          <t>A digital emblem should apply to dedicated and virtual servers, e.g., web or database servers.
Such servers may or may not have a stable IP or a domain name associated with them.</t>
        </section>
        <section anchor="networks">
          <name>Networks</name>
          <t>A digital emblem should apply to networks that are controlled by one organization, e.g., the ICRC's internal network.
Typically, such networks have an IP range associated with them.
Each device connected to this network should fall into one of the categories above and could thus be marked individually.
However, marking entire networks should drastically ease the burden of deployment, verification, and distribution.</t>
        </section>
      </section>
      <section anchor="excluded-scenarios">
        <name>Excluded Scenarios</name>
        <t>Notably, a digital emblem cannot be applied to infrastructure that is used for both services worthy and unworthy of protection.
A digital emblem must always identify assets that only serve purposes that enjoy protection under IHL.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The requirements "covert inspection", "authentic", and "accountable display" are all security requirements, i.e., one must consider powerful adversaries trying to break these requirements when evaluating a proposal for a digital emblem.
The original, academic paper proposing <em>ADEM: An Authentic Digital Emblem</em> formally verified ADEM's security, and any subsequent proposal should be rigorously analyzed as well.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <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>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <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>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="ADEM" target="https://dl.acm.org/doi/10.1145/3576915.3616578">
          <front>
            <title>ADEM: An Authentic Digital EMblem</title>
            <author initials="F." surname="Linker" fullname="Felix Linker">
              <organization>Department of Computer Science, ETH Zurich</organization>
            </author>
            <author initials="D." surname="Basin" fullname="David Basin">
              <organization>Department of Computer Science, ETH Zurich</organization>
            </author>
            <date year="2023" month="November"/>
          </front>
          <seriesInfo name="CCS '23" value="Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security"/>
        </reference>
        <reference anchor="DE-REPORT" target="https://www.icrc.org/en/document/icrc-digital-emblems-report">
          <front>
            <title>Digitalizing the Red Cross, Red Crescent and Red Crystal Emblems</title>
            <author initials="T." surname="Rodenhäuser" fullname="Tilman Rodenhäuser">
              <organization>ICRC</organization>
            </author>
            <author initials="M." surname="Vignati" fullname="Mauro Vignati">
              <organization>ICRC</organization>
            </author>
            <author initials="L." surname="Maybee" fullname="Larry Maybee">
              <organization>Australian Red Cross</organization>
            </author>
            <author initials="H." surname="Johnston" fullname="Hollie Johnston">
              <organization>Australian Red Cross</organization>
            </author>
            <date year="2022" month="November"/>
          </front>
          <format type="PDF" target="https://www.icrc.org/en/download/file/253888/icrc_digitalizing_the_rcrc_emblem.pdf"/>
        </reference>
      </references>
    </references>
    <?line 243?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Parts of this draft are based on the initial academic publication describing the proposal <em>ADEM: An Authentic Digital EMblem</em> <xref target="ADEM"/>.
Initial work on this project was funded by the Werner Siemens-Stiftung (WSS).
We thank the WSS for their generous support.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7Vb7XLbRpb9j6foVao2EoukI9tJHNXsZGRJHmvKsrWSMqnZ
ra1UE2iSHYFoBA2QZlJ5l/2xT7L7Ynvuvd34ICmXp2bXPxISBBrd9+Pcc0+3
JpNJUts6N2fq6LZys9ys1H2ta7MyRa3mrlJaXdqFrXWurlb081GiZ7PKrOmB
+8nl1VGS4vaFq7ZnyhZzlySZSwu9wohZpef1JLfFo6kmmYwyMTzK5KuvEt/M
VtZ764p6W+L266uHN0p9oXTuHUa3RWZKg/8U9dFYHZnM1q6yOqcv1+ev8T/M
7uj67uHNUVI0q5mpzpIMUzlLUld4U/jGn6m6akyCub5IMG5l9Jk6v7s6x5eN
qx4XlWvKM/Xw+jJ5NFtcyc6StSkaDJHopl46jKgmicK/eZPnsqg3Jrcf1Tte
FP/kqoUu7K+6xkLO1NXDW/VvTWXTJf9oVtrmZ2ouRvgTDDQ19fLXKf28O/Kl
XttMvdbeFv+3A9/opnLqr3ZRYKwDQ19f3F30B12t5dY/2bRKp7g3SQpXrXBl
TaYhL7ff8NT55dUNf8C/WlcLU5+pZV2X/uzZsyyf6nRFYzzLnH12+tX09PTl
189efP3tN9+dfj198c3pN19/+yo+HAKRB1TnhTqHE+B+m3YxeCMxKA+0Tor/
Jt1H/HvCYfEfJgWjm1JXNUe7m6sLtyqb2lTqPrWmSM141+xPvmXXef/YSziO
1Xu3NhTX6vlXz1+EX7yprPHkgt6yLy7u1ZfPX5wppHBqkCnFwtObYD1+Vp1f
3Kj76z/fn1/g7cXcVPRe5YpuLrrI6MuqKWzKYeHVvUkxp3pL77m8mtxd3X64
e3jK0ZvNZhrD5Zkp4O20oQU/o4s7ye8nlSldVe+4PfjY/orp89TvDOZUOe/H
4aPxKdmQ5ioXtr4DJv93RcWDzVe6UHcO+LL8n/9q/KHgaBPjyWH2U+vvHOCd
rqothtnOjNl//rzxdQWT0EyjMT493luX59aov7hl4Wt3IBY/MeR+1D0Pv0jC
90x6e/nmU77fFLnT2bO5zc2z51+/ePXqFcfBT1nPxT/BxT9VdFWiYlpm8yRJ
JpOJ0jOaY1onyXWB8FgZjmZdrTBhgDtAL63HHCJl5WqTEhSpEFsx7iu6V4JH
PkrwjDl65IpED8qCgvszVTu10tWjGpXLrUcW5COlvTe1nyYPS+uVKTTe4NXK
5lgEvIZcqT09ZqlI2fk23I//4Q2+xMQwLL0vTBPfGhS0CoUSOVdwnmEGywah
SEOSU3K9Ce/j8qnMxzJ3GE0t3QYZa2CAJseoZZlvnzIBpjQKph6NVWFqqnYT
WK6QSQA+Kg0TN2nd8Oop43T7TBhnJLbKzNwWeL8Y9ZfGVkwOxCVq+MgY/y+X
AEHOYR8AZPDYNEneuxqW3I73Hld4FBdh118aWuhqZsVI9K6Do4057HmsWCv4
AXxPYagCLyJvbWUpmoxVmqomy+labfASnedqlCLmqxp2Yafh+dE0udi9plZG
F16eBMJ4ozbWLxmsXP/1phcGneNXyDs1w29YKD2QOeUdRsBITY01rQ3ygoGP
hzdbBCMCqq51+giLdAPRW2rUgKnkyspmWW4SUJrroq5c1vBcKXP6Ifa2H2Lv
9EYdX799d4JXFJT0YVE7gc0zLlwdJ4Hso6xQc53SjZjCWPkmXdI6YY6SHMm5
8v+TiztBe2ymi+lYzWCjbnxVakqtjEqbbif1JdLRuXntyhNGjcrgKc5mMvgn
0lm8fMibksawoax3aGyqo7aujYnrb4EWZkdFOMGEaf1I4NLxanEPIt4LHXuL
RE/hJkp287EGBRYzk0G4svfTe9cs0SGoZwhfzxYOAOC/V7/91hby339PeOoL
hxkfSGVl+UUlRSZqbooCVUkgeLLuALOGc5gmt2A71vDzQ9D27OEZEjMjz8F+
ITFxtV42PuY2/wokpBECkj6BddPkA3kU6Y7uwHPOUMjOdt8yQ5IJcsLKSPk4
6u6yp8mV5QEpK2GWeB+1QjSDwbpTjWClNoQWunaW4mKjOQBhKgoiWGoDXAgp
xOEGL9LvobKc75pdPI/QYA/infBD2VQUKBS8rlksx8rOlUW+Go7LJ/ByB3RP
py2JjtkZ7tiBToqeEPItAvRwa64fOz8Q0JJlzEe9KnPD6YjKXXhQzIpWG181
r9yqBRBK7ph0w9DBRJ9PicXuVrSInhknDvGXX00GO0zNNKR0e0vhVLgnMEEr
sUgItyBML9iRwXOZxcstoiNYbegNzOeHmOkAuzpgJX4w+RofM4O8X6E8wstg
76oMgc8xHWyIiMRLylxLuQ5uFgDBBVu109xOkxdTdQ8opCVTaaDw7K+Y+lms
cgXWKmAJRxRGDIp+1zAaVQYuMQeqa2dED8KK0VCA2Cxx2hR7+H1piGDE+pkb
DmHAQBXrUjWsSHvp30ZHh5NKFsVxgMSWtMeHzrWG2srUxDhbargf8zHzOcaa
Ji+n6uFziu5uncW0CcoPsCRLNWKjAxfIHAxAsc6MoEvf2rHbUPTqXm0m23vU
MVPQVErHd1Noc1uEsPkxUAvJ38g6DhINJnuWgkbnbuEaxs3cOYYLTRAVi2B0
JFtRc+xqNHIg9Wqe64XAeFcMeUneItd0lQsuVtpSRXt6dVQCZ4beTDNgIAN4
gF2gb1zLQxLel0QLLX+XQvIIs5CG4tXRzQ/3DyTT0P/V+w/8+e7qX3+4vru6
pM/3b8/fvWs/JOGO+7cffnh32X3qnrz4cHNz9f5SHsZVNbiUHN2c/+1IIuro
w+3D9Yf35++OyL1s/NiJSpFxFBtMv1HZGKh9gnxIgQEcyer1xe1//+fpS5TK
f7p7c/H89PS7338PX16dfvsSXygb5G2M0/KVoiIBKTe64sCC61MtlGjM9Rj0
HVXTUH4ko38ny/zHmfrDLC1PX/4xXKAFDy5Gmw0uss32r+w9LEY8cOnAa1pr
Dq7vWHo43/O/Db5Hu/cu/uH7nJBxcvrq+z9yCFGUBJERX79Q78yCQBqGfItI
BgJSiL9GnSRhrsgkrP5M0KP3wk+Qc3SeZTawLkIdl7rcj9Tx+a0/IdKBWl83
teEYTwGKlCEERjQC6BYxQL9UOc+jaqi5c0W4uSAmvd92MsIihXbnE9/eG5bG
oZaB0xi3NF4veAb7WNS1MTt0eUiVA02eJgOSLUjZH5XLD9GyjGs6rsybguFm
Sh015Xjv7vjbuK0DyJK4XulCuNkkMBb8IegVtGXMMB/THD3kGgsQwK+JI7Tt
Qhi+1y2sDaplTv0DYNFTW5qzmjtrbM7iVbRyB9WkQCjHzKydZdcp9XkKMy2T
tSs9YIVxby1UCpGkSs/n4CTCgLj01nu8vqPxnQIVJKkbEk3wAa65t6StnX73
8jvx5oEAZo/NUDyo7wMgY7Lnt+qajF6jgcH4XVhXZtHkQZEj3o3m4JCbqHSn
rX5nQn4QY0E9kQYf/l4W7BJuZMcqt3BTpTNAFpO20pHzZHW4bF00zjS5M6lb
FFGaI7vTYA71SvpUhNMCtgCnBOhlMZAR00XG2FuSMImfiSzyUgHMYAxGrwgj
sP43fRYZiyY/Iqx9ZhYM6BURYBJFqIxShjd5HayTsoWld2DnodWaMtDEnY1L
t4J5JXtwd2rK+mDrUzsEKtE4tQbRNyjcpD9QVC9dTibCfG3lRYkksrVyvo48
lMrMqO2hfEMWPb669iejseIdhxC5WN8anWabJ8T3bUoQVLXwM+g2iEOEpcZE
amk0Uyd+tC/te3HxpZPm6McgNrxGleZFnHuOpdCmWu6i7Dq09q0G0Wevh/S2
IoJxxwijPQUlRl3mr9zM5sRAZanHzC9JxvFglXW5BJv1aNJj93o8Q8qrta3q
JlSKjK2Fd5wwYjDKUfCamninlV6MEsEUadCRMbXOdGMFVwhgeGMeCYDCJpSw
KjxaGmJHatTrHsDSfqQ2ruV+C1ig6D0sw1ISClbutBGBZ2EmnY3ENuPQOcB4
ALyiHnF7IfeDXiraGmMdZYTigU5uRPThjjGhoh6mQrmjEC5kPJKVCAhL0Y6G
LC9qdIOObdOuC0hkiW1uzAwfwFNGfyXubPkdnxiwR4W47LkoGIHez5tcHbdN
wEnHjx+iJbFACn/SQkIo0lq45nJQoy9YYOmZ0PWuDDPB5lWD3QX9ClkofN9y
8HRDDzWeE0wU/GzGPYNLLYVTaLeKrhnrPy++C701t4Eh+OjXEy7OY5A73szh
qXC8d1Phpn5G2C642O5rlQ24Qkrc2feyMJQiCpJBByvgx0IoXoRUnrj5ZMbM
YKmpijIwFTSpMYmbIt0idDLKJoIyT5p21LU4oGS+5AkySmis1tbltMjIlTxo
bSqunVHjvNcl78B3QA7OMBLUCAb7uVC4YrKbCQLVdz3VQoB6+K4v/VCE3jDk
ZrqkgTiDI/TznbTNRAi1m48DIWyavHUb6m85G1CUotjNT9sgq5qdN7PEuCI/
L+1iSQ/HbQsQyrURuIr6LvXxcH8uTNID96s9YZtdFmCAQ32FL4gTYlYAci/J
wQSGUHPcK+g7Wg+ZLWhGnyHt9VS9XZ9QKRXuRYExpF96Rgsb8oxOFT1+7+qQ
lhxEuXcCl7UYt8fKmjDLogWoDemYs5DYltIHt7SKSb8I7T7L2JYCG0lNOfmM
+KHAx7gYK4bPBvG6Is/rght1OJeMemxP1L5YR6kpEBFGJe7mSnYtbNciQIT5
Y1zM2s75hDvRIuthZrA7Y/ghtfnYHpoHuksiSRQyDMM1USREDHmNpSt5e1Du
o4qFUcrc0U5+2rItMiYvgHeEdrVRZCgpAaxhXLcaRrKvYsZ2Nmxs4P2EAq3u
gcFtvSOS9NxyWCe5nvcQlfOe1WEef6jM9F6zk/jjELChDqnjVrrh3qU1+Umg
nRRfPPZj4TbI3oWRzOHb+kqgXhBxr5mQrEgRbBNLWrfezHngOup07Oow4Q5P
0btwnqVU59EG7u1FIUTztgkKRg/YIcASdbARczozimJpbyKhCDLeRGCU/QLE
HE3rF5DXrRAS2oa0qa3zbYiC9mxGkuzqyux8fnW8p337HhQxbyBF0Q9ayv5G
0D9AlDlobC3RwltZcUbjPY9U1j+2cYQQEfYSJ96LjXEbPWErln0TUXTWEmYK
v3mlm6zJexY+HA4cPodDga19OVCBH1gFviEVOEnoCAdt56dmP/GHYSL9SZua
xH/U3H4kIdhIcdnVy4m3hAbUcOt5qJSQn6KZaFeC5jZ3ec63j57Ur0cxkHpC
86VYDk3054rgNEPfzOfAR9ljCDr4vSDi3nxn1PllZHtmlCxFY9JUZKomtRFK
dEFwEAhsbID2tweiYk4hSlvaFAW8myCRKyxCchbFKlZOJocdYnVjEBOoqRt+
K1Ryb/bsu5gPo+EWd7TnHbrRNVvzn5UQeP5yy+CQmgNgHaoH7RGqn8m0gQDt
yM6Ixb+EX7XozcE7neIclhIMFg4/UHu8ZiWZzUrnOZ5aGoVkSUAT1XuaxgaL
xWvBZryly+j2REcjcCZqIKgVx2uVCe5iWQoj8kE7DNpb+GhURQvBZJ2AyIcI
hBK3cwmzGIVNBCEfYsfRwd0iarH37DZAjwhzjL7ecsGmvCeBeKj+TZN36N7R
U8FcoXGI78tYyOBi1m1Q84hCHAKHpOZ4jaTJWmZF26DARuJxhWuvDhFp76RC
b5PLFN1zatPq2uIpIQjqB28mF8TY7pG0QGTn5RwP7TMwLACcmOMxp9VKDm8O
HSpJ+CTNwWSjRNg9wyAfuZwlOSzPQVKrXU0PvUE4DTKrnM66eBqeyhGNyZPt
07zJ4qG0rgqRqDIOZDaciKTWuBPG+re0HWi8yF0bbaq351rCC2HEa5Fd66Yq
lJDsFr2RYVHoVKTq5XE7jzeZnI8AxjbyvA8BC03YQtPkPXU5GCg3XqhQz/gb
veU9MaGKe7bvUrtFuOCOGe39lHR8pLArUqeJda9cFfZZQDoZ80ri1KLO7R8b
oqks0HnVgeLPmioztBE+pNAulEtmKCT0LA04My1q272MfqDjv5XZoYXdWRZh
tzs5GfDzliVpzO1SRKqnATOcwXIKqGFov7ndpy/jGCmfr2QiGiSvqITlaFld
OVS+JCqCJgY7Rv0h6GdxCJaPkYZeiub1LenFFbuU8jvuB6Cnrah8BTpEB7K4
qkpHL/6QlsF8jLArquHG5HlL9gtqakmk/TsMsn/kLM69ZXdpb2BO1mgonjdW
glkC+esl63xd2AcQX4UivqNmxezEtWv3EN/6tCml/UMXtI0KkxAiU6xt5YoV
b70sozqQNUL/ZYZLXWUbzUpMFfaQ2kXVUUANE/+Uufn50Ee7eU1DIpfQdcYt
DVkr+5qM1/rmXlTSz/BHq5oK1Ac9NaisYyVHqTZmxiciNMKK4Dv8DC5FFouS
LAET7ooHbUKwdaHIfzIg9Yk3tfY0trZQfKHeh4NJnx9RwwCqK0C8QAodg+hL
33FRPTUowHsex9qPivYl8fAB1iPV4fAirnQbSqoLdS6GIJRhtLiUOWEx5uBk
rnIyLPztRNBTwtZdGjrExrP35cAQCSagfQ1NtydYhUNhfCqQIC6uILw0o4MZ
QaEw2psBuM5D6EuUC9C2xyeZUXVnY6S0X9FOH4KpX9qfPs3Zq1UU7mKanfNq
cuhAmghOZVb82xYPi6mXW9k+LcKX3g4qzWsvdJi/6Fzq2c7JXH5d73hVQOzY
Rxc/u21v8L7wknzRHohnUGwlvCBTDlSlo72GnU4utM1nPKzQP2MTOPMRxzaF
yhPnXaXPohDidUY1sYP7ntiLTmkbFN0Ziutj4ItDAZU4nQFLbHTdlkUhEvLn
P7saEC0WEbsgnZmO2erMrEhA0qWpwrM0zuhTf8Uh54vlWDmFZijyGf8tyZe+
J4nKVvaW9UBMO+wlyvw6/oHpuMo1nnepdb79lWt6W8fU9fn78wNe658OoaPH
qKl8p4isxMT4iO0MjIFGOU+jCiTy9G9nwp5M9i9HyG5vjn5P+Oxj0PLbM9x8
6FF7OZcqhNHycaHOerwPIAwyHEeJhLNd7icteiMW/e03uokk7evwCoYgV7R7
qj+TuEDMfU7B3W6W/ghopD9JsRQWfnKPpKkbzOD4x/v7E1bqkCHFo9x7fx/P
Q6JmMfmhU0uhxk2T/wVQGXwBVTYAAA==

-->

</rfc>
