<?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.6.35 (Ruby 3.0.2) -->
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ar-pquip-pqc-engineers-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.3 -->
  <front>
    <title abbrev="PQC for Engineers">Post-Quantum Cryptography for Engineers</title>
    <seriesInfo name="Internet-Draft" value="draft-ar-pquip-pqc-engineers-00"/>
    <author fullname="Aritra Banerjee">
      <organization>Nokia</organization>
      <address>
        <postal>
          <city>Munich</city>
          <country>Germany</country>
        </postal>
        <email>aritra.banerjee@nokia.com</email>
      </address>
    </author>
    <author fullname="Tirumaleswar Reddy">
      <organization>Nokia</organization>
      <address>
        <postal>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Dimitrios Schoinianakis">
      <organization>Nokia</organization>
      <address>
        <postal>
          <city>Athens</city>
          <country>Greece</country>
        </postal>
        <email>dimitrios.schoinianakis@nokia-bell-labs.com</email>
      </address>
    </author>
    <author fullname="Timothy Hollebeek">
      <organization>DigiCert</organization>
      <address>
        <postal>
          <city>Pittsburgh</city>
          <country>USA</country>
        </postal>
        <email>tim.hollebeek@digicert.com</email>
      </address>
    </author>
    <date year="2023" month="June" day="16"/>
    <area>Security</area>
    <workgroup>PQUIP</workgroup>
    <keyword>PQC</keyword>
    <abstract>
      <?line 108?>

<t>The presence of a Cryptographically Relevant Quantum Computer (CRQC) would render state-of-the-art, public-key cryptography deployed today obsolete, since all the assumptions about the intractability of the mathematical problems that offer confident levels of security today no longer apply in the presence of a CRQC.  This means there is a requirement to update protocols and infrastructure to use post-quantum algorithms, which are public-key algorithms designed to be secure against CRQCs as well as classical computers.  These algorithms are just like previous public key algorithms, however the intractable mathematical problems have been carefully chosen, so they are hard for CRQCs as well as classical computers. This document explains why engineers need to be aware of and understand post-quantum cryptography. It emphasizes the potential impact of CRQCs on current cryptographic systems and the need to transition to post-quantum algorithms to ensure long-term security.  The most important thing to understand is that this transition is not like previous transitions from DES to AES or from SHA-1 to SHA2, as the algorithm properties are significantly different from classical algorithms, and a drop-in replacement is not possible.</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-ar-pquip-pqc-engineers/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        pquip Working Group mailing list (<eref target="mailto:pquip@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/pquip/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/pquip/"/>.
      </t>
    </note>
  </front>
  <middle>
    <?line 112?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Quantum computing is no longer perceived as a conjecture of computational sciences and theoretical physics. Considerable research efforts and enormous corporate and government funding for the development of practical quantum computing systems are being invested currently. For instance, Google’s announcement on achieving quantum supremacy <xref target="Google"/>, IBM’s latest 433-qubit processor Osprey <xref target="IBM"/> or even Nokia Bell Labs' work on topological qubits <xref target="Nokia"/> signify, among other outcomes, the accelerating efforts towards large-scale quantum computers. At the time of writing the document, Cryptographically Relevant Quantum Computers (CRQCs) that can break widely used public-key cryptographic algorithms are not yet available. However, it is worth noting that there is ongoing research and development in the field of quantum computing, with the goal of building more powerful and scalable quantum computers. As quantum technology advances, there is the potential for future quantum computers to have a significant impact on current cryptographic systems.  Forecasting the future is difficult, but the general consensus is that such computers might arrive some time in the 2030s, or might not arrive until 2050 or later.</t>
      <t>Extensive research has produced several post-quantum cryptographic algorithms that offer the potential to ensure cryptography's survival in the quantum computing era. However, transitioning to a post-quantum infrastructure is not a straightforward task, and there are numerous challenges to overcome. It requires a combination of engineering efforts, proactive assessment and evaluation of available technologies, and a careful approach to product development. This document aims to provide general guidance to engineers who utilize public-key cryptography in their software. It covers topics such as selecting appropriate post-quantum cryptographic (PQC) algorithms, understanding the differences between PQC Key Encapsulation Mechanisms (KEMs) and traditional Diffie-Hellman style key exchange, and provides insights into expected key sizes and processing time differences between PQC algorithms and traditional ones. Additionally, it discusses the potential threat to symmetric cryptography from Cryptographically Relevant Quantum Computers (CRQCs).  It is important to remember that asymmetric algorithms are largely used for secure communications between organizations that may not have previously interacted, so a significant amount of coordination between organizations, and within and between ecosystems needs to be taken into account.  Such transitions are some of the most complicated in the tech industry.</t>
      <t>It is crucial for the reader to understand that when the word "PQC" is mentioned in the document, it means Asymmetric Cryptography (or Public key Cryptography) and not any algorithms from the Symmetric side based on stream, block ciphers, etc. It does not cover such topics as when traditional algorithms might become vulnerable (for that, see documents such as <xref target="QC-DNS"/> and others).  It also does not cover unrelated technologies like Quantum Key Distribution or Quantum Key Generation, which use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively.  Post-quantum cryptography is based on standard math and software and can be run on any general purpose computer.</t>
      <t>Please note: This document does not go into the deep mathematics of the PQC algorithms, but rather provides an overview to engineers on the current threat landscape and the relevant algorithms designed to help prevent those threats.</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="contributing-to-this-document">
      <name>Contributing to This Document</name>
      <t>The guide was inspired by a thread in September 2022 on the <eref target="mailto:pqc@ietf.org">pqc@ietf.org</eref> mailing list.
The document is being collaborated on through a <eref target="https://github.com/tireddy2/pqc-for-engineers">GitHub repository</eref>.</t>
      <t>The editors actively encourage contributions to this document. Please consider writing a section on a topic that you think is missing. Short of that, writing a paragraph or two on an issue you found when writing code that uses PQC would make this document more useful to other coders. Opening issues that suggest new material is fine too, but relying on others to write the first draft of such material is much less likely to happen than if you take a stab at it yourself.</t>
    </section>
    <section anchor="traditional-cryptographic-primitives-that-could-be-replaced-by-pqc">
      <name>Traditional Cryptographic Primitives that Could Be Replaced by PQC</name>
      <t>Any asymmetric cryptographic algorithm based on integer factorization, finite field discrete logarithms or elliptic curve discrete logarithms will be vulnerable to attacks using Shor's Algorithm on a sufficiently large general-purpose quantum computer, known as a CRQC. This document focuses on the principal functions of asymmetric cryptography:</t>
      <ul spacing="normal">
        <li>Key Agreement:  Key Agreement schemes are used to establish a shared cryptographic key for secure communication. They are one of the mechanisms that can replaced by PQC, as this is based on public key cryptography and is therefore vulnerable to the Shor's algorithm. An CRQC can find the prime factors of the large public key, which can used to derive the private key.</li>
        <li>Digital Signatures: Digital Signature schemes are used to authenticate the identity of a sender, detect unauthorized modifications to data and underpin trust in a system. Signatures, similar to KEMs also depend on public-private key pair and hence a break in public key cryptography will also affect traditional digital signatures, hence the importance of developing post quantum digital signatures.</li>
      </ul>
    </section>
    <section anchor="invariants-of-post-quantum-cryptography">
      <name>Invariants of Post-Quantum Cryptography</name>
      <t>In the context of PQC, symmetric-key cryptographic algorithms are generally not directly impacted by quantum computing advancements. Symmetric-key cryptography, such as block ciphers (e.g., AES) and hash functions (e.g., HMAC-SHA2), rely on secret keys shared between the sender and receiver. HMAC is a specific construction that utilizes a cryptographic hash function (such as SHA-2) and a secret key shared between the sender and receiver to produce a message authentication code. CRQCs, in theory, do not offer substantial advantages in breaking symmetric-key algorithms compared to classical computers (see <xref target="symmetric"/> for more details).</t>
    </section>
    <section anchor="nist-pqc-algorithms">
      <name>NIST PQC Algorithms</name>
      <t>In 2016, the National Institute of Standards and Technology (NIST) started a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, as seen <eref target="https://csrc.nist.gov/projects/post-quantum-cryptography">here</eref>. The first set of algorithms for standardization (https://csrc.nist.gov/publications/detail/nistir/8413/final) were selected in July 2022.</t>
      <t>NIST announced as well that they will be <eref target="https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/round-4/guidelines-for-submitting-tweaks-fourth-round.pdf">opening a fourth round</eref> to standardize an alternative KEM, and a <eref target="https://csrc.nist.gov/csrc/media/Projects/pqc-dig-sig/documents/call-for-proposals-dig-sig-sept-2022.pdf">call</eref> for new candidates for a post-quantum signature algorithm.</t>
      <t>These algorithms are not a drop-in replacement for classical asymmetric cryptographic algorithms.  RSA and ECC can be used for both key encapsulation and signatures, while for post-quantum algorithms, a different algorithm is needed for each.  When upgrading protocols, it is important to replace the existing use of classical algorithms with either a PQC key encapsulation method or a PQC signature method, depending on how RSA and/or ECC was previously being used.</t>
      <section anchor="nist-finalists-for-standardization">
        <name>NIST finalists for standardization</name>
        <section anchor="pqc-key-encapsulation-mechanisms-kems">
          <name>PQC Key Encapsulation Mechanisms (KEMs)</name>
          <ul spacing="normal">
            <li>
              <eref target="https://pq-crystals.org/kyber/">CRYSTALS-Kyber</eref>: Kyber is a module learning with errors (MLWE)-based key encapsulation mechanism.</li>
          </ul>
        </section>
        <section anchor="pqc-signatures">
          <name>PQC Signatures</name>
          <ul spacing="normal">
            <li>
              <eref target="https://pq-crystals.org/dilithium/">CRYSTALS-Dilithium</eref></li>
            <li>
              <eref target="https://falcon-sign.info/">Falcon</eref></li>
            <li>
              <eref target="https://sphincs.org/">SPHINCS+</eref></li>
          </ul>
        </section>
        <section anchor="candidates-advancing-to-the-fourth-round-for-standardization-at-nist">
          <name>Candidates advancing to the fourth-round for standardization at NIST</name>
          <t>The fourth-round of the NIST process only concerns with KEMs.
The candidates still advancing for standardization are:</t>
          <ul spacing="normal">
            <li>
              <eref target="https://classic.mceliece.org/">Classic McEliece</eref></li>
            <li>
              <eref target="https://bikesuite.org/">BIKE</eref></li>
            <li>
              <eref target="http://pqc-hqc.org/">HQC</eref></li>
            <li>
              <eref target="https://sike.org/">SIKE</eref> (Broken): Supersingular Isogeny Key Encapsulation (SIKE) is a specific realization of the SIDH (Supersingular Isogeny Diffie-Hellman) protocol. Recently, a <eref target="https://eprint.iacr.org/2022/975.pdf">mathematical attack</eref> based on the "glue-and-split" theorem from 1997 from Ernst Kani was found against the underlying chosen starting curve and torsion information. In practical terms, this attack allows for the efficient recovery of the private key. NIST announced that SIKE was no longer under consideration, but the authors of SIKE had asked for it to remain in the list so that people are aware that it is broken.</li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="threat-of-crqcs-on-cryptography">
      <name>Threat of CRQCs on Cryptography</name>
      <t>Post-quantum cryptography or quantum-safe cryptography refers to cryptographic algorithms that are secure against cryptographic attacks from both CRQCs and classic computers.</t>
      <t>When considering the security risks associated with the ability of a quantum computer to attack traditional cryptography, it is important to distinguish between the impact on symmetric algorithms and public-key ones. Professor Peter Shor and computer scientist Lov Grover developed two algorithms that changed the way the world thinks of security under the presence of a CRQC.</t>
      <section anchor="symmetric">
        <name>Symmetric cryptography</name>
        <t>Grover's algorithm is a quantum search algorithm that provides a theoretical quadratic speedup for searching an unstructured database compared to classical algorithms. Grover’s algorithm theoretically requires doubling the key sizes of the algorithms that one deploys today to achieve quantum resistance. This is because Grover’s algorithm reduces the amount of operations to break 128-bit symmetric cryptography to 2^{64} quantum operations, which might sound computationally feasible. However, 2^{64} operations performed in parallel are feasible for modern classical computers, but 2^{64} quantum operations performed serially in a quantum computer are not. Grover's algorithm is highly non-parallelizable and even if one deploys 2^c computational units in parallel to brute-force a key using Grover's algorithm, it will complete in time proportional to 2^{(128−c)/2}, or, put simply, using 256 quantum computers will only reduce runtime by 1/16, 1024 quantum computers will only reduce runtime by 1/32 and so forth ​(see <xref target="NIST"/> and <xref target="Cloudflare"/>​).</t>
        <t>For unstructured data such as symmetric encrypted data or cryptographic hashes, although CRQCs can search for specific solutions across all possible input combinations (e.g., Grover's Algorithm), no CRQCs is known  to break the security properties of these classes of algorithms.</t>
        <t>How can someone be sure then that an improved algorithm won’t outperform Grover's algorithm at some point in time? Christof Zalka has shown that Grover's algorithm (and in particular its non-parallel nature) achieves the best possible complexity for unstructured search <xref target="Grover-search"/>.</t>
        <t>Finally, in their evaluation criteria for PQC, NIST is considering a security level equivalent to that of AES-128, meaning that NIST has confidence in standardizing parameters for PQC that offer similar levels of security as AES-128 does <xref target="NIST"/>​. As a result, 128-bit algorithms should be considered quantum-safe for many years to come.</t>
      </section>
      <section anchor="asymmetric-cryptography">
        <name>Asymmetric cryptography</name>
        <t>“Shor’s algorithm” on the other side, efficiently solves the integer factorization problem (and the related discrete logarithm problem), which offer the foundations of the public-key cryptography that the world uses today. This implies that, if a CRQC is developed, today’s public-key cryptography algorithms (e.g., RSA, Diffie-Hellman and Elliptic Curve Cryptography - ECC) and the accompanying digital signatures schemes and protocols would need to be replaced by algorithms and protocols that can offer cryptanalytic resistance against CRQCs. Note that Shor’s algorithm doesn’t run on any classic computer, it needs a CRQC.</t>
        <t>For structured data such as public-key and signatures, instead, CRQCs can fully solve the underlying hard problems used in classic cryptography (see Shor's Algorithm). Because an increase of the size of the key-pair would not provide a secure solution in this case, a complete replacement of the algorithm is needed. Therefore, post-quantum public-key cryptography must rely on problems that are different from the ones used in classic public-key cryptography (i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem).</t>
      </section>
    </section>
    <section anchor="timeline-for-transition">
      <name>Timeline for transition</name>
      <t>A malicious actor with adequate resources can launch an attack to store sensitive encrypted data today that can be decrypted once a CRQC is available. This implies that, every day, sensitive encrypted data is susceptible to the attack by not implementing quantum-safe strategies, as it corresponds to data being deciphered in the future.</t>
      <figure anchor="Mosca">
        <name>Mosca model</name>
        <artwork><![CDATA[
+------------------------+----------------------------+
|                        |                            |
|         y              |           x                |
+------------------------+----------+-----------------+
|                                   |
|               z                   |
+-----------------------------------+

]]></artwork>
      </figure>
      <t>These challenges are illustrated nicely by the so called Mosca model discussed in ​<xref target="Threat-Report"/>. In the <xref target="Mosca"/>, "x" denotes the time that our systems and data need to remain secure, "y" the number of years to migrate to a PQC infrastructure and "z" the time until a CRQC that can break current cryptography is available. The model assumes that encrypted data can be intercepted and stored before the migration is completed in "y" years. This data remains vulnerable for the complete "x" years of their lifetime, thus the sum "x+y" gives us an estimate of the full timeframe that data remain insecure​. The model essentially asks how are we preparing our IT systems during those "y" years (or in other words, how can one minimize those "y" years) to minimize the transition phase to a PQC infrastructure and hence minimize the risks of data being exposed in the future.</t>
      <t>Finally, other factors that could accelerate the introduction of a CRQC should not be under-estimated, like for example faster-than-expected advances in quantum computing and more efficient versions of Shor’s algorithm requiring less qubits. As an example, IBM, one of the leading actors in the development of a large-scale quantum computer, has recently published a roadmap committing to new quantum processors supporting more than 1000 qubits by 2025 and networked systems with 10k-100k qubits beyond 2026 <xref target="IBMRoadmap"/>. Innovation often comes in waves, so it is to the industry’s benefit to remain vigilant and prepare as early as possible.</t>
    </section>
    <section anchor="post-quantum-cryptography-categories">
      <name>Post-quantum cryptography categories</name>
      <t>The current set of problems used in post-quantum cryptography can be currently grouped into three different categories: lattice-based, hash-based and code-based.</t>
      <section anchor="lattice-based-public-key-cryptography">
        <name>Lattice-Based Public-Key Cryptography</name>
        <t>Lattice-based public-key cryptography leverages the simple construction of lattices (i.e., a regular collection of points in a Euclidean space that are regularly spaced) to build problems that are hard to solve such as the Shortest Vector or Closes Vector Problem, Learning with Errors, and Learning with Rounding. All these problems have good proof for worst-to-average case reduction, thus equating the hardness of the average case to the worst-case.</t>
        <t>The possibility to implement public-key schemes on lattices is tied to the characteristics of the basis used for the lattice. In particular, solving any of the mentioned problems can be easy when using reduced or "good" basis (i.e., as short as possible and as orthogonal as possible), while it becomes computationally infeasible when using "bad" basis (i.e., long vectors not orthogonal). Although the problem might seem trivial, it is computationally hard when considering many dimensions. Therefore, a typical approach is to use "bad" basis for public keys and "good" basis for private keys. The public keys ("bad" basis) let you easily verify signatures by checking, for example, that a vector is the closest or smallest, but do not let you solve the problem (i.e., finding the vector). Conversely, private keys (i.e., the "good" basis) can be used for generating the signatures (e.g., finding the specific vector). Signing is equivalent to solving the lattice problem.</t>
        <t>Lattice-based schemes usually have good performances and average size public keys and signatures, making them good candidates for general-purpose use such as replacing the use of RSA in PKIX certificates.</t>
        <t>Examples of such class of algorithms include Kyber, Falcon and Dilithium.</t>
      </section>
      <section anchor="hash-based">
        <name>Hash-Based Public-Key Cryptography</name>
        <t>Hash based PKC has been around since the 70s, developed by Lamport and Merkle which creates a digital signature algorithm and its security is mathematically based on the security of the selected cryptographic hash function. Many variants of hash based signatures have been developed since the 70s including the recent XMSS, LMS or BPQS schemes. Unlike digital signature techniques, most hash-based signature schemes are stateful, which means that signing necessitates the update of the secret key.</t>
        <t>SPHINCS on the other hand leverages the HORS (Hash to Obtain Random Subset) technique and remains the only hash based signature scheme that is stateless.</t>
        <t>SPHINCS+ is an advancement on SPHINCS which reduces the signature sizes in SPHINCS and makes it more compact. SPHINCS+ was recently standardized by NIST.</t>
      </section>
      <section anchor="code-based-public-key-cryptography">
        <name>Code-Based Public-Key Cryptography</name>
        <t>This area of cryptography stemmed in the 1970s and 80s based on the seminal work of McEliece and Niederreiter which focuses on the study of cryptosystems based on error-correcting codes. Some popular error correcting codes include the Goppa codes (used in McEliece cryptosystems), encoding and decoding syndrome codes used in Hamming Quasi-Cyclic (HQC) or Quasi-cyclic Moderate density parity check (QC-MDPC) codes.</t>
        <t>Examples include all the NIST Round 4 (unbroken) finalists: Classic McEliece, HQC, BIKE.</t>
      </section>
    </section>
    <section anchor="kems">
      <name>KEMs</name>
      <section anchor="what-is-a-kem">
        <name>What is a KEM</name>
        <t>Key Encapsulation Mechanism (KEM) is a cryptographic technique used for securely exchanging symmetric keys between two parties over an insecure channel. It is commonly used in hybrid encryption schemes, where a combination of asymmetric (public-key) and symmetric encryption is employed. The sender uses the symmetric key to encrypt the message first, following which the public key of the receiver is used to encrypt the symmetric key. The receiver then first decrypts the ciphertext using the private key to gain the symmetric key, finally that symmetric key is leveraged to decrypt the ciphertext.</t>
        <t>It is, however, essential to note that PQ KEMs are interactive in nature because the sender's actions are dependent on the receiver's public key and unlike Diffie-Hellman (DH) Key exchange (KEX) which provides non-interactive key exchange (NIKE) property.</t>
      </section>
      <section anchor="hpke">
        <name>HPKE</name>
        <t>HPKE (Hybrid public key encryption) <xref target="RFC9180"/> deals with a variant of KEM which is essentially a PKE of arbitrary sized plaintexts for a recipient public key. It works with a combination of KEMs, KDFs and AEAD schemes (Authenticated Encryption with Additional Data). HPKE includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. Kyber, which is a KEM does not support the static-ephemeral key exchange that allows HPKE based on DH based KEMs its (optional) authenticated modes as discussed in Section 1.2 of <xref target="I-D.westerbaan-cfrg-hpke-xyber768d00-02"/>.</t>
      </section>
      <section anchor="security-properties">
        <name>Security properties</name>
        <ul spacing="normal">
          <li>IND-CCA2 : Kyber, Classic McEliece, Saber all provide IND-CCA2 security. IND-CCA2 (INDistinguishability under Chosen-Ciphertext Attack, version 2) is an advanced security notion for encryption schemes. It ensures the confidentiality of the plaintext, resistance against chosen-ciphertext attacks, and prevents the adversary from forging new ciphertexts.</li>
        </ul>
      </section>
    </section>
    <section anchor="pqc-signatures-1">
      <name>PQC Signatures</name>
      <section anchor="what-is-a-post-quantum-signature">
        <name>What is a Post-quantum Signature</name>
        <t>Any digital signature scheme that provides a construction defining security under post quantum setting falls under this category of PQ signatures.</t>
      </section>
      <section anchor="what-security-properties-do-they-provide">
        <name>What security properties do they provide</name>
        <ul spacing="normal">
          <li>EUF-CMA : Dilithium, Falcon all provide EUF-CMA security. EUF-CMA (Existential Unforgeability under Chosen Message Attack) is a security notion for digital signature schemes. It guarantees that an adversary, even with access to a signing oracle, cannot forge a valid signature for an unknown message. EUF-CMA provides strong protection against forgery attacks, ensuring the integrity and authenticity of digital signatures by preventing unauthorized modifications or fraudulent signatures.</li>
        </ul>
      </section>
      <section anchor="details-of-falcon-dilithium-and-sphincs">
        <name>Details of FALCON, Dilithium, and SPHINCS+</name>
        <t>Dilithium <xref target="Dilithium"/> is a digital signature algorithm (part of the CRYSTALS suite) based on the hardness lattice problems over module lattices (i.e., the Module Learning with Errors problem(MLWE)). The design of the algorithm is based on Fiat Shamir with Abort method that leverages rejection sampling to render lattice based FS schemes compact and secure. Additionally, Dilithium offers both deterministic and randomized signing. Security properties of Dilithium are discussed in Section 9 of <xref target="I-D.ietf-lamps-dilithium-certificates"/>.</t>
        <t>Falcon <xref target="Falcon"/> is based on the GPV hash-and-sign lattice-based signature framework introduced by Gentry, Peikert and Vaikuntanathan, which is a framework that requires a class of lattices and a trapdoor sampler technique.</t>
        <t>The main design principle of Falcon is compactness, i.e. it was designed in a way that achieves minimal total memory bandwidth requirement (the sum of the signature size plus the public key size). This is possible due to the compactness of NTRU lattices.  Falcon also offers very efficient signing and verification procedures. The main potential downsides of Falcon refer to the non-triviality of its algorithms and the need for floating point arithmetic support.</t>
        <t>Access to a robust floating-point stack in Falcon is essential for accurate, efficient, and secure execution of the mathematical computations involved in the scheme. It helps maintain precision, supports error correction techniques, and contributes to the overall reliability and performance of Falcon's cryptographic operations.</t>
        <t>The performance characteristics of Dilithium and Falcon may differ based on the specific implementation and hardware platform. Generally, Dilithium is known for its relatively fast signature generation, while Falcon can provide more efficient signature verification. The choice may depend on whether the application requires more frequent signature generation or signature verification. For further clarity, please refer to the tables in sections <xref target="RecSecurity"/> and <xref target="Comparisons"/>.</t>
        <t>Sphincs+ utilizes the concept of stateless hash-based signatures, where each signature is unique and unrelated to any previous signature (as discussed in <xref target="hash-based"/>). This property eliminates the need for maintaining state information during the signing process. Other hash-based signature algorithms are stateful, including HSS/LMS <xref target="RFC8554"/> and XMSS <xref target="RFC8391"/>. SPHINCS+ offers three security levels.  The parameters for each of the security levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security.  Sphincs+ offers smaller key sizes, larger signature sizes, slower signature generation, and slower verification when compared to Dilithium and Falcon. Hence, when one wants to choose an algorithm which offers significantly smaller private and public key sizes, Sphincs+ provides a better solution.</t>
      </section>
      <section anchor="hash-then-sign-versus-sign-then-hash">
        <name>Hash-then-Sign Versus Sign-then-Hash</name>
        <t>Within the hash-then-sign paradigm, the message is hashed before signing it.  Hashing the message before signing it provides an additional layer of security by ensuring that only a fixed-size digest of the message is signed, rather than the entire message itself. By pre-hashing, the onus of resistance to existential forgeries becomes heavily reliant on the collision-resistance of the hash function in use.  As well as this security goal, the hash-then-sign paradigm also has the ability to improve performance by reducing the size of signed messages.  As a corollary, hashing remains mandatory even for short messages and assigns a further computational requirement onto the verifier.  This makes the performance of hash-then-sign schemes more consistent, but not necessarily more efficient. Using a hash function to produce a fixed-size digest of a message ensures that the signature is compatible with a wide range of systems and protocols, regardless of the specific message size or format.  Hash-then-Sign also greatly reduces the amount of data that needs to be processed by a hardware security module, which sometimes have somewhat limited data processing capabilities.</t>
        <t>In the case of Dilithium, it internally incorporates the necessary hash operations as part of its signing algorithm. Dilithium directly takes the original message, applies a hash function internally, and then uses the resulting hash value for the signature generation process. Therefore, the hash-then-sign paradigm is not needed to Dilithium, as it already incorporates hashing within its signing mechanism.</t>
      </section>
    </section>
    <section anchor="RecSecurity">
      <name>Recommendations for Security / Performance Tradeoffs</name>
      <t>The table below denotes the 5 security levels provided by NIST required for PQC algorithms. Users can leverage the required algorithm based on the security level based on their use case. The security is defined as a function of resources required to break AES and SHA3 algorithms, i.e., optimal key recovery for AES and optimal collision attacks for SHA3.</t>
      <table>
        <thead>
          <tr>
            <th align="left">Security Level</th>
            <th align="left">AES/SHA3 hardness</th>
            <th align="left">PQC Algorithm</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1</td>
            <td align="left">Find optimal key in AES-128</td>
            <td align="left">Kyber512, Falcon512, Sphincs+SHA256 128f/s</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">Find optimal collision in SHA3-256</td>
            <td align="left">Dilithium2</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">Find optimal key in AES-192</td>
            <td align="left">Kyber768, Dilithium3, Sphincs+SHA256 192f/s</td>
          </tr>
          <tr>
            <td align="left">4</td>
            <td align="left">Find optimal collision in SHA3-384</td>
            <td align="left">No algorithm tested at this level</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">Find optimal key in AES-256</td>
            <td align="left">Kyber1024, Falcon1024, Dilithium5, Sphincs+SHA256 256f/s</td>
          </tr>
        </tbody>
      </table>
      <t>Please note the Sphincs+SHA256 x"f/s" in the above table denotes whether its the Sphincs+ fast (f) version or small (s) version for "x" bit AES security level. Refer to <xref target="I-D.ietf-lamps-cms-sphincs-plus-02"/> for further details on Sphincs+ algorithms.</t>
      <t>The following table discusses the impact of performance on different security levels in terms of private key sizes, public key sizes and ciphertext/signature sizes.</t>
      <table>
        <thead>
          <tr>
            <th align="left">Security Level</th>
            <th align="left">Algorithm</th>
            <th align="left">Public key size (in bytes)</th>
            <th align="left">Private key size (in bytes)</th>
            <th align="left">Ciphertext/Signature size (in bytes)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1</td>
            <td align="left">Kyber512</td>
            <td align="left">800</td>
            <td align="left">1632</td>
            <td align="left">768</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">Dilithium2</td>
            <td align="left">1312</td>
            <td align="left">2528</td>
            <td align="left">2420</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">Kyber768</td>
            <td align="left">1184</td>
            <td align="left">2400</td>
            <td align="left">1088</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">Falcon1024</td>
            <td align="left">1793</td>
            <td align="left">2305</td>
            <td align="left">1330</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">Kyber1024</td>
            <td align="left">1568</td>
            <td align="left">3168</td>
            <td align="left">1588</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Comparisons">
      <name>Comparing PQC KEMs/Signatures vs Traditional KEMs (KEXs)/Signatures</name>
      <t>In this section, we provide two tables for comparison of different KEMs and Signatures respectively, in the traditional and Post scenarios. These tables will focus on the secret key sizes, public key sizes, and ciphertext/signature sizes for the PQC algorithms and their traditional counterparts of similar security levels.</t>
      <t>The first table compares traditional vs. PQC KEMs in terms of security, public, private key sizes, and ciphertext sizes.</t>
      <table>
        <thead>
          <tr>
            <th align="left">PQ Security Level</th>
            <th align="left">Algorithm</th>
            <th align="left">Public key size (in bytes)</th>
            <th align="left">Private key size (in bytes)</th>
            <th align="left">Ciphertext size (in bytes)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1</td>
            <td align="left">Kyber512</td>
            <td align="left">800</td>
            <td align="left">1632</td>
            <td align="left">768</td>
          </tr>
          <tr>
            <td align="left">0</td>
            <td align="left">P256_HKDF_SHA256</td>
            <td align="left">65</td>
            <td align="left">32</td>
            <td align="left">65</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">Kyber768</td>
            <td align="left">1184</td>
            <td align="left">2400</td>
            <td align="left">1088</td>
          </tr>
          <tr>
            <td align="left">0</td>
            <td align="left">P521_HKDF_SHA512</td>
            <td align="left">133</td>
            <td align="left">66</td>
            <td align="left">133</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">Kyber1024</td>
            <td align="left">1568</td>
            <td align="left">3168</td>
            <td align="left">1588</td>
          </tr>
          <tr>
            <td align="left">0</td>
            <td align="left">X25519_HKDF_SHA256</td>
            <td align="left">32</td>
            <td align="left">32</td>
            <td align="left">32</td>
          </tr>
        </tbody>
      </table>
      <t>The next table compares traditional vs. PQC Signature schemes in terms of security, public, private key sizes, and signature sizes.</t>
      <table>
        <thead>
          <tr>
            <th align="left">PQ Security Level</th>
            <th align="left">Algorithm</th>
            <th align="left">Public key size (in bytes)</th>
            <th align="left">Private key size (in bytes)</th>
            <th align="left">Signature size (in bytes)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">2</td>
            <td align="left">Dilithium2</td>
            <td align="left">1312</td>
            <td align="left">2528</td>
            <td align="left">768</td>
          </tr>
          <tr>
            <td align="left">0</td>
            <td align="left">RSA2048</td>
            <td align="left">256</td>
            <td align="left">256</td>
            <td align="left">256</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">Dilithium3</td>
            <td align="left">1952</td>
            <td align="left">4000</td>
            <td align="left">3293</td>
          </tr>
          <tr>
            <td align="left">0</td>
            <td align="left">P256</td>
            <td align="left">64</td>
            <td align="left">32</td>
            <td align="left">64</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">Falcon1024</td>
            <td align="left">1793</td>
            <td align="left">2305</td>
            <td align="left">1330</td>
          </tr>
        </tbody>
      </table>
      <t>As one can clearly observe from the above tables, leveraging a PQC KEM/Signature significantly increases the key sizes and the ciphertext/signature sizes as well as compared to traditional KEM(KEX)/Signatures. But the PQC algorithms do provide the additional security level in case there is an attack from a CRQC, whereas schemes based on prime factorization or discrete logarithm problems (finite field or elliptic curves) would provide no level of security at all against such attacks.</t>
    </section>
    <section anchor="post-quantum-and-traditional-hybrid-schemes">
      <name>Post-Quantum and Traditional Hybrid Schemes</name>
      <t>The migration to PQC is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required lifetimes. The traditional algorithms, such as RSA and elliptic curve, will fall to quantum cryptalanysis, while the post-quantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, and hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs.</t>
      <t>During the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that use both algorithm types. <xref target="I-D.ietf-pquip-pqt-hybrid-terminology"/> defines the terminology for the Post-Quantum and Traditional Hybrid Schemes.</t>
      <section anchor="pqt-hybrid-confidentiality">
        <name>PQ/T Hybrid Confidentiality</name>
        <t>The PQ/T Hybrid Confidentiality property can be used to protect from a "Harvest Now, Decrypt Later" attack, which refers to an attacker collecting encrypted data now and waiting for quantum computers to become powerful enough to break the encryption later. For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client uses the TLS supported groups extension to advertise support for a PQ/T hybrid scheme, and the server can select this group if it supports the scheme. The hybrid-aware client and server establish a hybrid secret by concatenating the two shared secrets, which is used as the shared secret in the existing TLS 1.3 key schedule.</t>
      </section>
      <section anchor="pqt-hybrid-authentication">
        <name>PQ/T Hybrid Authentication </name>
        <t>The PQ/T Hybrid Authentication property can be utilized in scenarios where an on-path attacker possesses network devices equipped with CRQCs, capable of breaking traditional authentication protocols. This property ensures authentication through a PQ/T hybrid scheme or a PQ/T hybrid protocol, as long as at least one component algorithm remains secure to provide the intended security level. For instance, a PQ/T hybrid certificate can be employed to facilitate a PQ/T hybrid authentication protocol. However, a PQ/T hybrid authentication protocol does not need to use a PQ/T hybrid certificate <xref target="I-D.ounsworth-pq-composite-keys"/>; separate certificates could be used for individual component algorithms <xref target="I-D.ietf-lamps-cert-binding-for-multi-auth"/>.</t>
        <t>The frequency and duration of system upgrades and the time when CRQCs will become widely available need to be weighed in to determine whether and when to support the PQ/T Hybrid Authentication property.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Several PQC schemes are available that need to be tested; cryptography experts around the world are pushing for the best possible solutions, and the first standards that will ease the introduction of PQC are being prepared. It is of paramount importance and a call for imminent action for organizations, bodies, and enterprises to start evaluating their cryptographic agility, assess the complexity of implementing PQC into their products, processes, and systems, and develop a migration plan that achieves their security goals to the best possible extent.</t>
    </section>
    <section anchor="further-reading-resources">
      <name>Further Reading &amp; Resources</name>
      <section anchor="reading-list">
        <name>Reading List</name>
        <t>(A reading list. <eref target="https://nostarch.com/seriouscrypto">Serious Cryptography</eref>. Pointers to PQC sites with good explanations. List of reasonable Wikipedia pages.)</t>
      </section>
      <section anchor="developer-resources">
        <name>Developer Resources</name>
        <ul spacing="normal">
          <li>
            <eref target="https://openquantumsafe.org/">Open Quantum Safe</eref> and corresponding <eref target="https://github.com/open-quantum-safe">github</eref></li>
        </ul>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>It leverages text from https://github.com/paulehoffman/post-quantum-for-engineers/blob/main/pqc-for-engineers.md. Thanks to Dan Wing and Florence D for the discussion and comments.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <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>
        <reference anchor="RFC8554">
          <front>
            <title>Leighton-Micali Hash-Based Signatures</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="M. Curcio" initials="M." surname="Curcio"/>
            <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
            <date month="April" year="2019"/>
            <abstract>
              <t>This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.</t>
              <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8554"/>
          <seriesInfo name="DOI" value="10.17487/RFC8554"/>
        </reference>
        <reference anchor="RFC8391">
          <front>
            <title>XMSS: eXtended Merkle Signature Scheme</title>
            <author fullname="A. Huelsing" initials="A." surname="Huelsing"/>
            <author fullname="D. Butin" initials="D." surname="Butin"/>
            <author fullname="S. Gazdag" initials="S." surname="Gazdag"/>
            <author fullname="J. Rijneveld" initials="J." surname="Rijneveld"/>
            <author fullname="A. Mohaisen" initials="A." surname="Mohaisen"/>
            <date month="May" year="2018"/>
            <abstract>
              <t>This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature.  This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS.  Both XMSS and XMSS^MT use WOTS+ as a main building block.  XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems.  Instead, it is proven that it only relies on the properties of cryptographic hash functions.  XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken.  It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks.  Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8391"/>
          <seriesInfo name="DOI" value="10.17487/RFC8391"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="Grover-search">
          <front>
            <title>C. Zalka, “Grover’s quantum searching algorithm is optimal,” Physical Review A, vol. 60, pp. 2746-2751, 1999.</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Threat-Report" target="https://globalriskinstitute.org/publications/quantum-threat-timeline-report-2020/">
          <front>
            <title>Quantum Threat Timeline Report 2020</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IBM" target="https://newsroom.ibm.com/2022-11-09-IBM-Unveils-400-Qubit-Plus-Quantum-Processor-and-Next-Generation-IBM-Quantum-System-Two">
          <front>
            <title>IBM Unveils 400 Qubit-Plus Quantum Processor and Next-Generation IBM Quantum System Two</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Google" target="https://ai.googleblog.com/2019/10/quantum-supremacy-using-programmable.html">
          <front>
            <title>Quantum Supremacy Using a Programmable Superconducting Processor</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="QC-DNS" target="https://www.icann.org/octo-031-en.pdf">
          <front>
            <title>Quantum Computing and the DNS</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="NIST" target="https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization">
          <front>
            <title>Post-Quantum Cryptography Standardization</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Nokia" target="https://journals.aps.org/prx/pdf/10.1103/PhysRevX.13.011028">
          <front>
            <title>Interference Measurements of Non-Abelian e/4 &amp; Abelian e/2 Quasiparticle Braiding</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Cloudflare" target="https://blog.cloudflare.com/nist-post-quantum-surprise/">
          <front>
            <title>NIST’s pleasant post-quantum surprise</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IBMRoadmap" target="https://www.ibm.com/quantum/roadmap">
          <front>
            <title>The IBM Quantum Development Roadmap</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Falcon" target="https://falcon-sign.info/">
          <front>
            <title>Fast Fourier lattice-based compact signatures over NTRU</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="Dilithium" target="https://pq-crystals.org/dilithium/index.shtml">
          <front>
            <title>Cryptographic Suite for Algebraic Lattices (CRYSTALS) - Dilithium</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC9180">
          <front>
            <title>Hybrid Public Key Encryption</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
            <author fullname="B. Lipp" initials="B." surname="Lipp"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
              <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9180"/>
          <seriesInfo name="DOI" value="10.17487/RFC9180"/>
        </reference>
        <reference anchor="I-D.westerbaan-cfrg-hpke-xyber768d00-02">
          <front>
            <title>X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE</title>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="4" month="May" year="2023"/>
            <abstract>
              <t>   This memo defines X25519Kyber768Draft00, a hybrid post-quantum KEM,
   for HPKE (RFC9180).  This KEM does not support the authenticated
   modes of HPKE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-westerbaan-cfrg-hpke-xyber768d00-02"/>
        </reference>
        <reference anchor="I-D.ietf-lamps-dilithium-certificates">
          <front>
            <title>Internet X.509 Public Key Infrastructure: Algorithm Identifiers for Dilithium</title>
            <author fullname="Jake Massimo" initials="J." surname="Massimo">
              <organization>AWS</organization>
            </author>
            <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
              <organization>AWS</organization>
            </author>
            <author fullname="Sean Turner" initials="S." surname="Turner">
              <organization>sn3rd</organization>
            </author>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <date day="6" month="February" year="2023"/>
            <abstract>
              <t>   Digital signatures are used within X.509 certificates, Certificate
   Revocation Lists (CRLs), and to sign messages.  This document
   describes the conventions for using Dilithium quantum-resistant
   signatures in Internet X.509 certificates and certificate revocation
   lists.  The conventions for the associated post-quantum signatures,
   subject public keys, and private key are also described.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-certificates-01"/>
        </reference>
        <reference anchor="I-D.ietf-lamps-cms-sphincs-plus-02">
          <front>
            <title>Use of the SPHINCS+ Signature Algorithm in the Cryptographic Message Syntax (CMS)</title>
            <author fullname="Russ Housley" initials="R." surname="Housley">
              <organization>Vigil Security, LLC</organization>
            </author>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
              <organization>Amazon Web Services</organization>
            </author>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <date day="17" month="May" year="2023"/>
            <abstract>
              <t>   SPHINCS+ is a stateless hash-based signature scheme.  This document
   specifies the conventions for using the SPHINCS+ stateless hash-based
   signature algorithm with the Cryptographic Message Syntax (CMS).  In
   addition, the algorithm identifier and public key syntax are
   provided.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-sphincs-plus-02"/>
        </reference>
        <reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="Florence D" initials="F." surname="D">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <date day="4" month="May" year="2023"/>
            <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.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid/.


              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-00"/>
        </reference>
        <reference anchor="I-D.ietf-tls-hybrid-design">
          <front>
            <title>Hybrid key exchange in TLS 1.3</title>
            <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization>University of Waterloo</organization>
            </author>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Shay Gueron" initials="S." surname="Gueron">
              <organization>University of Haifa and Amazon Web Services</organization>
            </author>
            <date day="27" month="February" year="2023"/>
            <abstract>
              <t>   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository which contains
   the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-06"/>
        </reference>
        <reference anchor="I-D.ounsworth-pq-composite-keys">
          <front>
            <title>Composite Public and Private Keys For Use In Internet PKI</title>
            <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
              <organization>Entrust Limited</organization>
            </author>
            <author fullname="John Gray" initials="J." surname="Gray">
              <organization>Entrust Limited</organization>
            </author>
            <author fullname="Massimiliano Pala" initials="M." surname="Pala">
              <organization>CableLabs</organization>
            </author>
            <author fullname="Jan Klaußner" initials="J." surname="Klaußner">
              <organization>D-Trust GmbH</organization>
            </author>
            <date day="29" month="May" year="2023"/>
            <abstract>
              <t>   The migration to post-quantum cryptography is unique in the history
   of modern digital cryptography in that neither the old outgoing nor
   the new incoming algorithms are fully trusted to protect data for the
   required data lifetimes.  The outgoing algorithms, such as RSA and
   elliptic curve, may fall to quantum cryptalanysis, while the incoming
   post-quantum algorithms face uncertainty about both the underlying
   mathematics as well as hardware and software implementations that
   have not had sufficient maturing time to rule out classical
   cryptanalytic attacks and implementation bugs.

   Cautious implementers may wish to layer cryptographic algorithms such
   that an attacker would need to break all of them in order to
   compromise the data being protected using either a Post-Quantum /
   Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or
   combinations thereof.  This document, and its companions, defines a
   specific instantiation of hybrid paradigm called "composite" where
   multiple cryptographic algorithms are combined to form a single key,
   signature, or key encapsulation mechanism (KEM) such that they can be
   treated as a single atomic object at the protocol level.

   This document defines the structures CompositePublicKey and
   CompositePrivateKey, which are sequences of the respective structure
   for each component algorithm.  Explicit pairings of algorithms are
   defined which should meet most Internet needs.

   This document is intended to be coupled with corresponding documents
   that define the structure and semantics of composite signatures and
   encryption, such as [I-D.ounsworth-pq-composite-sigs] and
   [I-D.ounsworth-pq-composite-kem].

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ounsworth-pq-composite-keys-05"/>
        </reference>
        <reference anchor="I-D.ietf-lamps-cert-binding-for-multi-auth">
          <front>
            <title>Related Certificates for Use in Multiple Authentications within a Protocol</title>
            <author fullname="Alison Becker" initials="A." surname="Becker">
              <organization>National Security Agency</organization>
            </author>
            <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
              <organization>National Security Agency</organization>
            </author>
            <author fullname="Michael J. Jenkins" initials="M. J." surname="Jenkins">
              <organization>National Security Agency</organization>
            </author>
            <date day="24" month="February" year="2023"/>
            <abstract>
              <t>   This document defines a new CSR attribute, relatedCertRequest, and a
   new X.509 certificate extension, RelatedCertificate.  The use of the
   relatedCertRequest attribute in a CSR and the inclusion of the
   RelatedCertificate extension in the resulting certificate together
   provide additional assurance that two certificates each belong to the
   same end entity.  This mechanism is particularly useful in the
   context of non-composite hybrid authentication, which enables users
   to employ the same certificates in hybrid authentication as in
   authentication done with only traditional or post-quantum algorithms.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-multi-auth-00"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9V9W3PcyLHme/+KWk7EMbluNC+6jMTjY5sipZFWl+GIksde
hY8DDVR3w0QDPQCaVI+sDT9uxL7t20acjTi/5fyU+SWbX2Zd0WhJ49jwehkx
IxKXqqysrLxnIkmSUVd0pT5Ve5d12yXfrdOqWy/VebNZdfW8SVeLjZrVjXpc
zYtK66bdG6XTaaNv8MZ35/17Wdrped1sTlVRzerRKK+zKl3S8HmTzrokbZLV
D+tiRf/PEm1fS46ORu16uizatqirbrOi5589fvNkVK2XU92cjnIa9XSU1VWr
q3bdnqquWesRgXBnlDY6JVCudLZuim6zN7qtm+t5U69XDODbZ5d7o2u9oav5
6UglimAeqdHoRldrGlIp+yiDtUcXZPq972mYopqrb3Af15dpUdrnflvobjap
mzlupE22oBuLrlu1p4eHeA6Xihs9sY8d4sLhtKlvW33IIxzizdGo7dIq/1Na
1hXNudHtaFWcqnddnY1VWzddo2ct/bZZml+6psi6scrq5VJXHV0h9C7T1YoA
/eNolK67Rd1glTS2UrN1WQruzwgzTaoepZVu/qw13yWo0qr4Me0I46fqVX1d
pHw9IySeqpfrqsgWcqFeVx029BvdLNNqwxe1wUbKI0+mZuTfVhhnQvDtbUPx
pmjWy7TU7W3aqNc6zzdfAAjBPCf0NAJ0o+f81PO0qdIuvU5jCJ9VuXnZwndd
V3lXNL+d4+8dcF0US1pEUbfqKlvURVWkVXpdtLuAUwF0Z92CCLKHpkbrTEdQ
5HaGSRvOINhKproskzKdtjvxtqw7OoVP67LUU62vByC7KObFuW66ALbLouva
6bqZ97bx7dVZBFxXLCcLO/Rvcxooo4EEltGoqmnTO6Ll09EIJ9r/pXA0bnST
tJpPAA+qLDM5n6j/mpbX6Vj99Nd/kwd/+uv/atUPhr/ISzhgaUn8ougWS1W0
ql4ROGk5/umv/1tdLjZtkaUl0cpNoW/V2Vjd1OVE3T8aq9Vqok6+vns/Ofn6
3vFYHT98+HCyZyBIm7nuTmWbFHMONUvLFlvyZkHcokte6xUdrh7ElvPJM8C6
Lok9KXlYnRydHPVmsCd+XtbTtGyKlhhGS8OtO82HfrWelrQA7FB7aBaedAJC
Z4ZPGh4+wfCHQyA/e/SyByhdUW+rG12Urbp7dKS+W0+LLrks162ya7hs6ky3
xEEUsRf1Sr/vkm80HVGGBUO6J682badp0bf1jsVV+rZt6no5KaZLEMUhQXqS
HB8nRw8TGigxkCQESeIhsXIkcZAkBEnSg4QHsE8KJAlBsoUG/hsEV9fzUu/Y
t6v1qiGazjbqbct0BSyQAFsu02mpcVs3JEHyddbhtgNsx7rTYjLn6aZlPTcL
P354eHzkdrK1EyZrTJisgukmi25ZDqyDLn13nly8utqxiPN6uVozfNg44i6K
nt0B4e3t7YTIq6qY2Oqsq5OjO8ckVSerfLY9N1159ezqTW/i3UL/CqIpbXLD
Y3YAkbVNNqmKtiNs3RwSCv6ss649XGFYi6gsGHb3naSNJxw6DMyA+8eh6nQz
042uMq1e6rRd065AOqp6Ri9UyRkxWOK4Sh/eVf+k/F8nOARtsUqbrsiIQh41
aZET6nes9M/1moRO2U7SVSvHu3l/SJgmkpgcHx/dOQS/Ilb1+8nxnckRXTl5
MLSE87Je5zPSEPp0jM1hFrkqaRGEHxWiStGyVsRi9A7ohErd2Eyw2JYkwrcd
ZJvTMGnScXxdpzlpFD3Y3hAhhlzjQt/osl4Bzcq88SkiNZzDQHHYyBtD2HmS
lnRGe7M/SdtOPSH0F7pRZdrRdulkmrY6hya0SrNOtcWcFALaedp1EjXq1ZvX
b3dANOMpErwxgUQb5LoXRUkiqVgv+2LNE2yREU8pOs0a8Fk511Oin0y9EPha
tX/++g9Xb85eXB2Q1unG2wHU6gecBToBpdBWbp8/LKpcv5+0g/xELpCUHiVJ
okiDIF0s60YjbBfxppaPBJ2CVEVwp2W5IbFW6htQWcx6CHcE+HfnB+q2Xpc5
aVw0f0OaJ82a1DMSX5qUeNJBRbglpFqr8BSrXK/KekNb09V5ulH1tK1L3WlS
XgtAQ3MzW0vbdr1csWgkwOt1x1eLileQTrH8DUDHVVI5Fhp6B5QBYjHEX5ct
3SEpXc/o5BMVVLMiBzGWIEw++a0xCAwcVa1IyZ7Tw6Qu0/KLiofuYYkWPoGW
QJrIUqcVJiHGAsUkJUyQ3i6shcZU6xU2AuCQtl7TnGDYRE8NEWtDMoZokR+j
oxWdY6fukPZ+S5uxIPtBh9j0DxAuQaWMSzXVsiRC3TyFnsHQ0rStuiUFEv9m
JWGVkZSZvWx5NbTEcFTM9+c1DVAW14yBm6Im3UFAUDEIY7WobzVOVLQ95a5N
WaQ3mkDVlcpoGuiwRB6LmnAMgwaDbHj+BfF5PjhftgjeEbJ11ox9/X5VAgWE
v41yRqSi/1tMpbeYBHtKm7IGBbNwiXciJNuJekbjLlcLEgg/6lZoo+5otoIg
KYTJ0HgCLulQtBMNYMkihtCyDtM64W1BIrRVbcHKF/21gx5wC+YtQQ5STWjp
S0fGspFqSa8CHFIZcXY71qBBZn6NhTkaHXAWTEx/VXV/0/39Vs2amjj74yuM
d0b/0O7wpaunZ8kxLtIvJ2PsER9gp7bT5pNq1RVaSAskW8ygmHS0+XkxY9nc
yVh+d0MaA9ipymmchM4lacRlmslBM0ATxtoCapUSVrcs8rzUo9FXZPJ1Tc06
HWkMI8vLMqdG8QD26EMD1GS95FhECrYBbWUtpCLvsOpB4LVZAb7gtpIsUEPq
bJUQTZ4TzojpNHwawEZg0Cg9I6ru5DUN4wlYzuqGdgzsApfnkFAVL29G+wYo
cRKA1DyQqwTSCqeNZ/1ha2GO1BocOF4qaeJ0Lbe0WRLRPKGBwSxSWsvY6M+s
ZJDaSAahwTJRR0rGGNEEDeMVDqtPf/ggL378OIYWwO+TGKbJ1N07d4iSSesH
FRiT49uWXsRb9OzHjyAjWlVljOdHOOYvSFT9QsFRo/hErGrSXsw6aayW3uWn
6W2hpg3RyJL2UNVgyIrEBSFCE+UwJWYZyTJYFPSAxX9XEwvIAScJ2qSlsXUP
icxYzkTuwBoDwm+JIvlEYS8Muxn/HOHZivRsD+QM0iFQU7L3rtUtkQq9uIbS
Miw6iX30mDQof6M7ld7ApcTk/1S48VgVfDYIhd0CzwnQfOqNwCJs1bjqKBOk
F9KXkYCzQpOYp7VvkRjJJ4KFH5rXtDf0zHRdlEywyxpCi4BpiMfz0EAxH4Uh
LHu7v9PZosJ2kxzIb0CWsosCdMx2cSpmaz6fW4OCH7GwSUOG4zj1Zxg0cVM6
GTojWW2320wEOUMsq8jWJe381OglczZZIZKMB9Jx2XZNqPVQLYv5gjasaYjL
kMBbGtIyuD45unNEy6VlyXPYYPPsmpZc0gP3jnAbp6uZjEaP3xMuWtx320gS
CmeNWB5RUgtiAFPaIddimgo0phjRXvCEMvEXLYyOm+IGElAWsM2GaPqAKr04
MXIpjUHr6UeGu6dwbKbACO04ji2px+312LJeqDw4DXQaG+amCzqDJPY1EwGY
KZgBS3CjowlzX06LShweRLlWTQh4xBh4BIO9YXWUmBefC+bctOa1e9edP0+9
hXZiyyg60Csx3IIlvMik8Lz1lZi0EIlPj94Qb3AkNl8XOY6FbIrVbW4XJOOJ
Qkg52al5yx4VpKzXsw4KEKMkA4Iw04qklpArUVBLDEz8IAw2GYWszO4mo/1L
2ASh0PYqh+OYRtZDbE51dws1ECGC5wTp4yoju3ldClJfEh5TMk8JBfvPH78k
dsl73aR5YeTvBQ6hTp6SuFgSE227DaEfS9bv8epcC/oN9loIORAQfgHi3q9o
eXRA8IZodOZpyCiGF8dyF8AhH+7BVVcaDC23F8oN8+K8aLM1aKh/ssSZSCC1
m+VSw38fbxprRX+LgCEW9oxlQKAN1gr2CUImctZTP2lPtLBYtPIIfNbYFogs
wPUvTkuHlNDZbPjIko2qTpiw1SfZsCIoUyCfNf6YPZMQX4tqk9V1k9vzOTiN
bDBEEBE2frVP6ay2yg/069bo/F16TTd5+0kjwDyEoivQe6jksoZai7TvrEIN
dsaeWp1bToeTTr/nZCc1m8lIjQTZGbEuK5rwGO0uzONYA2f83C60jITIE4fK
9hSblRUA8RN5NYPISIzOM79tkUdunya99FZaeE8OEDPTKjIhmb4wz5UbE1qr
EvdJjZNFa1iSqCvr7FplxYoYLuFedxmzj7zWwqSZjwj/MLwERhsvMjgewcwi
4qYazFndrMvKqMr7gruUVtxqv37Pm96Jh/SPvCRW+Cy1pyVRVA+iddXokncu
ZM5i5tjDAwZ0USB6RgKdmXoT3fMeaWuTw2y3jBC2KtuTwljKmjbK3iNRAn+n
YeQEQdc/Qqzxy/jMwAi3JKDAnkjuQEVXl7uMUtBLsE/iHWXDWzQuw+b5D9Y0
iR7XFWvzRARWoKzWZHy02ikppFZcwsPI+iXCS5FYctid13KWxCzRq8Dgb+3h
iXmlqEtNyiq6Y8wEF/aJIziRSKuF/q2eZjhlSYshVXKlnQ3dWFa4wzGy0OWK
GZCMgqXKWC2sxa9gp93IoZPNuNCzohJuIJ4ynCUc0lbtvXx79WZvLP+qV9/y
768ff/f22evHF/idLOAXL9wvI/PE1dNv37648L/5N8+/ffny8asLeZmuqujS
aO/l2R/2hM/tfXv55tm3r85e7AljiFQFob2pFuZKa+3YhB0RGjKiaWEmj84v
/+Pfj++S7fSfXj85Pzk+fkjmk/zx4Pjru/QHTqvMVlfEqeVPuGRGpASQdolR
4J8j9BfwRLKt3y7q20pBCyPC+c/vgJk/nqpfTbPV8d1fmwtYcHTR4iy6yDjb
vrL1siBx4NLANA6b0fUepmN4z/4Q/W3xHlz81W848JccP/jNr0eGhAzvEK2W
j8yF2R4hIqhtxOtT1kRWpIOSvCJGLKTI+3OlV53IZkTQLPn/ClHYrj5d/ZC5
pIJfc64B5ioRWOHxHTGAJ7C5n9UlKaXsVshlNNKO58Qa1Ltviu7pegpHSk1y
r242f9x3sUo6QOspu+M7QJlvTg6Ri0FM2edjHExkUTrH23RsDLOi00uCtUnn
4CaVY6fM/iKSnSjDYjLjJHGWdQpNQ3hwBfRAlIjA3NRr9mdds5gsWE2bqKsF
gq/MbyAx/DCrlOAAmwQz725rYXv0brvWPNaMVIBcJJR9K6tzLZOtoaqBfYmX
e0m6Q+/QsYVLj0G1h5nBXA0DwKD9dqUr8S7RbM4SnM/hEqmI0S1hv7HnkCQw
aKmra8MeCY14Ewhg0YbBAZ821jjpEJIrw05siMRwsCUulKTDsoArN2IG0+nF
/mP5M8Ej1gOzKp0qAq1g7Dak9M8moOc3gcSOIxqXDVIVaLPNos4ZPY84Cg6n
HFM1UmhGZ9AzBpXaUNv08gusCz64GRET3fvRiFvmxdYLAS0azE2REE8Nq4f7
qCyLVYdJyBzVg0/dFsS3ppGeAT2w69LsulUcn2VSIpv2zMHGFNiuYe0X7C8T
tdhKzsRKzr7zYayuKzBFdiJKzCAWojP6BQRW2yBDUZFiBbVxXWVyYmBWDpsE
p8RmWSs5mzea/XOnKv5btRlJYuNuZQ0eghWbTfwCDKAllQV+wGhPIOZ2afpY
gPHMk27qdGNvpTlvVhPTgXEHF22kqwShhEifce5pkiYznK94u1hNlU1yBES2
VsU45tmJWnKLUtIqhZacOiK75ye3yhzetGii8wt734xxY5QyiDbOoSGxp65c
LPF0+9og7pF4BRUDFoQEShCMMhEscDzYBmOamxXEdSWJWmSWEuepczaOHB/N
0y71YYsVlIEGwZqCiZXtnkkAIuJqSySc4V2Y0kZJ1sQSgr1IgsUS6ywkMWTB
oa/UuCiL3RvHx4sHTlnhjXT+3OCoDYCSkRkVxjyVGJtxiOA4wtngjtb2GBOl
xL9/Q2c8NeH8ndkKoxE9KfokCSb9nrkn06c7ZJ/3t5pzX4phm5N4zMAUxKco
JL/tADNeTDZhJt7K2nLPjJ19E1laal9P5pMxAi5iwy1SOsKeT5jbT1+enSeI
vxyMWYSwRaDBBtmmsCfemshAhFAdj0kLQdijmfA4Es6ECQLKYxHNHjmOTrFw
FEcTe9EifEWwqX27IASITg6MO8xD9YVAeX8ZSJGOVgv9IjhSmAuCdyLRt7Gx
nEmtQf4j75U4Ndv1FFYSO154W7p0zq4hIXCJmoT7E+w/JxI0cpwHQpC0WLJV
P3xw75M6DWbKWgKda9LXWGv6inNsWLNwcobMDKLNk6Pj+xKveGVjTM9sthiI
1abbiJHyxrvJ9zHiAWR5w2q/9WKxU6mm41qQXmQclsYr5jNpDD83gNo0EDpe
BWPqS0IRYgVgA9+Bb3tV8uem/hywlDEqTqv5iIaeirpRvRQgtWuuMLFOsM/J
LkVz+ODu8Z1DEhNpeaBu4ToWT6eYSP9lTScH2jftFO+TjYLlLgJtgygbp1K8
q42yl0KlRLylgWa5Cw/463BJmnN6ePn5bCjn/TjkQZO7h2xIwP5oWSfntOgO
nCahU5Re4yqASPh5ZHodMCEEO57CiiOirThTE0LBuqrfwbn4swAny4BYM5Jl
AlAxCgMHz3HdklywDyUtGTkJY5ghw55CH87gJUa+hGxzLyrgmH4g9tkA2c5b
kHDBUKQY4wbR5c9qphAwr6/OGDOPz8+tA8U5RKeknovDOfJc8/EKBB1pGKWk
AO3M8kiDIHiU7ArvpZlNp9mCAPoe1sp6NYd0hYi0ySU23tfz9fLqmafo94WE
suC4gnt1IM4u4TxdsCWTMo/aXh8hbVHnqrZP+L2RO2OjWhgbZlHfWiweohCA
EHnLASrnDxZjFWgFezT8kQ8oQTx46vHYV18aOIDi9s5mWiXPN2RfewLvZ1Vd
4/bhwani50QOkgK2ph0kc7XhUy5IahrolfsvX3z/+MCkmg3hygAz8SB7zSyG
zCWA7YbO53wd4FVJhfOPb+Wt8VNXl0+fvTq/+qV/riU6rzIZ8kAAO/fHT9QV
48dgizNgJ4M8mPgh9kw8AtHTRu3mHbVCiT1LBGdG/MdQHPZJnBgBGyBqLcsA
msGZkSPJWBRqVi+zx2VBakPAwuTOZJlpvmNWTe88evb8sX9uStZyi2w9/8DT
787lPm9Flix+yPzNq+jtlt6We2r/UVNf64poiBOKYViuoX0/a2tSHzcDJLuP
sQ56ShfpI6VdpkHj1bOLp/Tw4KhxNOzAMYYJ2eUZm65gM++inCwxfv0iNMzQ
blKkWcNrAZc+fPj1PeHUznYDKHvzcq05YbtdEU3umQSYpUQTjh8+/Fp+e9wg
D+05nQE+9eJxselpGIhtGHF4SBaYqDH8N9vy7OSlo8YJSra8APYoaUw++wWZ
UJwmACTysuCnrG9bF4fR1oiHWgl/s0seDK081RP6LOyxPQy+zxNisJ3vyngq
bC6AGG9sjvCrixTaw7Vh5IUNwxESbIgHnE6y32i6la5XpUS0JUuNrwp7nzJt
iYtG3OFhylls7+yOGhAULt83ncUxfYJsZpxOn04T4DhZnG/Ye8H4VpgQWFia
VD4EI8x59SkgoxGLNotSGzF2SZoonkBEqa2zgh2aLvUkyAVNtzwx3skTWaSx
3TUgOnORlmu4S0LzxKePDEdOqyh5R2LBpCzNJPHpUgMkeDAECxZIziXrQAQv
6htTNWMtYVDhbb2Ffolxi6/jNt3YQGKZi4s0znAVct2VzspS92o4+vzhK2/Q
jEYCWeh9Ea4V1+wEd4WgXaQnypOjl3IcnQxMT+frlXE+ubIfUnQqlwqSs99j
mpo41bYlFuptQTlRCIubu9z4RJC8xn4ZcvPZAIY5bCXHVNokMLcmb5ijyUiN
825Aaz2RtBG/H7vksxSq1yBotJh1ZlIDfAQcSZPe7SMumOOTBwmS6XYkC9Bz
J//64f7djw4WP4h1dknYtWVWHKU0ElZmOjVplC5jx4wXAEO/gQ+LxQQve1nq
kvmBfd1YvkR01ZCtLKxyJ6DBBC37tSUbe+BwG4XfbnifMBe0UvbVVIkFk0Qq
4JMUHs3u8HBLT/41i3FCJFhwzohfKO8FTQ8Dhz0SIBpxIG+DwcyFDUVOIYBT
Gjwfvkm2jRozjWzcPm3vT//9f2YHhycfkQWGJHqULtCbxKZkjpN79weS3XgK
Vq2ElhDn5VmmG3V8CMfC8dHJ3Z/94p0TE0jGjhK//emv/8P4OSAoP37kux8+
+JKVjx/pkQPwFCSWbp1fn17k6Je4ESjYPgAjbculxLlUJUlVhK9EisAaM+yG
2YbVm9q6NCEnUmPqtuV4pc0OJtwDoUHml/Ofua1zXpmDMQS+zEbEJB59fxIj
6RRkOAvjAJsqOWcsdmKQnKOTJdDXSw3aQ94+1wJIPghEawU5A4DygKBv64rY
RofcVnNAhsgecSbkU6zqwqRw0mb+Rp0vSIB2BArXXHKOoMRtecKBcfalWkFJ
8RPrmjgI4VlSYsccWP4n/GuKEJdDuFD9e+Bo1icIs30fPkRloh8/Eo6eFDZz
yqasBQl3GYJhxBd4RHbhstaG5JtAe0j97nDNhwLDp0FMdYZJdYRbNaFTN+bM
GpckywMCSbZwJONz6+0PNr4JD0vNp8hAEiZQWq/7QMEJjWumlWwKe5ro6HAq
LEpJWk4vtew+EEO0bYi4TX3olFAZqXPMfJHgsSGEiibH6Y8jFvRnw6JjNPrp
r/8GzSQWTSizNTq/BDgx49hr08Q36MTZvR8M4dnaDyEpk7DBKtx2nM4+e2CF
lU9GZdshdbExVmZ25DlaF51RiDjSxsLaimMkc5kA5hgiQDQhTu21StdY3pB6
ux3zBLtiuMjrq7NxPzOR/Uc2QHnORk2UtJXAKXLgslmQmkb6TcU20XbUw4eX
JF3R1BZJlDoocAnDcH0F1b3lgnamSgpgpXTyNh1boFaLiQuKyEiqO2OVbBMM
U7QwqiDVqK/vs1iU3DyvhT5hC39YXoTlTz0HGyDTKW2YFwxSVsSE2bcyua7I
VSOxM6+oPHxRNh0kXT8mTLLtkVHlwKZJeHEag6HIlh3qM6tLJhxIM3tTO03Y
8ibtpJVL6closLEkJ4u2EHow+zqpdxGy41xCpuPYz7iLdpcIGdpAUVwyB62q
V5XD55+MmS2E7Rp+v5joyfjzTGFskhoQ4092xfj9w/aQ2IB/sivg7xiJsD1f
rM/+AJfuORqdEatEiAR54wygGJZpTuIiZfyTptxAOQdhlem64koJZ1TCs16z
KcxDEjA9hcZYCa7YA8qmfaCW6KplPkEZxwCf0uy0oMHGuycrkCTZZppwE4TM
DaxTCVtiVKanoJZHBAeS7GmvJHW9xRHN6ga5iHWV+9Cz+GtpERyf9HmqUh/B
Udn/hp/R6JfJjp+dN/jm6C9qx8/OG3wzeG+z+7332+99CZzbz3wCzh1Qyc+P
g099EiVuRoPZD6fqq5d1m6VSdvwve/IHLK5y76ONjARlEDjSpOivZYeJGRUZ
jv5U/Aak3sMopuvBOC5jnTeYVJMPH6LmGKSn2Yj6hw/8Hqq/9t7vEWkgb1Q0
AjYlRCtaN1H1I9OSFVjGHSZckUbZsEdRSXcf8D2nypD1yomyXDoClatXMcKp
kj/u+cmlbsYcsl7N1UAJ0GbrIGqDDy5ItmlPvXNnTjZnX+L0QXHnMGst8W3O
ZeGMGQbfVFtaJs8Yxpp5lTZXCOMKXtowDcY6NJ2EAMoFPSIfSOKUxUxj8eCu
a9kIgp2e/CVNMufkrTUn3pKuXiB7zIoWCE5G2wyqrSw1AASylreINVWPGk1k
wlH1EsrtdctRH9DcLXucSFHmaBBRwLM3jgjytfHyIYPKrZ5z2AuT+yZZt1xi
LGpKBQxWpFn/qPsvHgh1uJs6LG1F2e6naUbyUaL3xeWInBTP9vR7JHxt8bzA
YhHAbeKREBwrAK4KUVux6OpSvTfOqvdg1FOjuCR2l0jH4ax1jge+T7H/NBFh
s0mQ25e4ohZbOAcwBxJSqlyi/d4njgogq1kP6HTiLON8U4RwpAZTTJXKQsKV
n+MwO6zUEqQ0qLDlDHEFa/rJAswxG2GNCWGIttEuOMnB9IjgNDWJf2N/EUt2
qo8tOIVQXLGvxRYmcirk8dHRka0nnXLY/54USegOlaewUA2pskpwfHSd0CvX
7hW9IbmI1+5LKavpcyGMsapvbPCmY7/2UrbjNr3hnKzaeJ2NiLaFJIz4qa70
LIoT3JAdUKam9kxOFErSFBE+H7mo/vmrTxQMmO5r0CokXmdZoEm32NKMdxbE
W57naomlURq/xYtqdKhG+olP4w4dvMULE0IVr3hubkk82PTLSB7xE1Lekjzv
lbeMRi+ith+79NKS6yHnRjqxZ03HCU6EhNJ16BAtFuxPwm1IqdbuOfaxtOKb
fLzOSlLt4ddZSczdaNLmVdgjuJEzn+Iy2QG1m60TSdtBeagxfmzaIxdU/06z
lorOCGUNy9ZcuLQ68osoUP2YA9WiOcd3XtdSW07nWFputLrXpmFe1wwkLRUs
hw4F0UJXJ6ngkI0VcRtKAIyFDevN1p+O9VQc9TWmS/imIX0ZFldMUrnQsgR1
6Bmnr4abaq3guvK7hdNUmHYKC1Z/uMwMjq+gJIXoo2h9FoekhfIIElN0/q4x
74IwTN9pxFVnOVSZc0BmoFRMGD+tuFM5UWIPiNwzM1uaYk9O04WHV5JwkNFM
sm0u5VL+7oHNJSls0VS75b8nwWZd8AEoe9O0Pz3imMT1hTNzgpyb8wAEYXyt
EjIS942JG2j6tWuKG5L2NnLWh4Kp+LYfzmOXVE66RcWiJjJZUzRVlDCOLZIV
3gg7OwSf82hcDqpokhF6+QEf0ZVpolf2g/EOiCFIYQHQRqATfRazTehvmaI/
ic6uud49kLxjc2oNFm1xesaHEvhU7RJKdWuqxE0iop3POyece0x2BhnM9vjI
0AcTKVFCev5mHK0utLNDNBxsZSuZCjMXV/ULNK6rcF7nTXcAIGvFdMuI/aj2
jATnyK5o0mfK9tCu27WhE8dkxKGduoYallG0vp7Zb3jo/VlK2ibSGmSoXiZZ
P1UfBGX5qvhWLPQmMQrJSsTRL58/+71Cn0NJvtYtF9vzzreu8IK9IL0sxaLK
ynWuJYNobPpVSV2ZTd8RufYUYu+TQk19+MrLRjLr8IbJw7h8fs6qEXfSSSXb
RvonYSlfo4mAjx8TCb9IObrNcLzUzTUzCE59h0nHsdktX2MYVUAwABWY1oWN
SpMglwS2ZJgf4p6zfjGbY/mJdOGJegkOEWZzL/yCA4L1LYT8EqO1mz2wGyvq
o/r9y6srko4vuW/No8vvriw9TtTbivXqbQxwxWjxw5opDenoga7SDmb8cx8s
MqNctNV0iUqlBRlgqjTXmHepNZJNpyiHK5sfTXRisrdiH/wC2xFrMk+/fX2l
9plA6FB+O+2gNb6m59CeZz0l7e7AL8ZkV4tpKa49Po3byDZLMykorawONoAH
7ZdsMFdhmjugtYALFsIAdzA4R9oL/zBbJum1Zt8TK+qmfdtEudluQ4MgyGpl
MkccRU7XObTIz6iMbGejPTAnRIYHD2r/0pt5xw9BVYDuwVHbp/QlLD/Tq2bm
MtCkryapI5rUY8SrDCZ6lT9tt843fnprcLgpOM8wYTdc5irUUEYgMb4Va6X8
kOo/5DgR5vmmXq1Sc33f6vYO1mhy0jNQxZdbUzHX5o92U+UN5pVh7ChPUzLA
6Db3SkzONxl49f5TdIOQKmq6msnVl3UuBnDODkwUmjCXYAGr9r87T15eXNJ7
ssiA4dql2OZwHJ9jBVbdpfVUkhd14NNGT1U/JXCsniJUiKy/CbuEkXXIpPK9
Ie4Ul0ajT+SUckqpydSLOZk/W72GCaVrSBFVF4gwc5lFt7UonrY7YepdLZzp
U+lyYro5wN7l82rxv9hMmyK3HinAa/gRWBD3Rum3Oglyn/e9Ti0hqK3AvPFV
6aV07RN9ylRprG0/i2hdUsXNLxudWSo2OK8fOhQy89gM4RPRRfqZ5YKu+MMq
671BoxkFKF8vAtXTFEqKr93oZuyx5uIfUYx76X+YA5Gu7QnGQlmlceTHyyUI
LTM2FWQeTD8lER1voGuYN/ZuM/ZcuKDa5XemTqvRrlkGfP0EmGGcNpmoc1vx
C6nBtQ0sJAXbsOIQnb+I2/hxFRnLvl7Qcv/i6QGnqtpuKiD93x+YLXMZXUgH
CEG8jt54xXmtJjdiY7Sey+ePSZOh/xOPEMoNAPI0d6A+fPjN6yfnD48fHH38
SAtKS+OHSa2KAFIhRBmYQKOhG1JhChB7M0UH8kYSu2g2dAbEhthKgwaRjMLb
l0JQtFdg6W7O3hHCBo3V84snIhbOHp9dODVg/yyo9svBS+w54rF8axh1kXYp
KdeMDcPiWuM5SaMxrFI0DlQbeNrEBAkeFXNRc5t8ca+tGp2YOiu75VwMvQr6
1WyPszXMJ5LbDVeM8miN9uu2hnmr7x1h/HFGBEKHTPQK2EM/ioiIBDLJ5WU8
OdF48dT8zocF2um+XdRBD31LFlhpG8c0rown53hygjUSvT1LLia3aJHXTNO0
SrJZM08Wq2udvMdyvr7/ID86So5O4OGTpMnt/B+koz97dZGcn5+dqFOLh21h
dJUissHJSSYo7N7yHR3dpX36zWek2oxXSes857zp5NwztzOO942tV1edHMQ6
Wu71c3SGoyfYrt0SINLzkvt+GQZq26jSGQu0e3ekxkNJA5LXnQTM12QG2wZN
3JjDJD/mgBmHlcPOBNZcNObbgJOath39YopIkkceUPeUFKVvq/mhlhtkq0Z+
wZy7gkCGx1m1UZUq6dmsgM1oY1uXdstxffnqhVSdRlWsHvKhdLLc9EQ1YIG8
Hr99kpy/PFOn3qL0dmZAUPY5T0/2yv5jVAMZ2fMWWfVzPURUpPmI6BaKsjUK
A8SzC6dCQ/N12hCCtOM0ld/psSRiCpvNbN1i6qylmmQLvC3oY15zFReKP4kj
lkVoqDAvR8aw5OkZncMv2W0r7WhtKqfM+beEykPTFjnyZNK3egKnMUj6FvwT
lr+YYzCQqDPdWNrm+qbdNd3cRjVdo8qoChtVi8C8kNpRTPLk7MX5t6/G4bYD
FmsajUbuhnrny4lk0z5l3e9D97SH2RYkKa6G6dV9OH9uz9Vj1FZbKtXzn+PN
l3JryDltB5FiKlMEKg18BlNeHERPCk5BSpeFydo4m0KomAo1pjRvJTf6z2a/
WxgVJl5kulfb5cjQT5xrwLUPZ9WY9fF+bzePc06iaqXUAZX8DaKJ8D2Lvc3G
OG+/Ie3JkPzAiv2QkoozILMeBhILXWGSkhaFKkvzZhK6rkReGQ5hy8YiTLKJ
ePk7cW9wWQ+QH3dSD84agsNs8Nogpljf32h8QGSsLjVplMbZ9Lu0uF5XyCpD
zC3SCPwwvFVha0brV3OUJOWppMet8hq2FduFjTe7JiacxdEyQzumq0bJnhWz
+sJtKciY1CkiUE7RToOeURzQubVZOy67lYPDrKzjIC31Evx8SpDdFjmKfoP2
3/s25O7ywkKfBwlME5UPVF/cOPD1Ai4mkK9dpCSAnD9d8Ob1W4ehifIioK0t
LXLKkA/zWp4KbLKn21bPc6g0F3nk0OibFObEUlvmnh6TXCdkIYMdYIIChiFC
H+t3SVyYftfctrWsxRsticqStaW5GkR0Q+J+Z4E4IBaBjDX7WiKvtZzYRLD6
7fVGFYuEjE4Yl707LIyDw0x6Jv0bFtlFFXJBYAM+iBv47J1TSFgEyzd0GGsZ
aex3W8GkaDkkZhbT9nw0OHKBa1HCnqZfknZB4Zp7t5ZI0yuseGaVyXvL/Yb8
ou25JHxBhY2rBa8NBMcCrkNzGISiiaMEcXtuLxshcNE5X/3s2uGRXoiGrcuJ
6Z/X45cuqV7K4lrJC5Y+UkhrCE7NPO6/R8fCwIcwh9V3ejkN/u2Q1IW+8ZEl
pHukm6ARyu1Cs3uVBc5qZRsIeMbEE8zwZzy+h47DPjvmfcLNihueghgc+P5Y
PuWh48PE7fPZL2o6YSFD/LXOrLTwZRdcCFW09ARnzV9JYe8vfX8Oo7QjJYmD
FtZ9O+jHdg4j1JoHy4AHxvuNg3aKNUdGXat4/8Z+39T68CEIZHy0bM56BhTR
N7yo1h/umIQ9Uax2A/awBNQnEGnH2EzKx0R9axzlA976XsMA77D3pvXTq6tD
BApMc7x79+4anCOGYK/eeXgMweoc04blivke1x6Yryz0KwYYz97rH74grSlM
SWzQBBg1A5x9EtQT4OtWJwNXATCqhfp30PXUUooBWkKVja9/G0taTtP31hNH
K9HUe8fZZM4qD0TyxQSDfd3eELOZqKeau9Dz03Bv3HIgCAUMi7puTeMKVw/j
CwTa3jcF7HKsS8KXZYYrdEgITL4pGXBYncnLDiJ10PcTWJLqdzQhkTt+l6u4
Pxp9L41oRU22L4gikqL0dG6Sna07tJBT6PMDLREX6EuLMS112ze2nouaaKbe
r1SmG0mbdFQ13YTWDBcyspNsVrzX0PZ+5OgXB65nfShFKxrbxp2cO4VHIGab
4MmO28epR8wSkoUsYGwCTGsmwcA9wL1SvRUqxlfBfZYlt2Gh05uC69JK8fbZ
9k1lycI1CQYzQMfthwpu6kW4PPMfD2Fj3GEFXevHn9oxUaYW9osWUVIKipYi
mTo1NXSeKUkxgNEqDZ5aAQjehQYNGqEwG1y5mNwSUS20ZRTbmKMJCzFtZAyT
KYKRWZO2YiUqXQwV0tp2apVjiU5P5is2HG7reuqBib0GGLEGkYnKVa1sneQ2
wDCXqCaJI9qyWBJP3PfW4v2J2joNEqLv9uS9UKa0JxJPzFkk5d24a/E1BZhc
c9mBIO84aJnS6DmpKmWQn+TUGjuv7GGjROqYcxnwAqaPOWLoroKyX8YrVQCA
O2xGbSSV7QLqdCZHm2JLW4MJNX3IyzXRb/x5y/YtujHaLOSge3mWroRaC/Yj
2NZnplQlcCAgg6fiXkCSP+S+RGJFseyqCQ8HRbrITDJuA84MsKaF78vnebzr
lNY5aqOH5hw4NZgei8rFTLh/jC14rv6j8pEnqZSTyh56C1WCPkd6UEVzOkKQ
f/QpFmC+QWB68YSyy1ZJpCVauPawZ8+06U8e4ihqC4MGHfy1VlvcBuCdY+CQ
jGl/LNGWU5PEI4Xwq1AhFP1ePrs01SR/oxz8e1vKhREbLmRuWUXuChnDavq3
LSQsl78Yb4rBvHlnoJfntkYT3Ss4dMjkaOOJPq+EHa3afIHHUYEID1OK46Z2
1bj4HBH7wp6e3Yl6K4kHynw1lKW/6//Bn2Uz79kHnHTx7SuwHTQq7dVf/L68
4DVFpR001CFP75xk28Un9idq//a58pG4CET1Lwz9fNFDu192NSvHDg71pAjQ
xGHPylWxbq+U4x73jk+sY5p/tQoX2hSSXkpvzg7bcKXyc7JjUr83cIQRphOM
sqsIx53Skx0PxJPe+YKVPgwgixb69f0HgWF7Z3ulD08GV3r3i1d658HdwZW+
CjqDqE6+7mQ/7SXnbmvSe59fKWAOVsprRP8Au5vyu1vwva0F039Y8F+iTvKS
xxw/+H6PntuzLpV0Cp1K+JjlYNYqL0yIyGnt7CLYnx24MJdNuVT7rb+I44sK
GVRR47DHXAntkYzlve1MzZZtYnplJfDYceTPfHNI9K3c+uYrD1ZU6w/e5vMd
zMKiL4H4L8dF+lcVpM73uTeQhX5Hkq/vsxeMWdM3dMS75KJnhz2L7vN8rcen
/hJ+YoL1o3000NzQZh3w3R5Ivds+Tnl4FXtFg+d+Jtv7NLv7zN0v5JXDXDH4
sSyvf/PB0dHAwQ1ePb5/Z4tHxWed+MvAEGoH0/Q/WzzQreDO8QBbDF49uXey
NWUE08ndk6FlqR08NfixHLN/8/j4wV219RPCdHcbk9HIx0cPPoungPv5H8/V
+jB9/fCO2voJYbpzdO8Tt4HpO5/F0yBMnuv2Ybo3RA3Bq3eOtx+IYbq3G0/8
MYOlqdjjFouPX7b+pLbqpo26w3PyBXKD2oPwqQ9fhc5JY4CI6W28uNr5tJCO
Ynye3KPTvSiBVcsGJScKOp6fJvxQim0WEn9uhp5HLgDZr7qiUWvR+1vnZeX+
N5yUGeitrj/xMEcdf4alOvtj6FNRrP1GvchgKOoGxpS46UzjkL4L0UgTTmsT
SWIcam003A06jpl9i0SFdwzKesZDwiNeWCAhLr/7ewoJ+3MegxI9NSAk/sHk
hPr7i4qdkiIGy03jrl2SNvanp88vnvzJaGbBzftbLK437zZQPbCGR9gC6x9R
YKhBbN07OXbYMhvpZeuAyAjnvX//k7d3jbAF1j+S2PgUtn5/cu/e8cMecTkd
YdA8+zm0NTyCgMUsswL7+AKOuf0Jh7+JfQ7p1/9vuOdu/Vr9/8E9B5XaLa32
/55S+zdzT/l5fXV2cnT3Qe9mYEzvAmv7gVjXHhxhC6xh7undEvHN44f3Po2t
u0ef4Z53ToaU4y2wdmGLRc7WyPcHWPrPlDWDI2yBNcw9+5bA38cQGJ21HO+E
jzUrpai/nrYavY1c/6XAOYLwrLhiJa5i9L3IoA7jobZNlbgcYs9AXKWwpcqm
PnYWxm+72ATg4oBA/5+oR6YZck8Fzn0oW/J93Sg9dzF6TKVS4iAxHt9ziTEi
7TJMxkLq26L5TwwFHwByjbSbT7SKIjMm+tbU1neliG9KKy+7AvSDZmCj5n6c
ru6SSqXWVHzJE9ebwX6hhr/kEaDSVERcyWJMSptrGUN4v5ROUSYfw4ab0dpR
cotN01Wb7bn9+V8OQxUuz2XHpzmr2n4BevCTBdLslZus8beHhCbs9y05FuW/
f2pc9bYnjckwG57YfwPHfnkh3oKxsde4DqxWUV+KtEyrTVu4Ty58Cv4ZWjSg
xXeD9BLs2rReb3UkDz5oOTafgGXvnHzUbeySjW13HhNvG8dZUNGXOON0KRPP
5JCefCo3Dz43hvlNxJ67KNWqQQotAA2a6kY9+2zQgut148ys6XoOArzwSTNB
fxxhMsGWYDt3fa5CjiRyp6aI3CJtstHK1NL4kLNU4ketBhH04fTYwGe9WYEk
Qu/risZY0f+7RErbEkml5Y/dcCkQ4kOmvZS/443uLz9gkt5x+d3hG3vjvFfh
IEfwU0+4JKaw4j44DYZb7T1NwUI69aq+HasLUyL2Al/u2zPbNnbFsrYDu+N5
2rceQROiuPlUhWZL+JJhKh8xnPn+7kGjXw47Z1I2eqsbfLVQV9LkIWxpG1SB
yDfmOW/N9TzgXC6/VV3Z2k2S7Fn0AGOJUjIFuzDtG04o51xIAps7xbQ0aifN
IHitKAjoCi7Pl+KgmfnGCOHe1DgKk/dtAFlCNqYXcMmfHYOTiYdHX8+i8wmY
Ycom9tSALS32DbiSGMpjhl/Ls7OLY2gqn68g5FS+nwJ8WKbKSh5rg1RnJgmT
QxI9ZBm4+zgL0HQ8uaNsixOkAGwT6Vn06av/+PdtIo2f2KZRyQ/k1DznGLPV
oki9Slb8DWFLe6YYDMVb0hsJlfecl43zvlrZdvzm81ucfCBp1+67WhG/34JO
mMRWWqBJ+ug9779juk0baotm7OgcrOe2JwgsozIA8SPWuuiM0L/Rx3dsJo5J
E+5itQUpCVUe1lGZaNITbl4mSUnjHiBBRr7rGWOKajE+iSTID05Xi97bga2g
RfsXPe+L72zTPe5huhNEc8zrddXeojlMgq/RAFMtWnWifPnjx38mBCBPAisK
6g1Mw7Ow/QiaixD61iapuofudij6RgMmU2lKwt+SWiLPI8HqONmVnaGSi5tJ
WnS+tkm4NuPHfCkp0HRZknJ+oXSLNd/wYr6InCEkxdnmf2E73VtdzBcm97t2
1R3aRSdT+yVZtEQJihu/4FCyVui8A+fhN0VIA7xiPb+UTy0FfSY8lC61yH7m
nqPA/xzrfmgNBy5oWoUANGmOzHnaa0lVsRI0buHtOqp7vmu+0OY+SCffswcq
tdHZt9rbsR3ApcuSp8stzHJb1I5IJnJjOWcq+CCklH2gwYhQEToNMOVkrvKs
buZpZRR8fFmgzp0KpuVj2IX0f5Yvy7hG4sK4i367eTKpSsmeZZbn6i5ME3Nk
O4X9U6WboOTWFY3JZwPzt/ld1ikkGWhj01GB25Ygvc3p9qsytd3fg27qRRMn
K7rSgHiLWJB2TEhPTGj6tWm+90/0m0mbYTlir78giTPaP8N3hnL3IWn17ko3
nMsdNsrwXwiqauAwW/DXoVt5VNB3MCG9izO1WmumgE+Y8mluzEMkWKam6/6E
55eknrQloYBVfF9cFyt8Xo5oAXmSB6b+TXq8NOFCEvUOX1hWVs27SmfBN5/w
PT6jAKGvrfkwkxRZ2H62WPM7+db14LevMUYSdscFNOosg8Zf6nwu3/McfTiV
HqU6/5c9skpajfarz8K6Mw5esBI4MMsqJQG/qGezZVrFHwGMPrd9OC3r6SEk
0vanuCdL7smQ4psvSE4jMvre1vg8KeuG+1peuLNtsg9srYaknnWkCf8f9p8J
Y+mdAAA=

-->

</rfc>
