<?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.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kwiatkowski-pquip-pqc-migration-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.0 -->
  <front>
    <title abbrev="PQUIP-MIGRATION">Guidance for migration to Post-Quantum Cryptography</title>
    <seriesInfo name="Internet-Draft" value="draft-kwiatkowski-pquip-pqc-migration-00"/>
    <author initials="K." surname="Kwiatkowski" fullname="Kris Kwiatkowski">
      <organization/>
      <address>
        <email>kris@amongbytes.com</email>
      </address>
    </author>
    <date year="2025" month="July" day="20"/>
    <area>Security</area>
    <workgroup>Post-Quantum Use In Protocols</workgroup>
    <keyword>post-quantum</keyword>
    <abstract>
      <?line 45?>

<t>This document provides guidance on migration to post-quantum cryptography (PQC) in internet protocols. It outlines the challenges and considerations that protocol designers and implementers should take into account when transitioning from traditional cryptographic algorithms to PQC algorithms, which are designed to be secure against quantum computer attacks.</t>
      <t>It is intended for cryptographic protocol designers within the IETF community, as well as technology developers and implementers responsible for deploying PQC standards.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-kwiatkowski-pquip-pqc-migration/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Post-Quantum Use In Protocols Working Group mailing list (<eref target="mailto:pquip@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/pqc/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/pquip/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/kriskwiatkowski/draft-kwiatkowski-pqc-migration"/>.</t>
    </note>
  </front>
  <middle>
    <?line 51?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Advances in quantum computing pose a growing threat to systems that rely on widely deployed internet security protocols, which use cryptographic mechanisms to secure communications, verify authenticity, and protect sensitive data at rest and in transit. While a cryptographically relevant quantum computer (CRQC) capable of breaking these protections may still be years away, initiating the transition to post-quantum cryptography (PQC) now is essential to ensure adequate time for planning and implementation.</t>
    </section>
    <section anchor="awareness">
      <name>Awareness</name>
      <t>Before embarking on the transition to post-quantum cryptography (PQC), organizations must first evaluate whether to begin the migration immediately or adopt a phased timeline. This decision depends on factors such as the duration required for migration, the expected shelf-life of sensitive data, and the projected timeline for quantum threats. Data with long-term confidentiality requirements may increase the urgency, as adversaries could collect encrypted information today and decrypt it in the future using a cryptographically relevant quantum computer (CRQC). Even in the absence of a direct harvest-now-decrypt-later threat, organizations must still prepare to protect data integrity and authenticity against future quantum-enabled attacks.</t>
      <t>To guide this process, organizations should clearly define their PQC migration objectives, starting with an assessment of their risk tolerance - how much risk they are willing to accept in safeguarding data and assets. This assessment will shape the choice of PQC algorithms, protocols, and implementation paths. It's important to recognize that PQC migration is not a one-off upgrade but a continuous effort that requires ongoing threat monitoring, periodic reassessments, and adaptability as quantum technology evolves.</t>
    </section>
    <section anchor="key-exchange">
      <name>Key exchange</name>
      <t>Key exchange is a fundamental component of security protocols that allows two entities to securely exchange keys over an insecure channel to derive symmetric session keys.</t>
      <t>The development of cryptanalytically relevant quantum computers (CRQCs) threatens current systems, necessitating a migration to post-quantum cryptography (PQC). A key concern driving this migration, particularly for key exchange, is the "harvest-now-decrypt-later" threat. Adversaries may collect and store sensitive data encrypted with keys established using quantum-vulnerable methods today, with the intention of decrypting it later once CRQCs are available. This threat specifically impacts the confidentiality of communications, which is protected by keys derived during the key exchange process.</t>
      <t>PQ/T hybrid KEMs are widely recommended because resilience that they offer: even if one of the underlying algorithms is broken (e.g., the traditional or post-quantum scheme), the confidentiality of the session remains protected as long as the other holds. This property is essential in practice, since encrypted data captured today could be decrypted in the future if a single algorithm fails. Migrating from PQ/T hybrid to post-quantum KEMs has lower cost comparing to digital signatures, as in most cases KEMs are ephemeral and used only during session setup, without long-term identity ties. In contrast, signatures involve persistent keys, certificates, and complex trust infrastructure, making their transition more disruptive.</t>
      <t>The expectation is that importance of PQ/T hybrid KEMs will diminish in time as confidence in post-quantum algorithms grows.</t>
    </section>
    <section anchor="digital-signatures">
      <name>Digital signatures</name>
      <t>Digital signatures remain a vital component of cryptographic protocols, ensuring authenticity, integrity, and non-repudiation. As such, post-quantum digital signature schemes are necessary in a future-proof internet infrastructure. However, the urgency to deploy them is relatively lower compared to key encapsulation mechanisms (KEMs).</t>
      <t>Unlike key exchange, authentication cannot be broken retrospectively, meaning quantum-safe signatures are only needed once cryptanalytically relevant quantum computers (CRQCs) become available. As a result, the migration to post-quantum digital signatures is less time-sensitive than for KEMs, allowing for a more deliberate and carefully planned transition. Since post-quantum signature schemes often involve larger keys and signatures, greater computational overhead, and increased implementation complexity, their deployment may incur higher costs - reinforcing the importance of keeping the migration as simple and efficient as possible.</t>
      <t>TODO: migration strategies, hybrid signatures vs dual signatures, etc.</t>
      <section anchor="pqt-hybrid-digital-signatures">
        <name>PQ/T hybrid digital signatures</name>
        <t>PQ/T hybrid digital signatures, which combine traditional and post-quantum algorithms, aim to provide resilience against future quantum threats by ensuring that if either algorithm remains secure, the signature remains valid. This dual-layer approach offers protection in the face of current uncertainty around newly standardized post-quantum schemes and implementations of them. However, hybrid signatures introduce considerable implementation and operational complexity:</t>
        <ul spacing="normal">
          <li>
            <t>The number of possible hybrid combinations leads to interoperability challenges and increased implementation burden.</t>
          </li>
          <li>
            <t>If one scheme is compromised, forgery is only a concern while the corresponding public key remains trusted—most systems already revoke or rotate compromised keys.</t>
          </li>
          <li>
            <t>Long-term protection through hybrids may be limited in practice due to standard key management practices.</t>
          </li>
        </ul>
        <t>Instead of relying solely on hybrids, protocols should prioritize cryptographic agility-embedding algorithm identifiers in keys and supporting efficient key rollover. While signature migration should be planned proactively, broad deployment of PQC signature schemes can be aligned with infrastructure readiness and the availability of well-vetted, efficient standards.</t>
      </section>
    </section>
    <section anchor="infrastructure-costs">
      <name>Infrastructure costs</name>
      <t>Migrating to post-quantum cryptography (PQC) necessitates potentially significant updates to an organization's cryptographic infrastructure. The process requires careful planning and resource allocation to address various financial and operational costs.</t>
      <t>A key aspect of PQC migration involves identifying and budgeting for discovery initiatives, which aim to understand the organization's cryptographic assets and their PQC relevancy. This includes building a comprehensive inventory of cryptographic use and associated assets. The process of inventorying may require specific tools and methods, which also factor into the initial costs.</t>
      <t>A major cost driver is determining whether PQC updates can be implemented through software updates or will necessitate more expensive hardware replacements or upgrades. Engaging with system vendors is crucial to confirm migration needs, inquire about the cost of new PQC solutions, and understand the anticipated business impact of implementation efforts. For custom or niche systems, organizations may need to budget for the cost of developing internal PQC-compliant solutions.</t>
      <t>Specific infrastructure components and systems require updates, leading to associated costs:</t>
      <ul spacing="normal">
        <li>
          <t>Network Protocols and Systems: Protocols like TLS, SSH, and QUIC, widely used in telecom networks and general IT infrastructure, need to integrate PQC for key exchange and authentication. While the computational performance impact of PQC Key Encapsulation Mechanisms (KEMs) like ML-KEM on handshake speed is often minimal or even faster compared to traditional methods, the size of PQC artifacts is much larger, which can lead to increased bandwidth usage, increased number of extra round trips and potential delays. While tweaking network parameters can alleviate some issues, it involves trade-offs, which relate to operational network costs.</t>
        </li>
        <li>
          <t>Message Processing: Post-quantum signature algorithms often handle messages differently from the traditional "digest-then-sign" model, typically processing the entire message internally. This can degrade performance for large messages, particularly when streaming data to constrained signing environments such as HSMs via interfaces like PKCS#11. While pre-hashing messages can mitigate performance issues, it introduces additional complexity—requiring applications to adapt to algorithms that support streaming processing to reduce memory usage. Managing these varied processing approaches across systems increases both development and operational overhead.</t>
        </li>
        <li>
          <t>Public Key Infrastructure (PKI): The PKI supporting systems needs to be updated to handle PQC keys and certificates. This involves changes to Certificate Authorities (CAs), certificate formats (e.g., X.509), and related processes. Various hybrid certificate formats are being explored to facilitate the transition, each with different complexity and potential overhead. The deployment of new Trust Anchors can also be a time-consuming and costly process.</t>
        </li>
        <li>
          <t>Constrained Devices: Devices with long operational lifetimes in environments like industrial control systems, vehicles, satellites, smart meters, and smart cards present unique challenges and potential costs. Upgrading cryptographic capabilities on such devices may be difficult or even impossible due to resource constraints, physical location, or immutability features, potentially requiring expensive field updates or device replacement. For guidance on integrating Post-Quantum Cryptography (PQC) into such constrained environments, see <xref target="I-D.ietf-pquip-pqc-hsm-constrained"/>.</t>
        </li>
        <li>
          <t>Hybrid Implementations: While motivated by security concerns during the transition period, hybrid scheme strategies can introduce increased complexity and potential overhead in terms of data size. The combinatorial explosion of combining various traditional and PQC schemes adds complexity to implementation and testing.</t>
        </li>
        <li>
          <t>Continuous monitoring and evaluation are also necessary to track migration progress and adapt to evolving quantum capabilities, requiring ongoing resource commitment and increasing hardware cost.</t>
        </li>
      </ul>
      <t>In addition to complexity, PQ/T hybrid schemes can incur higher migration costs. Organizations adopting hybrids will eventually need to migrate again to pure post-quantum schemes once confidence in these algorithms solidifies, deferring some costs rather than eliminating them. This means maintaining dual algorithm infrastructure (e.g., certificate chains, key management, validation logic) during the hybrid phase, followed by another transition with its own cost, testing, and operational risks. For many deployments-especially constrained or high-assurance environments—this two-step migration may be more burdensome than a single, well-timed switch to a vetted post-quantum alternative.</t>
      <t>Adopting principles like cryptographic agility is highlighted as a way to manage costs in the long term by designing systems that can undergo multiple cryptographic transitions without major architectural changes, thereby reducing the cost of future updates. However, achieving true agility requires effort in standardization and implementation to support simultaneous use or dynamic negotiation of algorithms.</t>
    </section>
    <section anchor="standards-compliance">
      <name>Standards Compliance</name>
      <t>Protocol designers are encouraged to prioritize solutions that conform to established, widely trusted standards such as FIPS. This helps ensure compatibility with regulatory requirements and facilitates future certification. Migration strategies should align with guidance such as CMVP, and anticipate the certification process for post-quantum algorithms.</t>
      <t>With the NIST standardization of post-quantum algorithms (e.g., <xref target="NIST-FIPS-203"/>, <xref target="NIST-FIPS-204"/>, <xref target="NIST-FIPS-205"/> and <xref target="NIST-SP-800-208"/>), the certification pathway is becoming clearer and more structured. However, during the transitional period—while post-quantum implementations mature—it may be beneficial to adopt PQC/T approaches. These offer several advantages:</t>
      <ul spacing="normal">
        <li>
          <t>They provide defense in depth by enabling fallback to a well-established, thoroughly vetted implementations of traditional schemes.</t>
        </li>
        <li>
          <t>Since the certification process is typically lengthy, using already-certified traditional implementations alongside post-quantum algorithms still undergoing certification is a practical approach for deployments that require approved component schemes.</t>
        </li>
      </ul>
      <t>NIST guidance documents such as <xref target="NIST-SP-800-56C"/> and <xref target="NIST-SP-800-135"/> offer precedents for this approach. For example, in key agreement schemes, hybrid shared secrets can be formed by combining output from a NIST-approved algorithm with that of a non-approved one. <xref target="NIST-SP-800-56C"/> specifically endorses simple concatenation as an acceptable method for deriving hybrid shared secrets, provided at least one component is generated by an approved mechanism.</t>
    </section>
    <section anchor="migration-pitfalls">
      <name>Migration Pitfalls</name>
      <t>Several practices should be avoided during PQC migration:</t>
      <ul spacing="normal">
        <li>
          <t>Key reuse across modes: Using the same keypair for PQ/T hybrid and traditional signatures risks downgrade attacks.</t>
        </li>
        <li>
          <t>Dynamic algorithm negotiation: Negotiating algorithm types at runtime (e.g., in TLS) can allow downgrade or confusion attacks. Algorithm identifiers should be part of the public key structure.</t>
        </li>
        <li>
          <t>Excessive hybridization: Supporting too many hybrid combinations introduces combinatorial complexity and compatibility issues.</t>
        </li>
        <li>
          <t>Ignoring key lifecycle: Systems that do not account for key expiration and revocation are particularly vulnerable in post-quantum scenarios.</t>
        </li>
      </ul>
      <t>Robust protocol design, infrastructure readiness, and clear separation of cryptographic roles are essential to avoid these anti-patterns.</t>
    </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="security-considerations">
      <name>Security Considerations</name>
      <t>TODO</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="rfc7748">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2016"/>
            <abstract>
              <t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7748"/>
          <seriesInfo name="DOI" value="10.17487/RFC7748"/>
        </reference>
        <reference anchor="rfc9794">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="F. Driscoll" initials="F." surname="Driscoll"/>
            <author fullname="M. Parsons" initials="M." surname="Parsons"/>
            <author fullname="B. Hale" initials="B." surname="Hale"/>
            <date month="June" year="2025"/>
            <abstract>
              <t>One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9794"/>
          <seriesInfo name="DOI" value="10.17487/RFC9794"/>
        </reference>
        <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="tlsiana">
          <front>
            <title>IANA Registry Updates for TLS and DTLS</title>
            <author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
              <organization>Venafi</organization>
            </author>
            <author fullname="Sean Turner" initials="S." surname="Turner">
              <organization>sn3rd</organization>
            </author>
            <date day="16" month="June" year="2025"/>
            <abstract>
              <t>   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   Recommended column of the selected TLS registries and adds a
   "Comment" column to all active registries that do not already have a
   "Comment" column.  Finally, it updates the registration request
   instructions.

   This document updates RFC 8447.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8447bis-14"/>
        </reference>
        <reference anchor="NIST-SP-800-56C">
          <front>
            <title>Recommendation for Key-Derivation Methods in Key-Establishment Schemes</title>
            <author fullname="Elaine Barker" initials="E." surname="Barker">
              <organization/>
            </author>
            <author fullname="Lily Chen" initials="L." surname="Chen">
              <organization/>
            </author>
            <author fullname="Richard Davis" initials="R." surname="Davis">
              <organization/>
            </author>
            <date month="August" year="2020"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-56cr2"/>
          <refcontent>National Institute of Standards and Technology</refcontent>
        </reference>
        <reference anchor="NIST-SP-800-135">
          <front>
            <title>Recommendation for existing application-specific key derivation functions</title>
            <author fullname="Q H Dang" initials="Q." surname="Dang">
              <organization/>
            </author>
            <date year="2011"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-135r1"/>
          <refcontent>National Institute of Standards and Technology</refcontent>
        </reference>
        <reference anchor="NIST-SP-800-208">
          <front>
            <title>Recommendation for Stateful Hash-Based Signature Schemes</title>
            <author fullname="David A. Cooper" initials="D." surname="Cooper">
              <organization/>
            </author>
            <author fullname="Daniel C. Apon" initials="D." surname="Apon">
              <organization/>
            </author>
            <author fullname="Quynh H. Dang" initials="Q." surname="Dang">
              <organization/>
            </author>
            <author fullname="Michael S. Davidson" initials="M." surname="Davidson">
              <organization/>
            </author>
            <author fullname="Morris J. Dworkin" initials="M." surname="Dworkin">
              <organization/>
            </author>
            <author fullname="Carl A. Miller" initials="C." surname="Miller">
              <organization/>
            </author>
            <date month="October" year="2020"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.sp.800-208"/>
          <refcontent>National Institute of Standards and Technology</refcontent>
        </reference>
        <reference anchor="NIST-FIPS-203">
          <front>
            <title>Module-lattice-based key-encapsulation mechanism standard</title>
            <author>
              <organization/>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.fips.203"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
        </reference>
        <reference anchor="NIST-FIPS-204">
          <front>
            <title>Module-lattice-based digital signature standard</title>
            <author>
              <organization/>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.fips.204"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
        </reference>
        <reference anchor="NIST-FIPS-205">
          <front>
            <title>Stateless hash-based digital signature standard</title>
            <author>
              <organization/>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/nist.fips.205"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
        </reference>
        <reference anchor="I-D.ietf-pquip-pqc-hsm-constrained">
          <front>
            <title>Adapting Constrained Devices for Post-Quantum Cryptography</title>
            <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
              <organization>Nokia</organization>
            </author>
            <author fullname="Dan Wing" initials="D." surname="Wing">
              <organization>Cloud Software Group Holdings, Inc.</organization>
            </author>
            <author fullname="Ben S" initials="B." surname="S">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Kris Kwiatkowski" initials="K." surname="Kwiatkowski">
              <organization>PQShield</organization>
            </author>
            <date day="4" month="July" year="2025"/>
            <abstract>
              <t>   This document offers guidance on incorporating Post-Quantum
   Cryptography (PQC) into resource-constrained devices, including IoT
   devices and lightweight Hardware Security Modules (HSMs), which
   operate under tight limitations on compute power, memory, storage,
   and energy.  It highlights how the Root of Trust acts as the
   foundation for secure operations, enabling features such as seed-
   based key generation to reduce the need for persistent storage,
   efficient approaches to managing ephemeral keys, and methods for
   offloading cryptographic tasks in low-resource environments.
   Additionally, it examines how PQC affects firmware update mechanisms
   in such constrained systems.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-hsm-constrained-01"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA51b7XLcxpX9P0+BpX9ESs1QoizHMiuVhCFliyVRokQq3pTL
tdUD9Mx0iAFgfAw1cblqH2IfYJ9lH2WfZM+5txtogKONk6p8iPhodN+Pc889
3bNYLGata3N7mnzXucwUqU1WZZ1s3bo2rSuLpC2T67JpF+87U7TdNjmv91Vb
4m612c/Mclnb3Wly/f7j5fXi6vK7D2e3l+/ezlLT2nVZ708TV6zK2Swr08Js
8ZGsNqt2cXfvTHtX3jd3blH91LkK/5su+m8unj6dNd1y65oGf7X7Ci9evrz9
dlZ026WtT2cZhj+dNa0psv8weVng/t42s7QsGls0XXOatHVnZ5jYlzNX1fJn
0z57+vSbp89mprbmNDm6sWlXu3Z/NLsv67t1XXYVro6W+rGxyWWRXNdlW6Zl
3hzN7uweT2ens9kiqfjoT/robGeLDlNKkl85UJLoso6+x8ddsU6+43u8vjUu
x3Uxy5+cbVfHZb3mDVOnG9zYtG3VnD55wud4ye3scXjsCS88WdawrH0Ckz7h
e2vXbrol3ryrXRNZ/skhX0ReOJqZrt2UtSzWFTDq6+Pk9fA0hlafvsa4kxtW
V8Ev/slsy2K93Le2OU7L7WxWlPUWH9iJuepV+vXXz1/4f37z9TfP8TnGTPRM
mzfOFPDZ5eJClrrAlQUef/H8+ddL1+CRt5c3t4ub68WLp08XX/3u/DS5eHd5
fPL0+HdPn714wpvHN9fH/mb9bPLCyZdfff4F3KxPJi88e/ri8y/gZnj828vr
G/z95YGHeesYtyaPPv/8o88njx6as3/0qxlctlgkZtm0tUnb2ex2AxchCbut
Ldqkqsudy2yTrEPKI89HGR/HdpJGGZ88un5//hjhgP+0ti6sjKZRfZxctknZ
tbkrMHa7sUm6MXluizX+RKomzE98Vz/DJ8zwdoL5uHVha33UbavccrK80GzK
Ls+S1txZfrZMTJqWHRZyv7GYbm0wLIdkHq3qcstLmVwxeTx7lyYmBywhIbaN
ANv78+jKHOO5dINEs2E2GZ9a2qQhWNjErA0SoU16y5TbqsMUE9O2Jr1rjmcz
mACmpnGKDK8TS8czOLDge3weFqXFCHMcdtsVwKZ5YnDX5jn/v7Xppijzcr3H
qzubl9VBY9W2qWjnZa5IntkqL/c0DVcrmGnqjFNliGxdluV2NvsC+NTWZdal
NNtsdpbtGBhcyWS1HAnhAWMQ6+75Z7sBpLY0VbNvWrv1rq1tvmdk3cPn+d5P
BDbpI6fxEDyEUHBBh/HHZtti9aZwjTrO+8MbKtWAmic7W7vVPiFuwRouVRPC
QvyATflFCZUdHGxak8gk4U8xYh9Jx8n3G5dzgaMpIJT3XJOFZQ6EwKPzD8yM
1FSGpi9XCUqjuVP7WKzHz0FCf2v2cIWDYxFce2voyHuDyTq4HUDq34pi+9dk
ZVHeM/hs03D1iH28w3rIyM0sXmwxottqXFS5KSRjRhEkljxmPJzdIw+QyM1s
9meLFyxAfWm0WJXFPz+7eYICBQ/+3Wf/FhU5Wbka/wuL5jI55DPGrTXp1j4l
BmBy263NYB2JKyRdVlbwXVJtTMNMxcoIPceJop1NHekD4w652HDSK4BhSUDp
mOaKUVnnR69hIVf7nO0/OpeH7KcKrsO9ZmPz1SJ3K/HwOJw01Pg4XP03fT5M
SgYNxtF8AV5eMAiZ/QlIzHqBMGJAFSskjDiQueGnRedo3LgixesIKH6pq9e2
SBUoTIb4b0ztkLapICZSKmfY4xH6Q3LPl1bxWYbhOGfYivcT1ybe6KuuZdh0
jUTIv5AIx8lLcKIwHCqRlTqzwmAZloNJbUy9Q/ItELULP4FFbjiC2udgwGjS
VLWtiNKMOp/Zks9ElrUgClcVw0AP3X5hftYLWzBbswjAb0spizQvogjDAwWb
6Vx8RUpzpK5A24o+xudcLTA7xGy5ZCQgRDAGwLeW1BaXmwJOazC41GRYRl8n
ScPCcpRJWmyRbJDVWwas3tnYvVSoexhCYELKoa3EdY1Z2XUHfOcdhTgaAp9h
uEleRN/kEFiKqayv1qVTH03rYoTPD9EiqUy7keL/m4a3yrplXGBecHO5htGs
1oOxYTCVomT6gr4vytUq6Srcgt2XHa8iDWCqruyAZyvEbBtqimQDs3ldRrUH
HNMhtXEFs0UVKDPUDKZJWKyfuslM1Zqlk9RCzvQpORRXuytzuEtA8DWMbT+x
8qxRJOO/OH+DaEI1FUvkkgBYi/ryYWnT+SN3wJGT9p7IjMaLudrXszwaHp0G
Frkjt2AWhYKHm4UVYAePIvA0e4BiW2O1XCkNyzcZx8Q25QkhwCTHwKTzffuP
srjRNG4eewMD6BLMoOZIvsjPk8IyN1yr9cr8UxTyODnjTOnnFGwAjaHbqT9h
2Ah9K6ZM2uWSZwTRu8gJc3qBoXv0WTA58gvA9yJ4JI4GcGRYNC0L3IQdDKgp
+SoewTcAGA5lIPPgGJBk1+Ugc1L74ZBNmTUKsHN9m7MUVqiosAqYyyEAuwp8
tEUidpcUNzv2eBjRp66P9Qa1yK28B5FwKGqebk9KB10+YUhKrxTYWi1Ry70u
TQMqY0EM9CO2dYBChNb1+ye3yWa/rF2WvH551Xg8EpbHnEdECvld2tSQySFf
kXBSACQJBMOQ8mjlkW2sEiuigMfABDll4W2JqYGuY85obO/w9CN7vD6eBwbS
E31ymjjmmnQDkHo8/5xpeDnkTM2GtYitAmxgTQ4soRResinzLOAoHgXQYKgR
4wIGV2y5AKTAe8clD2EkUQWCyAqU+fKrhXppQzzYbFKCHUsmI42MNJgDTMax
4brSRAl9T+yYaQqKozayrHssJcU9yXZT+yqSubUjjrErMfx0I6wCs9nKs6Ac
zeBuW9G6NZ5n/nQkYGXBUqjREwyLwtNVmgLoDCOao86A+QiBx1RHiPi1adp5
NAN8XdCYmN64hukjwTpPABqtJEFrPbRzMbn9pFoPiQ4Hq9HQYKA5Mj5QcdTY
iLhumfiZa+quYuZ74FS+1xcqidpQ2kKJnOSAFNPMbcHgm434kEzbNH3opVai
I/ZJFN7spbTmXDzww2z28JoPWcTGzj2oPoc7TthJugFJrFGL1PMmtWRRFgsw
rI5cm+1AcqaUeT6e/YOA8SmnAaLFwdQkrFIp+cQCc8H8+g5w7KXj5BViEyg9
j7mtFjv2jry6pT9QtkQdQryFaGYga7suoFUgzZouVw9GveMj+uox7PyxyN2d
nVST3ir6XopiC4qC5PTIU6PSloRf/TiiypoiLgLkX7GTaAhJi8LaTFIktf9a
GV4SV0cl4YwEBB/p8nY+aZSmuf8wtWnFHP6RKF0MhQ+RXkiZpZ3mSlcEXthv
+WRBQ7OkiGM17bDGVcdVSEdJH/TZdZzcCASOcflBuJSrVloFTXWU+rWttSZJ
bY7waC1cpPb2MQH5ETIbazLPTn1/9ICneoCQMFcc0LASeuQ7qw4g79YbD5AN
6HdtpWdKQ00cw8CdtVW4M9gfWd/Ix2VC4K/IM34E12EK0WYINO8u3p1Gb1Gs
Qx46LtQjS+SwHSp0N4Fn26aEjC9GaPTQ2eOKfQjnlRbAQEvpY6KqKurJYcyC
ud3W92DUE+M6f7jdCp0vOUcPRQquq8Q6qbFDjQtFWbmvxvgQPOHuDgU9Cz0/
DATat+cwFWZlsCjhGU2kvvT11agLA63tSERbjMnOoC47AqG9z/e9ZoZGJjtE
MZoDTVHjGcY2wrSHPnVec7ODNEr+OIlbjk6uEcJ9iGOR5lmvdGOE3wzxFb6m
PvVzQrsqtFQBWMb0rdBEqf1sDi27GqWM4mFyqaRNbUA84bzAQhxemxMwkMXC
jgQATc/070VcU1JWq1op7WrVgVingsjBt1LKbfa///lfQkGCumhyTC7jYzvA
MokfnEs8imYQ2qBF8qbnHFEMIBDLbr3xVtKGADifo357ChZoHIJKhIYQBTLB
LeB7bb2Yrs+J+IuQx8zoB3ZzQoTQyasM6j8VddNBRqjQryLk2ShP1Oq1eGdh
4d0sGxFiT6BWjsHtigguu4oAxYcH4BGjot8hUgZ5c0ilCII2gY4GMJcsCuUO
ZdBkMWp6reAhpKN0chTkpqjo0gKNiz2784w7BU0vm/ni5gJDp/K92Nm2ZUAN
i4k1bOrWo1EFtmezgRj/Gt2072MtAbpVLs/Mx+yFZBIeqkzuU28pRnLQb5qJ
26as5nbTd0+DgOHr5liHxY2yq4mf8FXaF3OTZTVf3oGsUxFZIaOL1Hl4HmMD
lg+7aHNthKsEL0Xai5baJgTRPnx/2WVr24aCD1qcMmL2vSy9G4qFx35p1sQj
2if9f3ZRHSq420tlnvuke4/hgJ684+bUsnN55uVH5rXdkKXsyKLRM6Jh3z+k
uuw2veJVplSKY/FrcIJQUD8Iv8Ds947pu2ssjinK0Xw/3688b0ovJet2lPb2
ThrAwQFb87fS91kUNwDPokoTiZw4PKjdtEKILp83w45O1kNVA5pETb5/FqNL
0xGFrzI0di9qqg3SRN4Bnc9R71RFxotebINdXhZrwEwQJRViE9gmo1BOVEcY
+70E6WSAo0MgkdY27B/UdmbJJk+hvZG4QwVVhCjzzksQ0i+Oo8ZIJ1KJv5aU
VegkVTbEV+MapHogpv4t7YsKgc4X/yrgGzuIUxPx2CgHl60FCXKJ8HiqXiwT
QUb6EywaU19IuXWEgH4R8O9NCBM3xR/fh3k09iUrRJf33VxKcZBvh2CV6JGq
/ta2PJcwnBmQ4W50uNPosrQxt29u5snNzSu17vuPl+fzIMhIa07KgzzD5GAF
GVjHQ4MlPfzl7YOGOVhLe0PGFv04VeDGQrtvF7+PKnzM04FTsvsgrXDvXQ5L
ZfXlqGe7mvZsutCrNwv8JeUUX2423BJGxnKJoY9gdm1VDxJxaYVVTVrEmOD2
ya308u+DAE6BQbQ1KpIU4LUz6dkyUpVeVCMFvrTEtGD5lnuYRhTK/tZA0uwn
zCBRjtnWrmo8zfaVhy2WAXsJhrz3+4jeddREzdZKe8hJkLntGD8IUGFiTccI
k80cj/NcsKjsPYhJCy3EJi4f4QsBxRbwQ8N1MOAEZYr1qZ4HetjORWqGeoIu
EjlUhgD4OXJxrJFSruzTTyS8I/QmVHEZTgsOfARAgzHmPC3je+Wqn4juzMFi
df+NPnPzUE5ooMzqzkIcfwxk8Wc/vYnWLGcLkA/WbPvNFMVA9mmOrEboAXlW
sXN1WSi4hr3FVzdXKNhON6VqNhs+V69fn998cXISvIvCttiYZiN1KFiKswYT
dWv6aJQ2sXN988Cdv+G4Q98cgDUr6kgNrYBhaTh4Ueo+iPwjOhDBRszTx2jl
scG5pyP9ytZuWYAlxo+TK9LhYaebNEWpY3gxdGOca1qjRemBMaQH6n2JpIl3
LKbcJrT5EpfX2i0QOCYM8NH168vHp1Lv8a+YD4dvStXyJzsUkCWJfbgy93s2
HcuMPUHxSaUIKAOdD48lZ3JqSrd2Hp2fNY9HYmWi+69NULH//firp988nnv2
l8tcvOH4xb94xhe6uQMDsbwvrcThJxBzD3EIOPJoyfHRVj2YNNtiqfZ9QkZh
M4Gi3uiJbijF1J/F/VbU1rMi3ZQ9HDViWaPaEhOm2waCSWAZklg8eR5l1AWA
DDdOwz+GzfFRJHD/nYNL5zPKPskwV2SYVK10jFmSD7RgZwF/uezG8iABTCT/
3iL1E8VU9YVeSdlmMEUbVQjcT92DU02DrRQ1k4/CrbjiMTmVoyF0ipP9S0WK
zC/UN6D0CCGo7csX9Sbf0vtOtG8Seizi7ibamYYQmYTGgRSIRya6fr9zZYPe
Ezc5A0gMvBFtJdrAiGjqNGMaqfQrPkEWmIKcNfrckdH+ABlb6k5Ep8H9sSvh
FGuTn3/+Y3/qbzgpumm2i+i9X36RQHqlOXI5FmJOPc5uS7Qvxm949duzXpRo
4l2vaHdAt5IH6Ua1jkGok4AfVJyh1v/DfFJKVkut1OJC7qFZFjSbUkJYsrrx
u4Z6izMNveBUrBO2HXSpLGviqZCpPNSW4GL6LCRj2HYfttRVxdRDOvKSFHtk
+aDxK6lK76LeADm+rkN739cb2V2PJPNRVsyjYAwb/FG0b1ES+8rgbc1H+i6H
CSgyTF8RtWQPum8shMZaxUj6HdbgM/rdqJeQc0fyXS8eSRfGZG07yahAnXUc
L4aKEMH6dFBB1I2B0U6R1tKoPqP9cBkVH9gpswBu3Wkj51OxGh+T01PU8C2l
rKI/Sbb1xYsbFgQbxKzROBJROZKVJsVUq1RcdwB/jn3cWAebqxCrZsvLtUsf
xznlTS5HtSgOcl9BU9EUurcaZZ2qRWxU79UF8xCj8wekgIdifCuIyeyjCtUs
rPTy4pIYZUp19AJ9V6eHbGLcAW2SMwggwgvUjCqKBo/R0mOrECrGF3uHPdq5
qlasTogwrAQQR5qVqI411dKFrfqNx7MQVxXMhnY4D4zxoCjIroTLyPFfv2Ft
knsjqahu8VHh5W4poiKDLvf+7GnMiYT8MROkNV9jDBQhzmHy9cFNTb+rq0qH
HEanvtqxo/TkSNqq2i73ShxDOISeOxwz00ITaeWgKM7qgZC6s/2ae/XMnwni
kadenR8QbQJyUmo8rXVclyksEY5qEWvbvgDTTZG267J1JhzQGDJPdMaboDoC
I1UQSO1sdn3g+HIte/4ALfhA9+EHfbeXELzBSzmPJ8A4nCzpe3evfw+KZ99d
yElvTemNzdFA+nOe0uW2zhd8SaTartlUk66PzhLSUANLbIIvhlSXXv7qwPZU
kIlF3dWP9DwgTPD86i/X/shVL+6o6+Pxe0VuNT29MbL+9+EEDU+5P/C47noc
3FX38PXD6Dj+j5MLz6cXvvpRJv7D5Mz/j+EsyXgFAF2mHc+nUGAR3sdzgXJ0
K1O06AE1i2L8IOVQmQSkAzikOyWjtU13mbbC6PCsawM8LW1hKZWrZqeHZEEK
UPeGLkx4BqOf/B9saKcnOXjou2UDGjaW9v3eHgtO0UhhAsTCHbKFx4ilWAyM
XbL6C9IJAI7CmQ0RNUyEtIfBQ7tlEZHxZVEoiW4hfz50iNW9OkBe3m5Q6P3J
Vd0pWvg3dXO6/8p0Evwp0ZrbcJ+NJz1+6iFSPD2akpwJ9BtCtGfYgxzO4Wvq
xUcZ9amd54x6hGNYvgR8n1zhFxwDDvww+eXLgcg9+RLxrI5GI5PaTAZQ9ZMT
9pPUGmo/GRpl7reUALy11X0uP6eBC29ETQOTrinqe+GaaKZ1fWCqKBEVqoQo
PkZ/w9KveSAe/pScafWQMM+g9E+VPNX9cKmjg3CqWNt+553MnucW+x15Fmk5
KBud0fOe8WcPD65sHlKAh4Qp+LFyFZHQS6+rjtoGRjP4tD96IjVkANNr1zJp
mtnsxidfv48YbcKZXSkf9kgx2sSRFH0tm6Wy66GyCuUytDwfe32sMVs55VIZ
V8tqYwYs7D9Ou+h4EXkVAu6+UO2sPyC9SC58vRx8F1XO0+Rt+GO0XcmfuzXy
g4uukJNRHpoRZ7dvbh4HIbO8j74p2yfFqpPmJ0wgOTu4BRrtXLJx9+f7oj3l
YT8OS3j5SZSpXSCmvpScJjeDWtSWpVLKQzvpkfg27tYmjd+4Hqt6xwlcrgtt
rTg1yhnpPuWPMG9iOpaVekTa/9pp0N4rVw9kh7vg6dCYjUTM6FDq9OxZkyI3
UGiIMh/KJVWcyU+T5p/dsfUH7ljlkCaUo0MhHpPFusz9IajRb1IkrEN/g6sL
mIhEWIkWWtCdHpNVjnLBw/XKOPVwHm3AX2E2ydHVx5vbo7n+f/L2nfz7w8v3
Hy8/vLzgv29enb150/9j5p+4efXu45uL4V/Dm+fvrq5evr3Ql3E1GV2aHV2d
/fVIF3/07pq/dD17c6QEO/59nf9pwtLL0UBdJegz2DWt3VI3ZP58fv0//33y
PPn553/78O35s5OTb375xf/x4uTr5/iDErTveAqvSAsD2c+AL7S9k5xhC80T
PXpeE4mAromkG9b87Q+0zI+nye+XaXXy/A/+Ahc8uhhsNrooNnt45cHLasQD
lw58prfm6PrE0uP5nv119Hewe3Tx93+Un9gsTl788Q8z4epB3jkf/eJQj1zJ
oYGzt2cPb46cyKOyRalPmjRs+/E3c2Q6s/8DW4Apazk9AAA=

-->

</rfc>
