<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version1.7.291.7.35 (Ruby3.2.3)2.5.9) --> <?rfc strict="yes"?> <?rfc comments="yes"?> <?rfc docmapping="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pquip-pqc-engineers-14" category="info" consensus="true" submissionType="IETF" xml:lang="en" number="9958" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion3.30.13.33.0 --> <link href="https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers-14" rel="prev"/> <front> <title abbrev="PQC for Engineers">Post-Quantum Cryptography for Engineers</title> <seriesInfoname="Internet-Draft" value="draft-ietf-pquip-pqc-engineers-14"/>name="RFC" value="9958"/> <author fullname="Aritra Banerjee"> <organization>Nokia</organization> <address> <postal> <city>London</city> <country>United Kingdom</country> </postal> <email>aritra.banerjee@nokia.com</email> </address> </author> <author fullname="TirumaleswarReddy">Reddy.K"> <organization>Nokia</organization> <address> <postal> <city>Bangalore</city> <region>Karnataka</region> <country>India</country> </postal> <email>k.tirumaleswar_reddy@nokia.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><region>PA</region> <country>United States of America</country> </postal> <email>tim.hollebeek@digicert.com</email> </address> </author> <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth"> <organization abbrev="Entrust">Entrust Limited</organization> <address> <postal> <street>2500 SolandtRoad –Road, Suite 100</street> <city>Ottawa, Ontario</city> <code>K2K 3G5</code> <country>Canada</country> </postal><email>mike.ounsworth@entrust.com</email><email>mike@ounsworth.ca</email> </address> </author> <dateyear="2025" month="August" day="26"/> <area>Security</area> <workgroup>PQUIP</workgroup>year="2026" month="May"/> <area>SEC</area> <workgroup>pquip</workgroup> <keyword>PQC</keyword> <abstract> <?line263?>638?> <!-- Status of I-Ds in references section: [I-D.bonnell-lamps-chameleon-certs] draft-bonnell-lamps-chameleon-certs-07 IESG State: I-D Exists as of 11/26/25 [I-D.connolly-cfrg-xwing-kem] draft-connolly-cfrg-xwing-kem-09 IESG State: I-D Exists as of 11/26/25 [I-D.hale-mls-combiner] draft-hale-mls-combiner-01 Replaced by draft-ietf-mls-combiner [I-D.ietf-hpke-pq] draft-ietf-hpke-pq-03 IESG State: I-D Exists as of 11/26/25 [I-D.ietf-lamps-pq-composite-sigs] draft-ietf-lamps-pq-composite-sigs-13 IESG state: Publication Requested as of 11/26/25 [I-D.ietf-pquip-hybrid-signature-spectrums] draft-ietf-pquip-hybrid-signature-spectrums-07 IESG state: RFC Ed Queue as of 11/26/25 [I-D.ietf-pquip-pqc-hsm-constrained] draft-ietf-pquip-pqc-hsm-constrained-02 IESG State: I-D Exists as of 11/26/25 [I-D.ietf-sshm-ntruprime-ssh] draft-ietf-sshm-ntruprime-ssh-06 Published as RFC 9941 [I-D.ietf-tls-hybrid-design] draft-ietf-tls-hybrid-design-16 IESG state: RFC Ed Queue as of 11/26/25 [I-D.irtf-cfrg-bbs-signatures] draft-irtf-cfrg-bbs-signatures-09 IESG State: I-D Exists as of 11/26/25 [I-D.irtf-cfrg-hybrid-kems] draft-irtf-cfrg-hybrid-kems-07 IESG State: I-D Exists as of 11/26/25 [I-D.ounsworth-cfrg-kem-combiners] draft-ounsworth-cfrg-kem-combiners-05 IESG State: Expired as of 11/26/25 --> <!-- [rfced] FYI - We will do the following when we convert the file to RFCXML: a) Correct author names in reference entry for draft-ietf-pquip-pqc-hsm-constrained. Current: [I-D.ietf-pquip-pqc-hsm-constrained] Reddy.K, T., Wing, D., S, B., and K. Kwiatkowski, "Adapting Constrained Devices for Post-Quantum Cryptography", Work in Progress, Internet-Draft, draft- ietf-pquip-pqc-hsm-constrained-02, 18 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-pquip- pqc-hsm-constrained-02>. b) Update the document to include <sup> elements (per A48 mail). c) Update draft-hale-mls-combiner-01 to draft-ietf-mls-combiner-02 since -01 was replaced (note title change). --> <!-- XML for reference update (draft-ietf-pquip-pqc-hsm-constrained): <reference anchor="I-D.ietf-pquip-pqc-hsm-constrained" target="https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-hsm-constrained-02"> <front> <title>Adapting Constrained Devices for Post-Quantum Cryptography</title> <author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy.K"> <organization>Nokia</organization> </author> <author initials="D." surname="Wing" fullname="Dan Wing"> <organization>Citrix</organization> </author> <author initials="B." surname="Salter" fullname="Ben Salter"> <organization>UK National Cyber Security Centre</organization> </author> <author initials="K." surname="Kwiatkowski" fullname="Kris Kwiatkowski"> <organization>PQShield</organization> </author> <date month="October" day="18" year="2025" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-hsm-constrained-02" /> </reference> - --> <t>The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC),detailingand it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms.</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-ietf-pquip-pqc-engineers/"/>. </t> <t> Discussion of this document takes place on the pquip Working Group mailing list (<eref target="mailto:pqc@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/pqc/"/>. </t> </note></front> <middle> <?line267?>738?> <section anchor="introduction"> <name>Introduction</name> <t>Quantum computing is no longer just a theoretical concept in computational science and physics; it is now an active area of research with practical implications. Considerable research efforts and enormous corporate and government funding for the development of practical quantum computing systems are currently being invested. At the time this document is published, cryptographically relevant quantum computers (CRQCs) that can break widely used asymmetric algorithms (also known as public key algorithms) are not yet available. However, there is ongoing research and development in the field of quantum computing, with the goal of building more powerful and scalable quantum computers.</t> <t>One common myth is that quantum computers are faster than conventional CPUs and GPUs in all areas. This is not the case; much as GPUs outperform general-purpose CPUs only on specific types of problems,so willquantumcomputers, too,computers also have a niche set of problems on which they excel. Unfortunately for cryptographers, integer factorization and discrete logarithms, the mathematical problems underpinning much of classical public key cryptography, happen to fall within the nichethatin which quantum computers are expected toexcel at.excel. As quantum technology advances, there is the potential for future quantum computers to have a significant impact on current cryptographic systems. Predicting the date of emergence of a CRQC is a challenging task, and there is ongoing uncertainty regarding when they will become practically feasible <xref target="CRQCThreat"/>.</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 and deployment.</t> <t>PQC is sometimes referred to as "quantum-proof", "quantum-safe", or "quantum-resistant". It is the development of cryptographic algorithms designed to secure communication and data in a world where quantum computers are powerful enough to break traditional cryptographic systems, such as RSA(Rivest–Shamir–Adleman)(Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography). PQC algorithms are intended to be resistant to attacks by quantum computers, which use quantum-mechanical phenomena to solve mathematical problems that are infeasible for classical computers.</t> <t>As the threat of CRQCs draws nearer, engineers responsible for designing, maintaining, and securing cryptographic systems must prepare for the significant changes that the existence of CRQCs will bring. Engineers need to understand how to implement post-quantum algorithms in applications, how to evaluate the trade-offs between security and performance, and how to ensure backward compatibility with current systems where needed. This is not merely a one-for-one replacement of algorithms; in many cases, the shift to PQC will involve redesigning protocols and infrastructure to accommodate the significant differences in resource utilization and key sizes between traditional and PQC algorithms. Due to the wide-ranging nature of these impacts, discussions of protocol changes are integrated throughout this document rather than being confined to a single section.</t> <t>This document aims to provide general guidance to engineers working on cryptographic libraries, network security, and infrastructure development, where long-term security planning is crucial. The document covers topics such as selecting appropriate PQCalgorithms,algorithms and understanding the differences between PQCkey encapsulation mechanismsKey Encapsulation Mechanisms (KEMs) and traditional Diffie-Hellman (DH) andRSA styleRSA-style key exchanges, and it provides insights into expectedkey,differences in keys, ciphertext,andsignaturesizessizes, and processingtime differencestimes between PQC and traditional algorithms. Additionally, it discusses the potential threat to symmetric cryptography and hash functions from CRQCs.</t> <t>It is important to remember that asymmetric algorithms (also known as public key algorithms) are largely used for secure communications between organizations or endpoints that may not have previously interacted, so a significant amount of coordination between organizations, and within and betweenecosystemsecosystems, needs to be taken into account. Such transitions are some of the most complicated in the tech industry and will require staged migrations in which upgraded agents need toco-existcoexist and communicate with non-upgraded agents at a scale never before undertaken.</t> <t>The National Security Agency (NSA) of the United States released an article on future PQC algorithm requirements for US national security systems <xref target="CNSA2-0"/> based on the need to protect against deployments of CRQCs in the future. The German Federal Office for Information Security (BSI) has also released a PQC migration and recommendations document <xref target="BSI-PQC"/>whichthat largely aligns with United States National Institute of Standards and Technology (NIST) and NSAguidance,guidance but differs in aspects such as specific PQC algorithm profiles.</t> <t>CRQCs pose a threat to both symmetric and asymmetric cryptographic schemes. However, the threat to asymmetric cryptography is significantly greater due to Shor's algorithm <xreftarget="Shors"/> algorithm,target="Shors"/>, which can breakwidely-usedwidely used public key schemes like RSA and ECC. Symmetric cryptography and hash functions face a lower risk from Grover's algorithm <xreftarget="Grovers"/> algorithm,target="Grovers"/>, although the impact is less severe and can typically be mitigated by doubling key and digest lengths where the risk applies. It is crucial for the reader to understand that whenthe word"PQC" is mentioned in the document, it means asymmetric cryptography (or public keycryptography),cryptography) and not any symmetric algorithms based on stream ciphers, block ciphers, hash functions,MACs,Message Authentication Codes (MACs), etc., which are less vulnerable to quantum computers. This document does not coversuchtopics such as when traditional algorithms might become vulnerable (for that, see documents such as <xref target="QC-DNS"/> and others).</t> <t>This document does not cover unrelated technologies like quantum key distribution (QKD) or quantum key generation, which use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively. PQC is based on conventional math (not on quantum mechanics) andsoftwaresoftware, and it can be run on anygeneral purposegeneral-purpose computer.</t> <t>This document does not go into the deep mathematics or technical specification of the PQCalgorithms,algorithms but rather provides an overview to engineers on the current threat landscape and the relevant algorithms designed to help prevent those threats. Also, the cryptographic and algorithmic guidance given in this document should be taken as non-authoritative if it conflicts with emerging and evolving guidance from the IRTF's Crypto Forum Research Group (CFRG).</t> </section> <section anchor="terminology"> <name>Terminology</name><t>Quantum computer: A<dl> <dt>Quantum computer:</dt> <dd> <t>A computer that performs computations using quantum-mechanical phenomena such as superposition and entanglement.</t><t>Physical qubit: The</dd> <dt>Physical qubit:</dt> <dd> <t>The basic physical unit in a quantum computer, which is prone to noise and errors.</t><t>Logical qubit: A</dd> <dt>Logical qubit:</dt> <dd> <t>A fault-tolerant qubit constructed from multiple physical qubits using quantum error correction; it is the effective unit for reliable quantum computation.</t><t>Post-Quantum</dd> <dt>Post-Quantum Cryptography(PQC): Cryptographic(PQC):</dt> <dd> <t>Cryptographic algorithms designed to be secure against quantum and classical attacks.</t><t>Cryptographically</dd> <dt>Cryptographically Relevant Quantum Computer(CRQC): A(CRQC):</dt> <dd> <t>A quantum computer with sufficient logical qubits to break traditional asymmetric cryptographic algorithms (e.g., RSA or ECC) within a practical timeframe.</t><t>Public</dd> <dt>Public Key Cryptography (also called AsymmetricCryptography): ACryptography):</dt> <dd> <t>A class of cryptographic algorithms in which separate keys are used for encryption anddecryption,decryption or for signing and verification. Throughout this document, the terms Public Key Cryptography and Asymmetric Cryptography are used interchangeably.</t> </dd> </dl> <t>There is ongoing discussion about whether to use the term "post-quantum", "quantum ready", "quantum resistant", or "quantumsecure",secure" to describe algorithms that resist CRQCs, and a consensus has not yet been reached. NIST has coined the term "post-quantum" to refer to the algorithms that participated in its competition-like selection process; in this context, the term can be interpreted to mean "the set of algorithms that are designed to still be relevant after quantum computersexist",exist" and not a statement about their security. "Quantum resistant" or "quantum secure" is obviously the goal of thesealgorithms, howeveralgorithms; however, some people have raised concerns thatlabellinglabeling a class of algorithms as "quantum resistant" or "quantum secure" could lead to confusion if one or more of those algorithms are later found to be insecure or to not resist quantum computers as much as theory predicted. "Quantum ready" is often used to refer to a solution -- device, appliance, or software stack -- that has reached maturity withregardsregard to integration of these new cryptographic algorithms. That said, the authors recognize that there is great variability in how these terms are used. This document usesany ofthese terms interchangeably to refer to such algorithms.</t><t>The terms "current," "state-of-the-art," and "ongoing," as used in<t>In this document, the terms "current", "state-of-the-art", and "ongoing" refer to work, research, investigations, deployments, or developments that are applicable at the time of publication.</t> </section> <section anchor="threat-of-crqcs-on-cryptography"> <name>Threat of CRQCs on Cryptography</name> <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. Dr. Peter Shor and Dr. Lov Grover developed two algorithms that changed the way the world thinks of security under the presence of a CRQC.</t> <t>Quantum computers are, by their nature, hybrids of classical and quantum computational units. For example, Shor's algorithm consists of a combination of quantum and classical computational steps. Thus, the term "quantum adversary" should be thought of as "quantum-enhanced adversary", meaning they have access to both classical and quantum computational techniques.</t><t>Despite that<t>Although large-scale quantum computers do not yet exist to experiment on, the theoretical properties of quantum computation are very well understood. This allows engineers and researchers to reason about the upper limits of quantum-enhancedcomputation,computation andindeedto design cryptographic algorithms that are resistant to any conceivable form of quantum cryptanalysis.</t> <section anchor="symmetric"> <name>Symmetric Cryptography</name> <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 quantum algorithm is known to break the underlying security properties of these classes of algorithms. Symmetric-key cryptography, which includes keyed primitives such as block ciphers (e.g., AES) and message authentication mechanisms (e.g., HMAC-SHA256), relies on secret keys shared between the sender and receiver and remains secure even in a post-quantum world. Symmetric cryptography also includes hash functions (e.g., SHA-256) that are used for secure message digesting without any shared key material.HMACHashed Message Authentication Code (HMAC) is a specific construction that utilizes a cryptographic hash function and a secret key shared between the sender and receiver to produce a message authentication code.</t> <t>Grover's algorithm is a quantum search algorithm that provides a theoretical quadratic speedup for searching an unstructured database, compared to traditional search algorithms. This has led to the common misconception that symmetric key lengths need to be doubled for quantum security. When you consider the mapping of hash values to their corresponding hash inputs (also known aspre-image),pre-image) or of ciphertext blocks to the corresponding plaintextblocks,blocks as an unstructured database, thenGrover’sGrover's algorithm theoretically requires doubling the key sizes of the symmetric algorithms that are currently deployed at the time of publication to counter the quadratic speedup and maintain the current security level. This is becauseGrover’sGrover's algorithm reduces the amount of operations to break 128-bit symmetric cryptography to 2^{64} quantum operations, which might sound computationally feasible. However, quantum operations are fundamentally different from classicalonesones, as 2^{64} classical operations can be efficientlyparallelized,parallelized but 2^{64} quantum operations must be performed serially, making them infeasible on practical quantum computers.</t> <t>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 to2^{(128−c)/2},2^{(128-c)/2}, or, put simply, using 256 quantum computers will only reduce runtime by a factor of 16, 1024 quantum computers will only reduce runtime by a factor of3232, and so forth (see <xref target="NIST"/> and <xref target="Cloudflare"/>). Due to this inherent limitation, the general expert consensus is that AES-128(Advanced Encryption Standard)remains secure inpractice,practice and key sizes do not necessarily need to be doubled.</t> <t>It would be natural to ask whether future research will develop a superior algorithm that could outperform Grover's algorithm in the general case. However, Christof Zalka has shown that Grover's algorithm achieves the best possible complexity for this type of search, meaning no significantly faster quantum approach is expected <xreftarget="Grover-search"/></t>target="Grover-Search"/>.</t> <t>Finally, in their evaluation criteria for PQC, NIST is assessing the security levels of proposed post-quantum algorithms by comparing them against the equivalent traditional and quantum security of AES-128, AES-192, and AES-256. This indicates that NIST is confident in the stable security properties of AES, even in the presence of both traditional and quantum attacks. As a result, 128-bit algorithms can be considered quantum-safe for the foreseeable future. However, for compliance purposes, some organizations, such as the French National Agency for the Security of Information Systems (ANSSI) <xref target="ANSSI"/> andCNSA 2.0 (Commercialthe National SecurityAlgorithm SuiteAgency (NSA) (CNSA 2.0) <xref target="CNSA2-0"/>, recommend the use of AES-256.</t> </section> <section anchor="asymmetric-cryptography"> <name>Asymmetric Cryptography</name><t>“Shor’s algorithm”<t>"Shor's algorithm" efficiently solves the integer factorization problem (and the related discrete logarithm problem), which underpin the foundations of the vast majority of public key cryptography that the world uses today. This implies that, if a CRQC is developed,today’stoday's public key algorithms (e.g., RSA,Diffie-HellmanDiffie-Hellman, andelliptic curve cryptography,ECC, as well as lesscommonly-usedcommonly used variants such as ElGamal <xref target="RFC6090"/> and Schnorr signatures <xref target="RFC8235"/>) and protocols would need to be replaced by algorithms and protocols that can offer cryptanalytic resistance against CRQCs. Note thatShor’sShor's algorithm cannot run solely on a classicalcomputer,computer; it requires a CRQC.</t> <t>For example, studies show that, if a CRQC existed, it could break RSA-2048 in hours or even seconds depending on assumptions about error correction <xreftarget="RSAShor"/><xref target="RSA8HRS"/><xreftarget="RSAShor"/> <xref target="RSA8HRS"/> <xref target="RSA10SC"/>. While such machines are purely theoretical at the time of writing, this illustrates the eventual vulnerability of RSA to CRQCs.</t> <t>For structured data such as public keys and signatures, CRQCs can fully solve the underlying hard problems used in traditional cryptography (see Shor's algorithm). Because an increase in the size of thekey-pairkey pair would not provide a secure solution (short of RSA keys that are many gigabytes in size <xref target="PQRSA"/>), 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 traditional 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 anchor="quantum-side-channel-attacks"> <name>QuantumSide-channelSide-Channel Attacks</name> <t>Cryptographic side-channel attacks exploit physicalimplementations, suchimplementations (such as timing, power consumption, or electromagneticleakageleakage) to recover secret keys.</t> <t>The field of cryptographic side-channel attacks potentially stands to gain a boost in attacker power once cryptanalytic techniques can be enhanced with quantum computation techniques <xref target="QuantSide"/>. While a full discussion of quantum side-channel techniques is beyond the scope of this document, implementers of cryptographic hardware should be aware that currentbest-practicesbest practices for side-channel resistance may not be sufficient against quantum adversaries.</t> </section> </section> <section anchor="traditional-cryptographic-primitives-that-could-be-replaced-by-pqc"> <name>Traditional Cryptographic PrimitivesthatThat Could Be Replaced by PQC</name> <t>Any asymmetric cryptographic algorithm based on integer factorization, finite field discrete logarithms, orelliptic curveelliptic-curve discrete logarithms will be vulnerable to attacks using Shor's algorithm on a CRQC. This document focuses on the principal functions of asymmetric cryptography:</t><ul spacing="normal"> <li> <t>Key<dl> <dt>Key agreement and keytransport: Keytransport:</dt> <dd> <t>Key agreement schemes, typically referred to as Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH), as well as key transport, typically using RSA encryption, are used to establish a shared cryptographic key for secure communication. They are one of the mechanisms that can be replaced by PQC, as they are based on existing public key cryptography and are therefore vulnerable to Shor's algorithm. A CRQC can employ Shor's algorithm to efficiently find the prime factors of a large public key (in the case of RSA),whichwhich, inturnturn, can be exploited to derive the private key. In the case ofDiffie-Hellman,DH, a CRQC has the potential to calculate the discrete logarithm of the(short(short- or long-term)Diffie-HellmanDH public key. This, in turn, would reveal the secret required to derive the symmetric encryption key.</t></li> <li></dd> <dt>Digital signatures:</dt> <dd> <t>Digitalsignatures: Digitalsignature schemes are used to authenticate the identity of a sender, detect unauthorized modifications to data, and underpin trust in a system. Similar to key agreement, signatures also depend on a public-private key pair based on the same mathematics as for key agreement and keytransport, and hencetransport. Because of this, a break in existing public key cryptography will also affect traditional digital signatures, hence the importance of developing post-quantum digital signatures.</t></li> <li></dd> <dt>Boneh-Boyen-Shacham (BBS) signatures:</dt> <dd> <t>BBSsignatures: BBS (Boneh-Boyen-Shacham)signatures are a privacy-preserving signature scheme that offers zero-knowledge proof-like properties by allowing selective disclosure of specific signed attributes without revealing the entire set of signed data. The security of BBS signatures relies on the hardness of the discrete logarithm problem, making them vulnerable to Shor's algorithm. A CRQC can break the data authenticity security property of BBS but not the data confidentiality(Section 6.9 of <xref(<xref section="6.9" sectionFormat="of" target="I-D.irtf-cfrg-bbs-signatures"/>).</t></li> <li></dd> <dt>Content encryption:</dt> <dd> <t>Contentencryption: Contentencryption typically refers to the encryption of the data using symmetric key algorithms, such as AES, to ensure confidentiality. The threat to symmetric cryptography is discussed in <xref target="symmetric"/>.</t></li> </ul></dd> </dl> </section> <section anchor="nist-pqc-algorithms"> <name>NIST PQC Algorithms</name> <t>At the time of writing, NISThavehas standardized three PQC algorithms, with more expected to bestandardisedstandardized in the future(<xref(see <xref target="NISTFINAL"/>). These algorithms are not necessarily drop-in replacements for traditional asymmetric cryptographic algorithms. For instance, RSA <xref target="RSA"/> and ECC <xref target="RFC6090"/> can be used as both akey encapsulation method (KEM)KEM andasa signature scheme, whereas there is currently no post-quantum algorithm that can perform both functions. When upgrading protocols, it is important to replace the existing use of traditional algorithms with either a PQC KEM or a PQC signature method, depending on how the traditional algorithm was previously being used. Additionally, KEMs, as described in <xref target="KEMs"/>, present a different API than either key agreement or key transport primitives. As a result, they may require protocol-level or application-level changes in order to be incorporated.</t> <section anchor="nist-candidates-selected-for-standardization"> <name>NIST Candidates Selected for Standardization</name><section anchor="pqc-key-encapsulation-mechanisms-kems"> <name>PQC Key Encapsulation Mechanisms (KEMs)</name> <ul spacing="normal"> <li> <t><xref target="ML-KEM"/>:<!-- [rfced] In Sections 5.1.1, 5.1.2, and 6.1, may we update the lists to better indicate the term being defined? We suggest placing the term rather than the citation before the colon. See the suggested text in a), b), and c) below. We also have some additional questions regarding Section 5.1.2: - How should "FN" in "FN-DSA" be expanded? Perhaps as "Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm"? - The FN-DSA entry includes pointers to Sections 8.1 and 10.2, but ML-DSA and SLH-DSA are also mentioned in those setions. Should the pointers to Sections 8.1 and 10.2 apply to all entries? - We do not see "FN-DSA" mentioned in the URL listed for [FN-DSA]. Please review. Also, should this reference be to FIPS 206, or should the relationship between FIPS 206 and Fast Fourier/Falcon be explained for the reader? It seems that FIPS 206 is still in draft form. a) Section 5.1.1 Original * [ML-KEM]: Module-Lattice-based Key-Encapsulation Mechanism Standard(FIPS-203).</t> </li> <li> <t><xref target="HQC"/>:(FIPS-203). * [HQC]: Hamming Quasi-Cyclic coding algorithm which is based on the hardness of the syndrome decoding problem for quasi-cyclic concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the Hamming metric. Reed-Muller (RM) codes are a class of block error-correcting codes commonly used in wireless and deep-space communications, while Reed-Solomon (RS) codes are widely used to detect and correct multiple-bit errors. HQC has been selected as part of the NIST post-quantum cryptography project but has not yet beenstandardized.</t> </li> </ul> </section> <section anchor="pqc-signatures"> <name>PQC Signatures</name> <ul spacing="normal"> <li> <t><xref target="ML-DSA"/>:standardized. Perhaps: ML-KEM: Module-Lattice-Based Key Encapsulation Mechanism. See FIPS 203 [ML-DSA]. HQC: Hamming Quasi-Cyclic. See [HQC]. The coding algorithm based on the hardness of the syndrome decoding problem for quasi-cyclic concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the Hamming metric. Reed-Muller (RM) codes are a class of block error-correcting codes commonly used in wireless and deep-space communications, while Reed-Solomon (RS) codes are widely used to detect and correct multiple-bit errors. HQC has been selected as part of the NIST post-quantum cryptography project but has not yet been standardized. b) Section 5.1.2 Original: * [ML-DSA]: Module-Lattice-Based Digital Signature Standard(FIPS-204).</t> </li> <li> <t><xref target="SLH-DSA"/>:(FIPS- 204). * [SLH-DSA]: Stateless Hash-Based Digital Signature(FIPS-205).</t> </li> <li> <t><xref target="FN-DSA"/>:(FIPS-205). * [FN-DSA]: FN-DSA is a lattice signature scheme (FIPS-206)(<xref target="lattice-based"/>(Section 8.1 and Section 10.2). Perhaps: ML-DSA: Module-Lattice-Based Digital Signature Algorithm. See FIPS 204 [ML-DSA]. SLH-DSA: Stateless Hash-Based Digital Signature Algorithm. See FIPS 205 [SLH-DSA]. FN-DSA: Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm. See FIPS 206 [FN-DSA]. For more information about these, see Sections 8.1 and 10.2. c) Section 6.1 Original: * [FrodoKEM]: Key Encapsulation mechanism based on the hardness of learning with errors in algebraically unstructured lattices. * [ClassicMcEliece]: Based on the hardness of syndrome decoding of Goppa codes. Goppa codes are a class of error-correcting codes that can correct a certain number of errors in a transmitted message. The decoding problem involves recovering the original message from the received noisy codeword. * [NTRU]: Key encapsulation mechanism based on the "N-th degree Truncated polynomial Ring Units" (NTRU) lattices. Variants include Streamlined NTRU Prime (sntrup761), which is leveraged for use in SSH [I-D.ietf-sshm-ntruprime-ssh]. Perhaps: FrodoKEM: KEM based on the hardness of learning with errors in algebraically unstructured lattices. See [FrodoKEM]. Classic McEliece: KEM based on the hardness of syndrome decoding of Goppa codes. Goppa codes are a class of error-correcting codes that can correct a certain number of errors in a transmitted message. The decoding problem involves recovering the original message from the received noisy codeword. See [ClassicMcEliece]. NTRU: KEM based on the "N-th degree Truncated polynomial Ring Units" (NTRU) lattices. Variants include Streamlined NTRU Prime (sntrup761), which is leveraged for use in SSH [RFC9941]. See [NTRU]. --> <section anchor="pqc-key-encapsulation-mechanisms-kems"> <name>PQC Key Encapsulation Mechanisms (KEMs)</name> <dl> <dt>ML-KEM:</dt> <dd> <t>Module-Lattice-Based Key-Encapsulation Mechanism. See FIPS 203 <xref target="ML-KEM"/>.</t> </dd> <dt>HQC:</dt> <dd> <t>Hamming Quasi-Cyclic. See <xref target="HQC"/>. The coding algorithm based on the hardness of the syndrome decoding problem for quasi-cyclic concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the Hamming metric. Reed-Muller (RM) codes are a class of block error-correcting codes commonly used in wireless and deep-space communications, while Reed-Solomon (RS) codes are widely used to detect and correct multiple-bit errors. HQC has been selected as part of the NIST post-quantum cryptography project but has not yet been standardized.</t> </dd> </dl> </section> <section anchor="pqc-signatures"> <name>PQC Signatures</name> <dl> <dt>ML-DSA:</dt> <dd> <t>Module-Lattice-Based Digital Signature Algorithm. See FIPS 204 <xreftarget="sig-scheme"/>).</t> </li> </ul>target="ML-DSA"/>.</t> </dd> <dt>SLH-DSA:</dt> <dd> <t>Stateless Hash-Based Digital Signature Algorithm. See FIPS 205 <xref target="SLH-DSA"/>.</t> </dd> <dt>FN-DSA:</dt> <dd> <t>Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm. See <xref target="FN-DSA"/>; note that NIST has named this algorithm "FN-DSA" and assigned "FIPS 206" for its specification, but at the time of this document's publication, it has not yet been released.</t> </dd> </dl> <t>For more information about these, see Sections <xref target="lattice-based" format="counter"/>, <xref target="hash-based" format="counter"/>, and <xref target="sig-scheme" format="counter"/>.</t> </section> </section> </section> <section anchor="iso-candidates-selected-for-standardization"> <name>ISO Candidates Selected for Standardization</name> <t>At the time of writing, ISO has selected three PQC KEM algorithms as candidates forstandardization, whichstandardization; these are mentioned in the following subsection.</t> <section anchor="pqc-key-encapsulation-mechanisms-kems-1"> <name>PQC Key Encapsulation Mechanisms (KEMs)</name><ul spacing="normal"> <li> <t><xref target="FrodoKEM"/>: Key Encapsulation mechanism<dl> <dt>FrodoKEM:</dt> <dd> <t>KEM based on the hardness of learning with errors in algebraically unstructuredlattices.</t> </li> <li> <t><xref target="ClassicMcEliece"/>: Basedlattices. See <xref target="FrodoKEM"/>.</t> </dd> <dt>ClassicMcEliece:</dt> <dd> <t>KEM based on the hardness of syndrome decoding of Goppa codes. Goppa codes are a class of error-correcting codes that can correct a certain number of errors in a transmitted message. The decoding problem involves recovering the original message from the received noisycodeword.</t> </li> <li> <t><xref target="NTRU"/>: Key encapsulation mechanismcodeword. See <xref target="ClassicMcEliece"/>.</t> </dd> <dt>NTRU:</dt> <dd> <t>KEM based on the "N-th degree Truncated polynomial Ring Units" (NTRU) lattices. Variants include Streamlined NTRU Prime (sntrup761), which is leveraged for use in SSH <xreftarget="I-D.ietf-sshm-ntruprime-ssh"/>.</t> </li> </ul>target="RFC9941"/>. See <xref target="NTRU"/>.</t> </dd> </dl> </section> </section> <section anchor="timeline"> <name>Timeline for Transition</name> <t>Thetimeline,timeline and driving motivation for transitiondiffersdiffer slightly between data confidentiality (e.g., encryption) and data authentication (e.g., signature)use-cases.</t>use cases.</t> <t>For data confidentiality, one is concerned with the so-called "harvest now, decrypt later" (HNDL) attack where a malicious actor with adequate resources can launch an attack to store sensitive encrypted data today that they hope to decrypt 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 possibly being deciphered in the future.</t> <t>For authentication, it is often the case that signatures have a very short lifetime between signing and verifying (such as during a TLShandshake)handshake), but some authenticationuse-casesuse cases do require long lifetimes, such as signing firmware or software that will be active for decades, signing legal documents, or signing certificates that will be embedded into hardware devices such assmartcards.smart cards. Even for short-livedsignaturessignature use cases, the infrastructure often relies on long-lived rootkeyskeys, which can be difficult to update or replace on in-field devices.</t> <figure anchor="Mosca"> <name>Moscamodel</name>Model</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="160" width="448" viewBox="0 0 448 160" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,128" fill="none" stroke="black"/> <path d="M 208,32 L 208,80" fill="none" stroke="black"/> <path d="M 296,80 L 296,128" fill="none" stroke="black"/> <path d="M 440,32 L 440,80" fill="none" stroke="black"/> <path d="M 8,32 L 440,32" fill="none" stroke="black"/> <path d="M 8,80 L 440,80" fill="none" stroke="black"/> <path d="M 312,96 L 440,96" fill="none" stroke="black"/> <path d="M 8,128 L 296,128" fill="none" stroke="black"/> <polygon class="arrowhead" points="448,96 436,90.4 436,101.6" fill="black" transform="rotate(0,440,96)"/> <polygon class="arrowhead" points="320,96 308,90.4 308,101.6" fill="black" transform="rotate(180,312,96)"/> <g class="text"> <text x="104" y="68">y</text> <text x="320" y="68">x</text> <text x="136" y="116">z</text> <text x="356" y="116">Security</text> <text x="408" y="116">gap</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +------------------------+----------------------------+ | | | | y | x | +------------------------+----------+-----------------+ | | <---------------> | z | Security gap +-----------------------------------+ ]]></artwork> </artset> </figure> <t>These challenges are illustrated nicely by the so-called Mosca model discussed in <xref target="Threat-Report"/>. In <xref target="Mosca"/>, "x" denotes the time that systems and data need to remain secure, "y" the number of years to fully migrate to a PQC infrastructure, and "z" the time until a CRQC that can break current cryptography is available. The model assumes either that encrypted data can be intercepted and stored before the migration is completed in "y" years, or that signatures will still be relied upon for "x" years after their creation. This data remains vulnerable for the complete "x" years of theirlifetime, thuslifetime; thus, the sum "x+y" gives us an estimate of the full timeframe that dataremainremains insecure. The model essentially asks how one is preparing IT systems during those "y" years (in other words, how one can 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 beunder-estimated, likeunderestimated, forexampleexample, faster-than-expected advances in quantum computing and more efficient versions ofShor’sShor's algorithm requiring fewer qubits. Innovation often comes in waves, so it is to theindustry’sindustry's benefit to remain vigilant and prepare as early as possible.BearAlso, bear in mindalsothat while the industry tracks advances from public research institutions such as universities and companies that publish their results, there is also a great deal of large-budget quantum research being conducted privately by various national interests. Therefore, the true state of quantum computer advancement is likely several years ahead of the publicly available research at the date this document is published.</t> <t>Organizations should alsoconsidercarefully and honestly consider what their migration timeline "y" actually is. If youthinkonly think of the time between receiving a patch from your technologyvendor,vendor and rolling that patch out, then "y" might seem as short as a few weeks. However, this represents the minority of migration cases; more often, a PQC migration will involve at least some amount of hardware replacement. For example, performance-sensitive applications will need CPUs with PQC hardware acceleration. Security-sensitive applications will need PQC TPMs,TEEs, Secure Enclaves,Trusted Execution Environments (TEEs), secure enclaves, and other cryptographic co-processors.SmartcardSmart card applications will require replacement of the cardsas well as of theand readers. The readerswhichcan come in manyform-factors:form factors: tap-for-entry door and turnstile readers, PIN pad machines, laptops with built-insmartcardsmart card readers, and many others.</t> <t>Included in "y" is not only the deploymenttime,time but also the preparation time: integration, testing, auditing, andre-certificationrecertification of cryptographic environments.Consider alsoAlso consider upstream effects that contribute to "y", includinglead-timeslead times foryourvendors to produce PQC-ready products, which may itself include auditing and certification delays, time for regulating bodies to adopt PQC policies, time for auditors to become familiar with the new requirements, etc. If you measure the full migration time "y" from when your vendors begin implementing PQCfunctionality,functionality to when you switch off your last non-PQC-capable device, then "y" can be quitelong;long, likely measured in years for even mostmoderately-sized organizations, thismoderately sized organizations. This long tail should not discourage early action.</t> <t>Organizations responsible for protecting long-lived sensitive data or operating critical infrastructure will need to begin transitioning immediately, particularly in scenarios where data is vulnerable to HNDL attacks.PQ/TPost-quantum and traditional (PQ/T) <xref target="PQT"/> or PQ key exchange is relatively self-contained, typically requiring changes only to the cryptographic library (e.g., OpenSSL). In contrast, migrating to post-quantum or PQ/T digital signatures involves broader ecosystem changes, including updates to certificates,CAs,certificate authorities (CAs), Certificate Management Protocols, HSMs, and trust anchors. Starting early with hybrid key exchange deployments allows organizations to gain operational experience, while prototyping and planning for PQ/T or PQ digital signature integration helps identify ecosystem-wide impacts early. This phased approach reduces long-term migration risks and ensures readiness for more complex updates.</t> </section> <section anchor="pqc-categories"> <name>PQC Categories</name> <t>The post-quantum cryptographic schemes standardized by NIST can be categorized into three main groups: lattice-based, hash-based, and code-based. Other approaches, such as isogeny-based, multivariate-based, and MPC-in-the-Head-based cryptography, are also being explored in research and standardization efforts. In addition, NIST issued a call for additional digital signature proposals to expand the set of post-quantum signatures under evaluation <xref target="AddSig"/>.</t> <section anchor="lattice-based"> <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 evenly spaced) to create "trapdoor" problems. These problems are efficient to compute if you possess the secret information but challenging to compute otherwise. Examples of such problems include the shortest vector, closest vector, short integer solution, learning with errors, module learning with errors, and learning with rounding problems. All of these problems feature strong proofs for worst-to-average case reduction, effectively relating the hardness of the average case to the worst case.</t> <t>Lattice-based public keys and signatures are larger than those of classical schemes such as RSA or ECC, but typically by less than an order of magnitude for public keys (about6–10×)6-10x) and by roughly one to two orders of magnitude for signatures (about10–100×),10-100x) rather than by several orders of magnitude, making them the best available candidates for general-purposeuseuse, such as replacing the use of RSA in PKIX certificates.</t> <t>Examples of this class of algorithms include ML-KEM, FN-DSA,ML-DSAML-DSA, and FrodoKEM.</t> <t>It is noteworthy that lattice-based encryption schemes require a rounding step duringdecryptiondecryption, which has a non-zero probability of "rounding the wrong way" and leading to a decryption failure, meaning that valid encryptions are decrypted incorrectly. However, the parameters of NIST PQC candidates are carefully chosen so that the probability of such a failure is cryptographically negligible, far lower than the probability of random transmission errors and implementation bugs. In practical terms, these rare decryption failures can be treated the same way as any fatal transport error:bothBoth sides simply perform a fresh KEM operation, generating a new ciphertext and shared secret.</t> <t>In cryptanalysis, an oracle refers to a system that an attacker can query to learn whether decryption succeeded or failed. If such an oracle exists, an attacker could significantly reduce the security of lattice-based schemes that have a relatively high failure rate. However, for most of the NIST PQC proposals, the number of required oracle queries to force a decryption failure is above practical limits, ashas beenshown in <xref target="LattFail1"/>. More recent works have improved upon the results in <xref target="LattFail1"/>, showing that the cost of searching for additional failing ciphertexts after one or more have already beenfound,found can be sped up dramatically <xref target="LattFail2"/>. Nevertheless, at the time this document is published, the PQC candidates by NIST are considered secure under theseattacksattacks, and constant monitoring as cryptanalysis research is ongoing.</t> </section> <section anchor="hash-based"> <name>Hash-Based Public Key Cryptography</name><t>Hash based PKC<t>Hash-based Public Key Cryptography (PKC) has been around since the 1970s, when it was developed by Lamport and Merkle. It is used to create digital signaturealgorithmsalgorithms, and its security is based on the security of the underlying cryptographic hash function. Many variants of hash-based signatures(HBS)(HBSs) have been developed since the70s1970s, including the recent XMSS <xref target="RFC8391"/>, HSS/LMS <xreftarget="RFC8554"/>target="RFC8554"/>, or BPQS <xref target="BPQS"/> schemes. Unlike many other digital signature techniques, most hash-based signature schemes are stateful, which means that signing necessitates the update and careful tracking of the state of the secret key. Producing multiple signatures using the same secret key state results in loss of security and may ultimately enable signature forgery attacks against that key.</t> <t>Stateful hash-based signatures with long service lifetimes require additional operational complexity comparedwithto other signature types. For example, consider a 20-year root key; there is an expectation that 20 years is longer than the expected lifetime of the hardware that key is stored on,and thereforeso the key will need to be migrated to new hardware at some point. Disaster-recovery scenarios where the primary node fails without warning can be similarly tricky. This requires careful operational and compliance consideration to ensure that no private key state can be reused across the migration or disaster recovery event. One approach for avoiding these issues is to only use statefulHBSHBSs for short-term use cases that do not require horizontal scaling, forexampleexample, signing a batch of firmware images and then retiring the signing key.</t> <t>The SLH-DSA algorithm, which was standardized by NIST, leverages the HORST(hash(Hash toobtain random subsetObtain Random Subset withtrees)Trees) technique and remains the only standardized hash based signature scheme that is stateless, thus avoiding the complexities associated with state management. SLH-DSA is an advancement on SPHINCSwhichthat reduces the signature sizes in SPHINCS and makes it more compact.</t> </section> <section anchor="code-based"> <name>Code-Based Public Key Cryptography</name> <t>This area of cryptography started in the 1970s and80s1980s and was based on the seminal work of McEliece andNiederreiterNiederreiter, which focuses on the study of cryptosystems based on error-correcting codes. Some popularerror correctingerror-correcting codes include Goppa codes (used in McEliece cryptosystems), encoding and decoding syndrome codes used inHamming quasi-cyclic (HQC),HQC, or quasi-cyclic moderate density parity check (QC-MDPC) codes.</t> <t>Examples include all the unbroken NIST Round 4 finalists: Classic McEliece, HQC (selected by NIST for standardization), and Bit Flipping Key Encapsulation (BIKE) <xref target="BIKE"/>.</t> </section> </section> <section anchor="KEMs"> <name>KEMs</name> <t>A Key Encapsulation Mechanism (KEM) is a cryptographic technique used for securely exchanging symmetric key material between two parties over an insecure channel. It is commonly used in hybrid encryptionschemes,schemes where a combination of asymmetric (public key) and symmetric encryption is employed. TheKEMencapsulation operation of a KEM results in a fixed-length symmetric key that can be used with a symmetric algorithm, typically a block cipher, in one of two different ways:</t> <ul spacing="normal"> <li><t>Derive<t>To derive a data encryption key (DEK) to encrypt the data</t> </li> <li><t>Derive<t>To derive a key encryption key (KEK) used to wrap a DEK</t> </li> </ul> <t>These techniques are often referred to as"hybrid public key encryption (HPKE)"the Hybrid Public Key Encryption (HPKE) <xref target="RFC9180"/> mechanism.</t> <t>The term "encapsulation" is chosen intentionally to indicate that KEM algorithms behave differently at the API level from the key agreement or key encipherment/and key transport mechanisms that are in use today. Key agreement schemes imply that both parties contribute apublic / privatepublic-private key pair to the exchange, while key encipherment/and key transport schemes imply that the symmetric key material is chosen by one party and "encrypted" or "wrapped" for the other party. KEMs, on the other hand, behave according to the following API primitives <xref target="PQCAPI"/>:</t> <ul spacing="normal"> <li> <t>def kemKeyGen() -> (pk, sk)</t> </li> <li> <t>def kemEncaps(pk) -> (ss, ct)</t> </li> <li> <t>def kemDecaps(ct, sk) -> ss</t> </li> </ul> <t>where <tt>pk</tt> is the public key, <tt>sk</tt> is the secret key, <tt>ct</tt> is the ciphertext representing an encapsulated key, and <tt>ss</tt> is the shared secret. The following figure illustrates a sample flow of a KEM-based key exchange:</t> <figure anchor="tab-kem-ke"><name>KEM based key exchange</name><name>KEM-Based Key Exchange</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="336" width="536" viewBox="0 0 536 336" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,272 L 8,304" fill="none" stroke="black"/> <path d="M 24,80 L 24,112" fill="none" stroke="black"/> <path d="M 184,32 L 184,64" fill="none" stroke="black"/> <path d="M 208,80 L 208,112" fill="none" stroke="black"/> <path d="M 208,272 L 208,304" fill="none" stroke="black"/> <path d="M 224,72 L 224,320" fill="none" stroke="black"/> <path d="M 264,32 L 264,64" fill="none" stroke="black"/> <path d="M 280,32 L 280,64" fill="none" stroke="black"/> <path d="M 320,72 L 320,320" fill="none" stroke="black"/> <path d="M 336,176 L 336,208" fill="none" stroke="black"/> <path d="M 360,32 L 360,64" fill="none" stroke="black"/> <path d="M 528,176 L 528,208" fill="none" stroke="black"/> <path d="M 184,32 L 264,32" fill="none" stroke="black"/> <path d="M 280,32 L 360,32" fill="none" stroke="black"/> <path d="M 184,64 L 264,64" fill="none" stroke="black"/> <path d="M 280,64 L 360,64" fill="none" stroke="black"/> <path d="M 24,80 L 208,80" fill="none" stroke="black"/> <path d="M 24,112 L 208,112" fill="none" stroke="black"/> <path d="M 232,160 L 312,160" fill="none" stroke="black"/> <path d="M 336,176 L 528,176" fill="none" stroke="black"/> <path d="M 336,208 L 528,208" fill="none" stroke="black"/> <path d="M 232,256 L 312,256" fill="none" stroke="black"/> <path d="M 8,272 L 208,272" fill="none" stroke="black"/> <path d="M 8,304 L 208,304" fill="none" stroke="black"/> <polygon class="arrowhead" points="320,160 308,154.4 308,165.6" fill="black" transform="rotate(0,312,160)"/> <polygon class="arrowhead" points="240,256 228,250.4 228,261.6" fill="black" transform="rotate(180,232,256)"/> <g class="text"> <text x="220" y="52">Client</text> <text x="316" y="52">Server</text> <text x="48" y="100">pk,</text> <text x="76" y="100">sk</text> <text x="96" y="100">=</text> <text x="152" y="100">kemKeyGen()</text> <text x="216" y="100">-</text> <text x="244" y="148">pk</text> <text x="328" y="196">-</text> <text x="360" y="196">ss,</text> <text x="388" y="196">ct</text> <text x="408" y="196">=</text> <text x="472" y="196">kemEncaps(pk)</text> <text x="292" y="244">ct</text> <text x="28" y="292">ss</text> <text x="48" y="292">=</text> <text x="112" y="292">kemDecaps(ct,</text> <text x="184" y="292">sk)</text> <text x="216" y="292">-</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +---------+ +---------+ | Client | | Server | +---------+ +---------+ +----------------------+ | | | pk, sk = kemKeyGen() |-| | +----------------------+ | | | | | pk | |---------->| | | +-----------------------+ | |-| ss, ct = kemEncaps(pk)| | | +-----------------------+ | | | ct | |<----------| +------------------------+ | | | ss = kemDecaps(ct, sk) |-| | +------------------------+ | | | | ]]></artwork> </artset> </figure> <section anchor="authenticated-key-exchange"> <name>Authenticated Key Exchange</name> <t>Authenticated Key Exchange (AKE) with KEMs where both parties contribute a KEM public key to the overall session key is interactive as described inSection 9.4 of<xref section="9.4" sectionFormat="of" target="RFC9528"/>. However, a single-sided KEM, such as when one peer has a KEM key in a certificate and the other peer wants to encrypt for it (as in S/MIME or OpenPGP email), can be achieved using non-interactive HPKE <xref target="RFC9180"/>. The following figure illustrates theDiffie-Hellman (DH)DH Key exchange:</t> <figure anchor="tab-dh-ake"><name>Diffie-Hellman based<name>DH-Based AKE</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="480" width="552" viewBox="0 0 552 480" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,320 L 8,368" fill="none" stroke="black"/> <path d="M 24,80 L 24,128" fill="none" stroke="black"/> <path d="M 136,336 L 136,344" fill="none" stroke="black"/> <path d="M 184,32 L 184,64" fill="none" stroke="black"/> <path d="M 216,80 L 216,128" fill="none" stroke="black"/> <path d="M 216,320 L 216,368" fill="none" stroke="black"/> <path d="M 232,72 L 232,464" fill="none" stroke="black"/> <path d="M 264,32 L 264,64" fill="none" stroke="black"/> <path d="M 280,32 L 280,64" fill="none" stroke="black"/> <path d="M 328,72 L 328,464" fill="none" stroke="black"/> <path d="M 344,192 L 344,256" fill="none" stroke="black"/> <path d="M 344,432 L 344,464" fill="none" stroke="black"/> <path d="M 360,32 L 360,64" fill="none" stroke="black"/> <path d="M 544,192 L 544,256" fill="none" stroke="black"/> <path d="M 544,432 L 544,464" fill="none" stroke="black"/> <path d="M 184,32 L 264,32" fill="none" stroke="black"/> <path d="M 280,32 L 360,32" fill="none" stroke="black"/> <path d="M 184,64 L 264,64" fill="none" stroke="black"/> <path d="M 280,64 L 360,64" fill="none" stroke="black"/> <path d="M 24,80 L 216,80" fill="none" stroke="black"/> <path d="M 24,128 L 216,128" fill="none" stroke="black"/> <path d="M 240,176 L 320,176" fill="none" stroke="black"/> <path d="M 344,192 L 544,192" fill="none" stroke="black"/> <path d="M 344,256 L 544,256" fill="none" stroke="black"/> <path d="M 240,304 L 320,304" fill="none" stroke="black"/> <path d="M 8,320 L 216,320" fill="none" stroke="black"/> <path d="M 8,368 L 216,368" fill="none" stroke="black"/> <path d="M 240,416 L 320,416" fill="none" stroke="black"/> <path d="M 344,432 L 544,432" fill="none" stroke="black"/> <path d="M 344,464 L 544,464" fill="none" stroke="black"/> <polygon class="arrowhead" points="328,416 316,410.4 316,421.6" fill="black" transform="rotate(0,320,416)"/> <polygon class="arrowhead" points="328,176 316,170.4 316,181.6" fill="black" transform="rotate(0,320,176)"/> <polygon class="arrowhead" points="248,304 236,298.4 236,309.6" fill="black" transform="rotate(180,240,304)"/> <g class="text"> <text x="220" y="52">Client</text> <text x="316" y="52">Server</text> <text x="72" y="100">Long-term</text> <text x="140" y="100">client</text> <text x="188" y="100">key:</text> <text x="116" y="116">sk1,</text> <text x="152" y="116">pk1</text> <text x="224" y="116">-</text> <text x="256" y="164">pk1</text> <text x="336" y="212">-</text> <text x="392" y="212">Long-term</text> <text x="460" y="212">server</text> <text x="508" y="212">key:</text> <text x="436" y="228">sk2,</text> <text x="472" y="228">pk2</text> <text x="364" y="244">ss</text> <text x="384" y="244">=</text> <text x="436" y="244">KeyEx(pk1,</text> <text x="500" y="244">sk2)</text> <text x="312" y="292">pk2</text> <text x="28" y="340">ss</text> <text x="48" y="340">=</text> <text x="96" y="340">KeyEx(pk2</text> <text x="164" y="340">sk1)</text> <text x="92" y="356">encryptContent(ss)</text> <text x="224" y="356">-</text> <text x="280" y="388">encrypted</text> <text x="288" y="404">content</text> <text x="428" y="452">decryptContent(ss)</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +---------+ +---------+ | Client | | Server | +---------+ +---------+ +-----------------------+ | | | Long-term client key: | | | | sk1, pk1 |-| | +-----------------------+ | | | | | pk1 | |---------->| | | +------------------------+ | |-| Long-term server key: | | | | sk2, pk2 | | | | ss = KeyEx(pk1, sk2) | | | +------------------------+ | | | pk2| |<----------| +-------------------------+ | | | ss = KeyEx(pk2, sk1) | | | | encryptContent(ss) |-| | +-------------------------+ | | | encrypted | | content | |---------->| | | +------------------------+ | | | decryptContent(ss) | | | +------------------------+ ]]></artwork> </artset> </figure><t>What's important to note about<t>In the sample flowaboveabove, it is important to note that the shared secret <tt>ss</tt> is derived using key material from both theClientclient and theServer,server, which classifies it as an AKE. There is another property of a key exchange, called Non-Interactive Key Exchange(NIKE) which(NIKE), that refers to whether the sender can compute the shared secret <tt>ss</tt> and encrypt content without requiring active interaction (an exchange of network messages) with the recipient. <xref target="tab-dh-ake"/> shows aDiffie-HellmanDH keyexchangeexchange, which is anAKE,AKE since both parties are using long-term keyswhichthat can have established trust (for example, via certificates), but it is not aNIKE,NIKE since the client needs to wait for the network interaction to receive the receiver's public key <tt>pk2</tt> before it can compute the shared secret <tt>ss</tt> and begin content encryption. However, a DH key exchange can be an AKE and a NIKE at the same time if the receiver's public key is known to the sender inadvance,advance (see <xref target="tab-dh-ake-nike"/>), and many Internet protocols rely on this property of DH-based key exchanges.</t> <figure anchor="tab-dh-ake-nike"><name>Diffie-Hellman based<name>Simultaneous DH-Based AKE andNIKE simultaneously</name>NIKE</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="400" width="536" viewBox="0 0 536 400" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,80 L 8,192" fill="none" stroke="black"/> <path d="M 136,160 L 136,168" fill="none" stroke="black"/> <path d="M 168,32 L 168,64" fill="none" stroke="black"/> <path d="M 200,80 L 200,192" fill="none" stroke="black"/> <path d="M 216,72 L 216,368" fill="none" stroke="black"/> <path d="M 248,32 L 248,64" fill="none" stroke="black"/> <path d="M 264,32 L 264,64" fill="none" stroke="black"/> <path d="M 312,72 L 312,368" fill="none" stroke="black"/> <path d="M 328,288 L 328,368" fill="none" stroke="black"/> <path d="M 344,32 L 344,64" fill="none" stroke="black"/> <path d="M 456,336 L 456,344" fill="none" stroke="black"/> <path d="M 528,288 L 528,368" fill="none" stroke="black"/> <path d="M 168,32 L 248,32" fill="none" stroke="black"/> <path d="M 264,32 L 344,32" fill="none" stroke="black"/> <path d="M 168,64 L 248,64" fill="none" stroke="black"/> <path d="M 264,64 L 344,64" fill="none" stroke="black"/> <path d="M 8,80 L 200,80" fill="none" stroke="black"/> <path d="M 8,192 L 200,192" fill="none" stroke="black"/> <path d="M 224,272 L 304,272" fill="none" stroke="black"/> <path d="M 328,288 L 528,288" fill="none" stroke="black"/> <path d="M 328,368 L 528,368" fill="none" stroke="black"/> <polygon class="arrowhead" points="312,272 300,266.4 300,277.6" fill="black" transform="rotate(0,304,272)"/> <g class="text"> <text x="204" y="52">Client</text> <text x="300" y="52">Server</text> <text x="56" y="100">Long-term</text> <text x="124" y="100">client</text> <text x="172" y="100">key:</text> <text x="100" y="116">sk1,</text> <text x="136" y="116">pk1</text> <text x="208" y="116">-</text> <text x="56" y="132">Long-term</text> <text x="124" y="132">server</text> <text x="172" y="132">key:</text> <text x="96" y="148">pk2</text> <text x="28" y="164">ss</text> <text x="48" y="164">=</text> <text x="96" y="164">KeyEx(pk2</text> <text x="164" y="164">sk1)</text> <text x="92" y="180">encryptContent(ss)</text> <text x="208" y="180">-</text> <text x="244" y="228">pk1,</text> <text x="264" y="244">encrypted</text> <text x="272" y="260">content</text> <text x="320" y="308">-</text> <text x="376" y="308">Long-term</text> <text x="444" y="308">server</text> <text x="492" y="308">key:</text> <text x="420" y="324">sk2,</text> <text x="456" y="324">pk2</text> <text x="348" y="340">ss</text> <text x="368" y="340">=</text> <text x="416" y="340">KeyEx(pk1</text> <text x="484" y="340">sk2)</text> <text x="412" y="356">decryptContent(ss)</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +---------+ +---------+ | Client | | Server | +---------+ +---------+ +-----------------------+ | | | Long-term client key: | | | | sk1, pk1 |-| | | Long-term server key: | | | | pk2 | | | | ss = KeyEx(pk2, sk1) | | | | encryptContent(ss) |-| | +-----------------------+ | | | | | pk1, | | encrypted | | content | |---------->| | | +------------------------+ | |-| Long-term server key: | | | | sk2, pk2 | | | | ss = KeyEx(pk1, sk2) | | | | decryptContent(ss) | | | +------------------------+ ]]></artwork> </artset> </figure> <t>The complication with KEMs is that a KEM <tt>Encaps()</tt> is non-deterministic; it involves randomness chosen by the sender of that message. Therefore, in order to perform an AKE, the client must wait for the server to generate the needed randomness and perform <tt>Encaps()</tt> against the client key, which necessarily requires a network round-trip. Therefore, a KEM-based protocol can either be an AKE or a NIKE, but it cannot be both at the same time. Consequently, certain Internet protocols will necessitate a redesign to accommodate this distinction, either by introducing extra networkround-tripsround trips or by making trade-offs in security properties.</t> <figure anchor="tab-kem-ake"><name>KEM based<name>KEM-Based AKE</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="480"width="560"width="576" viewBox="0 0560576 480" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M8,808,288 L8,112"8,352" fill="none" stroke="black"/> <path d="M8,28824,80 L8,352"24,112" fill="none" stroke="black"/> <path d="M184,32200,32 L184,64"200,64" fill="none" stroke="black"/> <path d="M208,80224,80 L208,112"224,112" fill="none" stroke="black"/> <path d="M208,336224,288 L208,352"224,352" fill="none" stroke="black"/> <path d="M224,72240,72 L224,464"240,464" fill="none" stroke="black"/> <path d="M264,32280,32 L264,64"280,64" fill="none" stroke="black"/> <path d="M280,32296,32 L280,64"296,64" fill="none" stroke="black"/> <path d="M320,72336,72 L320,464"336,464" fill="none" stroke="black"/> <path d="M336,176352,176 L336,224"352,224" fill="none" stroke="black"/> <path d="M336,416352,416 L336,464"352,464" fill="none" stroke="black"/> <path d="M360,32376,32 L360,64"376,64" fill="none" stroke="black"/> <path d="M552,176568,176 L552,224"568,224" fill="none" stroke="black"/> <path d="M552,416568,416 L552,464"568,464" fill="none" stroke="black"/> <path d="M184,32200,32 L264,32"280,32" fill="none" stroke="black"/> <path d="M280,32296,32 L360,32"376,32" fill="none" stroke="black"/> <path d="M184,64200,64 L264,64"280,64" fill="none" stroke="black"/> <path d="M280,64296,64 L360,64"376,64" fill="none" stroke="black"/> <path d="M8,8024,80 L208,80"224,80" fill="none" stroke="black"/> <path d="M8,11224,112 L208,112"224,112" fill="none" stroke="black"/> <path d="M232,160248,160 L312,160"328,160" fill="none" stroke="black"/> <path d="M336,176352,176 L552,176"568,176" fill="none" stroke="black"/> <path d="M336,224352,224 L552,224"568,224" fill="none" stroke="black"/> <path d="M232,272248,272 L312,272"328,272" fill="none" stroke="black"/> <path d="M 8,288 L200,288"224,288" fill="none" stroke="black"/> <path d="M 8,352 L208,352"224,352" fill="none" stroke="black"/> <path d="M232,400248,400 L312,400"328,400" fill="none" stroke="black"/> <path d="M336,416352,416 L552,416"568,416" fill="none" stroke="black"/> <path d="M336,464352,464 L552,464"568,464" fill="none" stroke="black"/> <polygon class="arrowhead"points="320,400 308,394.4 308,405.6"points="336,400 324,394.4 324,405.6" fill="black"transform="rotate(0,312,400)"/>transform="rotate(0,328,400)"/> <polygon class="arrowhead"points="320,160 308,154.4 308,165.6"points="336,160 324,154.4 324,165.6" fill="black"transform="rotate(0,312,160)"/>transform="rotate(0,328,160)"/> <polygon class="arrowhead"points="240,272 228,266.4 228,277.6"points="256,272 244,266.4 244,277.6" fill="black"transform="rotate(180,232,272)"/>transform="rotate(180,248,272)"/> <g class="text"> <textx="220"x="236" y="52">Client</text> <textx="316"x="332" y="52">Server</text> <textx="36"x="52" y="100">pk1,</text> <textx="72"x="88" y="100">sk1</text> <textx="96"x="112" y="100">=</text> <textx="152"x="168" y="100">kemKeyGen()</text> <textx="216"x="232" y="100">-</text> <textx="240"x="256" y="148">pk1</text> <textx="328"x="344" y="196">-</text> <textx="364"x="380" y="196">ss1,</text> <textx="400"x="416" y="196">ct1</text> <textx="424"x="440" y="196">=</text> <textx="492"x="508" y="196">kemEncaps(pk1)</text> <textx="364"x="380" y="212">pk2,</text> <textx="400"x="416" y="212">sk2</text> <textx="424"x="440" y="212">=</text> <textx="480"x="496" y="212">kemKeyGen()</text> <textx="288"x="304" y="260">ct1,pk2</text> <text x="32" y="308">ss1</text> <text x="56" y="308">=</text> <text x="124" y="308">kemDecaps(ct1,</text> <text x="204" y="308">sk1)</text> <textx="236" y="308">-|</text> <textx="36" y="324">ss2,</text> <text x="72" y="324">ct2</text> <text x="96" y="324">=</text> <text x="164" y="324">kemEncaps(pk2)</text> <text x="232" y="324">-</text> <text x="28" y="340">ss</text> <text x="48" y="340">=</text> <text x="112" y="340">Combiner(ss1,</text> <text x="188" y="340">ss2)</text> <textx="240"x="256" y="388">ct2</text> <textx="328"x="344" y="436">-</text> <textx="360"x="376" y="436">ss2</text> <textx="384"x="400" y="436">=</text> <textx="452"x="468" y="436">kemDecaps(ct2,</text> <textx="532"x="548" y="436">sk2)</text> <textx="356"x="372" y="452">ss</text> <textx="376"x="392" y="452">=</text> <textx="440"x="456" y="452">Combiner(ss1,</text> <textx="516"x="532" y="452">ss2)</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +---------+ +---------+ | Client | | Server | +---------+ +---------+ +------------------------+ | | | pk1, sk1 = kemKeyGen() |-| | +------------------------+ | | | | |pk1 | |---------->| | | +--------------------------+ | |-| ss1, ct1 = kemEncaps(pk1)| | | | pk2, sk2 = kemKeyGen() | | | +--------------------------+ | | | ct1,pk2| |<----------|+------------------------++--------------------------+ | | | ss1 = kemDecaps(ct1,sk1)|-|sk1)| | | | ss2, ct2 =kemEncaps(pk2)|kemEncaps(pk2)|-| | | ss = Combiner(ss1,ss2)|ss2) | |+------------------------+| +--------------------------+ | | | | |ct2 | |---------->| | | +--------------------------+ | |-| ss2 = kemDecaps(ct2, sk2)| | | | ss = Combiner(ss1, ss2) | | | +--------------------------+ ]]></artwork> </artset> </figure><t>Here,<t>In the figure above, <tt>Combiner(ss1, ss2)</tt>, often referred to as a KEMCombiner,combiner, is a cryptographic construction that takes in two shared secrets and returns a single combined shared secret. The simplest combiner is concatenation <tt>ss1 || ss2</tt>, but combiners can vary in complexity depending on the cryptographic properties required. For example, if the combination should preserve IND-CCA2 (see <xreftarget="INDCCA2"/>target="INDCCA2"/>) of eitherinputinput, even if the other is chosen maliciously, then a more complex construct is required. Another consideration for combiner design is the so-called "binding properties" introduced in <xref target="KEEPINGUP"/>, which may require the ciphertexts and recipient public keys to be included in the combiner. KEM combiner security analysis becomes more complicated in hybrid settings where the two KEMs represent different algorithms, for example, where one is ML-KEM and the other is ECDH. For a more thorough discussion of KEM combiners, see <xref target="KEEPINGUP"/>, <xreftarget="I-D.draft-ounsworth-cfrg-kem-combiners"/>,target="I-D.ounsworth-cfrg-kem-combiners"/>, and <xref target="I-D.irtf-cfrg-hybrid-kems"/>.</t> </section> <section anchor="security-properties-of-kems"> <name>Security Properties of KEMs</name> <t>The security properties described in this section (IND-CCA2 and binding) are not an exhaustive list of all possible KEM security considerations. They were selected because they are fundamental to evaluating KEM suitability in protocol design and are commonly discussed in current PQC work.</t> <section anchor="INDCCA2"> <name>IND-CCA2</name> <t>IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Attack) is an advanced security notion for encryption schemes. It ensures the confidentiality of the plaintext and resistance against chosen-ciphertext attacks. An appropriate definition of IND-CCA2 security for KEMs can be found in <xref target="CS01"/> and <xref target="BHK09"/>. ML-KEM <xref target="ML-KEM"/> and Classic McEliece provide IND-CCA2 security.</t> <t>Understanding IND-CCA2 security is essential for individuals involved in designing or implementing cryptographic systems and protocols in order to evaluate the strength of the algorithm, assess its suitability for specific use cases, and ensure that data confidentiality and security requirements are met. Understanding IND-CCA2 security is generally not necessary for developers migrating to using an IETF-vettedkey establishment method (KEM)KEM within a given protocol or flow. IND-CCA2 is a widely accepted security notion for public key encryption mechanisms, making it suitable for a broad range of applications. When an IETF specification defines a new KEM, its security considerations should fully describe the relevant cryptographic properties, including IND-CCA2.</t> </section> <section anchor="binding"> <name>Binding</name> <t>KEMs also have an orthogonal set of properties to consider when designing protocols around them: binding <xref target="KEEPINGUP"/>. This can be "ciphertext binding", "public key binding", "context binding", or any other property that is important to not be substituted between KEM invocations. In general, a KEM is considered to bind a certain value if substitution of that value by an attacker will necessarily result in a different shared secret being derived. As an example, if an attacker can construct two different ciphertextswhichthat will decapsulate to the same sharedsecret; orsecret, can construct a ciphertextwhichthat will decapsulate to the same shared secret under two different public keys, or can substitute whole KEM exchanges from one session into another, then the construction is not ciphertext binding, public key binding, or contextbindingbinding, respectively. Similarly, protocol designers may wish to bind protocol state information such as a transaction ID or nonce so that attempts to replay ciphertexts from one session inside a different session will be blocked at the cryptographic level because the server derives a different shared secret and is thus is unable to decrypt the content.</t> <t>The solution to binding is generally achieved at the protocol design level: It is recommended to avoid using the KEM output shared secret directly without integrating it into an appropriate protocol. While KEM algorithms provide key secrecy, they do not inherently ensure source authenticity, protect against replay attacks, or guarantee freshness. These security properties should be addressed by incorporating the KEM into a protocol that has been analyzed for such protections. Even though modern KEMs such as ML-KEM produce full-entropy shared secrets, it is still advisable for binding reasons to passitthe shared secret through a key derivation function (KDF) and also include all values that you wish to bind;then finallyfinally, you will have a shared secret that is safe to use at the protocol level.</t> </section> </section> <section anchor="hpke"> <name>HPKE</name> <t>Modern cryptography has long used the notion of "hybrid encryption" where an asymmetric algorithm is used to establish akey,key and then a symmetric algorithm is used for bulk content encryption. The previous sections explained important security properties of KEMs, such as IND-CCA2 security and binding, and emphasized that these properties must be supported by proper protocol design. One widely deployed scheme that achieves this isHPKE (HybridHybrid Public KeyEncryption)Encryption (HPKE) <xref target="RFC9180"/>.</t> <t>HPKE(hybrid public key encryption)<xref target="RFC9180"/> works with a combination of KEMs,KDFsKDFs, andAEAD (authenticated encryptionAuthenticated Encryption withadditional data)Associated Data (AEAD) schemes. HPKE includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of akey encapsulation mechanism (KEM)KEM private key. HPKE can be extended to support hybrid post-quantum KEM <xref target="I-D.ietf-hpke-pq"/>. ML-KEM does not support the static-ephemeral key exchange that allows HPKE that is based onDH basedDH-based KEMs and its optional authenticated modes as discussed insection 1.5 of<xreftarget="I-D.draft-connolly-cfrg-xwing-kem"/>.</t>section="1.5" sectionFormat="of" target="I-D.connolly-cfrg-xwing-kem"/>.</t> </section> </section> <section anchor="pqc-signatures-1"> <name>PQC Signatures</name> <t>Any digital signature scheme that provides a construction defining security under a post-quantum setting falls under this category of PQC signatures.</t> <section anchor="security-properties-of-pqc-signatures"> <name>Security Properties of PQC Signatures</name> <section anchor="euf-cma-and-suf-cma"> <name>EUF-CMA and SUF-CMA</name> <t>EUF-CMA (existential unforgeability under chosen message attack) <xref target="GMR88"/> 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 arbitrary message. EUF-CMA provides strong protection against forgery attacks, ensuring the integrity and authenticity of digital signatures by preventing unauthorized modifications or fraudulent signatures. ML-DSA, FN-DSA, and SLH-DSA provide EUF-CMA security.</t> <t>SUF-CMA (strong unforgeability under chosen message attack) builds upon EUF-CMA by requiring that an adversary cannot produce a different valid signature for a message that has already been signed by the signing oracle. Like EUF-CMA, SUF-CMA provides robust assurances for digital signature schemes, further enhancing their security posture. ML-DSA, FN-DSA, and SLH-DSA also achieve SUF-CMA security.</t> <t>Understanding EUF-CMA and SUF-CMA security is essential for designing or implementing cryptographic systems in order to ensure the security, reliability, and robustness of digital signature schemes. These notions allow for informeddecision-making,decision making, vulnerability analysis, compliance with standards, and designing systems that provide strong protection against forgery attacks. For developers migrating tousingan IETF-vetted PQC signature scheme within a given protocol or flow, a deep understanding of EUF-CMA and SUF-CMA security may not be necessary, as the schemes vetted by IETF adhere to these stringent security standards.</t> <t>EUF-CMA and SUF-CMA are considered strong security benchmarks for public key signature algorithms, making them suitable for most applications. Authors of IETFspecification authorsspecifications should include all security concerns in the "Security Considerations" section of the relevant RFC and should not assume that implementers are experts in cryptographic theory.</t> </section> </section> <section anchor="sig-scheme"> <name>Details of FN-DSA, ML-DSA, and SLH-DSA</name> <t>ML-DSA <xref target="ML-DSA"/> is a digital signature algorithm based on the hardness of lattice problems over module lattices (i.e., the Module Learning with Errorsproblem (MLWE)).(MLWE) problem). The design of the algorithm is based on the "Fiat-Shamir with Aborts" <xref target="Lyu09"/> framework introduced byLyubashevsky,Lyubashevsky that leverages rejection sampling to render lattice-based Fiat-Shamir (FS) schemes compact and secure. ML-DSA usesuniformly-distributeduniformly distributed random number sampling over small integers to compute coefficients in error vectors, which makes the scheme easier to implement comparedwithto FN-DSA <xreftarget="FN-DSA"/>target="FN-DSA"/>, which uses Gaussian-distributed numbers, necessitating the need to usefloating pointfloating-point arithmetic during signature generation.</t> <t>ML-DSA offers both deterministic and randomized signing and is instantiated with3three parameter sets providing different security levels. Security properties of ML-DSA are discussed inSection 9 of<xreftarget="I-D.ietf-lamps-dilithium-certificates"/>.</t>section="9" sectionFormat="of" target="RFC9881"/>.</t> <t>FN-DSA <xref target="FN-DSA"/> 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 certain class of lattices and a trapdoor sampler technique.</t> <t>The main design principle of FN-DSA 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. FN-DSA also offers very efficient signing and verification procedures. The main potential downsides of FN-DSA refer to the non-triviality of its algorithms and the need forfloating pointfloating-point arithmetic support in order to support Gaussian-distributed random number sampling where the other lattice schemes use the less efficient but easier to supportuniformly-distributeduniformly distributed random number sampling.</t> <t>Implementers of FN-DSA need to be aware that FN-DSA signing is highly susceptible to side-channelattacks,attacks unless constant-time 64-bit floating-point operations are used. This requirement is extremely platform-dependent, as noted in NIST'sreport.</t>report <xref target="NIST"/>.</t> <t>The performance characteristics of ML-DSA and FN-DSA may differ based on the specific implementation and hardware platform. Generally, ML-DSA is known for its relatively fast signature generation, while FN-DSA can provide more efficient signature verification. The choice may depend on whether the application requires more frequent signature generation or signature verification(See(see <xref target="LIBOQS"/>). For further clarity on the sizes and security levels, please refer to the tables in Sections <xreftarget="RecSecurity"/>target="RecSecurity" format="counter"/> and <xreftarget="Comparisons"/>.</t>target="Comparisons" format="counter"/>.</t> <t>SLH-DSA <xref target="SLH-DSA"/> 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. SLH-DSA was designed to sign up to 2^64 messages under a given key pair, and it 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. SLH-DSA offers smaller public key sizes, larger signature sizes, slower signature generation, and slower verification when compared to ML-DSA and FN-DSA. SLH-DSA does not introduce a new hardness assumption beyond those inherent to the underlying hash functions. It builds upon established foundations in cryptography, making it a reliable and robust digital signature scheme for a post-quantum world.</t> <t>All of thesealgorithms, ML-DSA,algorithms (ML-DSA, FN-DSA, andSLH-DSASLH-DSA) include two signature modes: pure mode, where the entire content is signed directly, and pre-hash mode, where a digest of the content is signed.</t> </section> <section anchor="details-of-xmss-and-lms"> <name>Details of XMSS and LMS</name> <t>The eXtended Merkle Signature Scheme (XMSS) <xref target="RFC8391"/> and Hierarchical Signature Scheme (HSS) / Leighton-Micali Signature (LMS) <xref target="RFC8554"/> are stateful hash-based signature schemes, where the secret key state changes over time. In both schemes, reusing a secret key state compromises cryptographic security guarantees.</t> <t>XMSS and LMS can be used for signing a potentially large but fixed number ofmessagesmessages, and the number of signing operations depends upon the size of the tree. XMSS and LMS provide cryptographic digital signatures without relying on the conjectured hardness of mathematical problems, instead leveraging the properties of cryptographic hash functions. Multi-tree XMSS and LMS (i.e., XMSS-MT and HSS, respectively) use ahyper-tree basedhyper-tree-based hierarchical approach with a Merkle tree at each level of the hierarchy. <xref target="RFC8391"/> describes both single-tree and multi-tree variants of XMSS, while <xref target="RFC8554"/> describes the Leighton-Micali One-Time Signature (LM-OTS) system as well as the LMS and HSS N-time signature systems. Comparison of XMSS and LMS is discussed inSection 10 of<xref section="10" sectionFormat="of" target="RFC8554"/>.</t> <t>The number of tree layers in multi-tree XMSS and HSS provides a trade-off between signature size on the one side and key generation and signing speed on the other side. Increasing the number of layers reduces key generation time exponentially and signing time linearly at the cost of increasing the signature size linearly. HSS allows for customization of eachsubtreesubtree, whereas XMSS-MT does not, electing instead to use the same structure for each subtree.</t> <t>Due to the complexities described above,theXMSS and LMS are notasuitablereplacementreplacements for traditional signature schemes like RSA or ECDSA. Applications that expect a long lifetime of a signature, like firmware update or secure boot, are typical use cases where those schemes can be successfully applied.</t> <section anchor="lms-key-and-signature-sizes"> <name>LMS Key and Signature Sizes</name> <t>The LMS scheme is characterized by four distinct parameter sets: the underlying hash function (SHA2-256 or SHAKE-256), the length of the digest (24 or 32 bytes), the LMS tree height parameter that controls a maximal number of signatures that the private key can produce, and the width of the Winternitz coefficients (see <xreftarget="RFC8554"/>, section 4.1)section="4.1" sectionFormat="comma" target="RFC8554"/>) that can be used to trade-off signing time for signature size. Parameters can be mixed, providing 80 possible parameterizations of the scheme.</t> <t>The public (PK) and private (SK) key size depends on the length of the digest (M). The signature size depends on the digest, the Winternitz parameter (W), the LMS tree height (H), and the length of the digest. The table below provides key and signature sizes for parameterization with the digest size M=32 of the scheme.</t> <table> <thead> <tr> <th align="left">PK</th> <th align="left">SK</th> <th align="left">W</th> <th align="left">H=5</th> <th align="left">H=10</th> <th align="left">H=15</th> <th align="left">H=20</th> <th align="left">H=25</th> </tr> </thead> <tbody> <tr> <td align="left">56</td> <td align="left">52</td> <td align="left">1</td> <td align="left">8684</td> <td align="left">8844</td> <td align="left">9004</td> <td align="left">9164</td> <td align="left">9324</td> </tr> <tr> <td align="left">56</td> <td align="left">52</td> <td align="left">2</td> <td align="left">4460</td> <td align="left">4620</td> <td align="left">4780</td> <td align="left">4940</td> <td align="left">5100</td> </tr> <tr> <td align="left">56</td> <td align="left">52</td> <td align="left">4</td> <td align="left">2348</td> <td align="left">2508</td> <td align="left">2668</td> <td align="left">2828</td> <td align="left">2988</td> </tr> <tr> <td align="left">56</td> <td align="left">52</td> <td align="left">8</td> <td align="left">1292</td> <td align="left">1452</td> <td align="left">1612</td> <td align="left">1772</td> <td align="left">1932</td> </tr> </tbody> </table> </section> </section> <section anchor="hash-then-sign"> <name>Hash-then-Sign</name> <t>Within the hash-then-sign paradigm, the message is hashed before signing it. By pre-hashing, the onus of resistance to existential forgeries becomes heavily reliant on the collision-resistance of the hash function in use. The hash-then-sign paradigm has the ability to improve application performance by reducing the size of signed messages that need to be transmitted between application and cryptographicmodule,module and making the signature size predictable and manageable. 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.</t> <t>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. Crucially for hardware security modules,Hash-then-Signhash-then-sign also significantly reduces the amount of data that needs to be transmitted and processed by a Hardware Security Module (HSM). Consider scenarios such as a networked HSM located in a different data center from the calling application or a smart card connected over a USB interface. In these cases, streaming a message that is megabytes or gigabytes long can result in notable network latency, on-device signing delays, or even depletion of available on-device memory.</t> <t>Note that the vast majority of Internet protocols that sign large messages already perform some form of content hashing at the protocol level, so this tends to be more of a concern with proprietary cryptographicprotocols,protocols and protocols from non-IETF standards bodies. Protocols like TLS 1.3 and DNSSEC use theHash-then-Signhash-then-sign paradigm. In TLS 1.3 <xref target="RFC8446"/> CertificateVerify messages, the content that is covered under the signature includes the transcript hash output(Section 4.4.1 of <xref target="RFC8446"/>),(<xref section="4.4.1" sectionFormat="of" target="RFC8446"/>) while DNSSEC <xref target="RFC4034"/> uses it to provide origin authentication and integrity assurance services for DNS data. Similarly, the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> includes a mandatory message digest step before invoking the signature algorithm.</t> <t>In the case of ML-DSA, it internally incorporates the necessary hash operations as part of its signing algorithm. ML-DSA directly takes the original message, applies a hash function internally, and then uses the resulting hash value for the signature generation process. In the case of SLH-DSA, it internally performs randomized message compression using a keyed hash function that can process arbitrary length messages. In the case of FN-DSA, the SHAKE-256 hash function is used as part of the signature process to derive a digest of the message being signed.</t> <t>Therefore, ML-DSA, FN-DSA, and SLH-DSA offer enhanced security over the traditionalHash-then-Signhash-then-sign paradigmbecausebecause, by incorporating dynamic key material into the message digest, a pre-computed hash collision on the message to be signed no longer yields a signature forgery. Applications requiring the performance and bandwidth benefits ofHash-then-Signhash-then-sign may still pre-hash at the protocol level prior to invoking ML-DSA, FN-DSA, or SLH-DSA, but protocol designers should be aware that doing sore-introducesreintroduces the weakness that hash collisions directly yield signature forgeries. Signing the full un-digested message is recommended where applications can tolerate it.</t> </section> </section> <section anchor="RecSecurity"> <name>NIST Recommendations for Security/and PerformanceTradeoffs</name>Trade-offs</name> <t>This information is are-printreprint of information provided in the NIST PQC project <xref target="NIST"/> as of the time this document is published.The Table 2<xref target="security-levels-table"/> denotes the five security levels provided by NIST for PQC algorithms. Neither NIST nor the IETFmakemakes any specific recommendations about which security level to use. In general, protocols will include algorithm choices at multiple levels so that users can choose the level appropriate to their policies and data classification, similar to how organizations today choose which size of RSA key to use. The security levels are defined as requiring computational resources comparable to or greater than an attack on AES (128,192192, and 256) and SHA2/SHA3 algorithms, i.e., exhaustive key recovery for AES and optimal collision search for SHA2/SHA3.</t><table><table anchor="security-levels-table"> <thead> <tr> <th align="left">PQ Security Level</th> <th align="left">AES/SHA(2/3) hardness</th> <th align="left">PQC Algorithm</th> </tr> </thead> <tbody> <tr> <td align="left">1</td> <td align="left">AES-128 (exhaustive key recovery)</td> <td align="left">ML-KEM-512, FN-DSA-512, SLH-DSA-SHA2/SHAKE-128f/s</td> </tr> <tr> <td align="left">2</td> <td align="left">SHA-256/SHA3-256 (collision search)</td> <td align="left">ML-DSA-44</td> </tr> <tr> <td align="left">3</td> <td align="left">AES-192 (exhaustive key recovery)</td> <td align="left">ML-KEM-768, ML-DSA-65, SLH-DSA-SHA2/SHAKE-192f/s</td> </tr> <tr> <td align="left">4</td> <td align="left">SHA-384/SHA3-384 (collision search)</td> <td align="left">No algorithm tested at this level</td> </tr> <tr> <td align="left">5</td> <td align="left">AES-256 (exhaustive key recovery)</td> <td align="left">ML-KEM-1024, FN-DSA-1024, ML-DSA-87, SLH-DSA-SHA2/SHAKE-256f/s</td> </tr> </tbody> </table> <t>The SLH-DSA-x-yf/s "f/s" in the above table denotes whether SLH-DSA is using SHAKE or SHA-2 as an underlying hash function "x" and whether it is the fast (f) or small (s) version for "y" bit AES security level. Refer to <xreftarget="I-D.ietf-lamps-cms-sphincs-plus"/>target="RFC9814"/> for further details on SLH-DSA algorithms.</t> <t>The following table compares the signature sizes for different SLH-DSA algorithm categories at equivalent securitylevels,levels using the "simple" version. The categories include"(f)""f" for fast signaturegeneration,generation and"(s)""s" for smaller signature size and faster verification, although with slower signature generation. Both SHA-256 and SHAKE-256 parameterizations produce the same signature sizes and are therefore included together in the table.</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">1</td> <td align="left">SLH-DSA-{SHA2,SHAKE}-128f</td> <td align="left">32</td> <td align="left">64</td> <td align="left">17088</td> </tr> <tr> <td align="left">1</td> <td align="left">SLH-DSA-{SHA2,SHAKE}-128s</td> <td align="left">32</td> <td align="left">64</td> <td align="left">7856</td> </tr> <tr> <td align="left">3</td> <td align="left">SLH-DSA-{SHA2,SHAKE}-192f</td> <td align="left">48</td> <td align="left">96</td> <td align="left">35664</td> </tr> <tr> <td align="left">3</td> <td align="left">SLH-DSA-{SHA2,SHAKE}-192s</td> <td align="left">48</td> <td align="left">96</td> <td align="left">16224</td> </tr> <tr> <td align="left">5</td> <td align="left">SLH-DSA-{SHA2,SHAKE}-256f</td> <td align="left">64</td> <td align="left">128</td> <td align="left">49856</td> </tr> <tr> <td align="left">5</td> <td align="left">SLH-DSA-{SHA2,SHAKE}-256s</td> <td align="left">64</td> <td align="left">128</td> <td align="left">29792</td> </tr> </tbody> </table> <t>The following table illustrates 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">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/signature size (in bytes)</th> </tr> </thead> <tbody> <tr> <td align="left">1</td> <td align="left">ML-KEM-512</td> <td align="left">800</td> <td align="left">1632</td> <td align="left">768</td> </tr> <tr> <td align="left">1</td> <td align="left">FN-DSA-512</td> <td align="left">897</td> <td align="left">1281</td> <td align="left">666</td> </tr> <tr> <td align="left">2</td> <td align="left">ML-DSA-44</td> <td align="left">1312</td> <td align="left">2560</td> <td align="left">2420</td> </tr> <tr> <td align="left">3</td> <td align="left">ML-KEM-768</td> <td align="left">1184</td> <td align="left">2400</td> <td align="left">1088</td> </tr> <tr> <td align="left">3</td> <td align="left">ML-DSA-65</td> <td align="left">1952</td> <td align="left">4032</td> <td align="left">3309</td> </tr> <tr> <td align="left">5</td> <td align="left">FN-DSA-1024</td> <td align="left">1793</td> <td align="left">2305</td> <td align="left">1280</td> </tr> <tr> <td align="left">5</td> <td align="left">ML-KEM-1024</td> <td align="left">1568</td> <td align="left">3168</td> <td align="left">1588</td> </tr> <tr> <td align="left">5</td> <td align="left">ML-DSA-87</td> <td align="left">2592</td> <td align="left">4896</td> <td align="left">4627</td> </tr> </tbody> </table> </section> <section anchor="Comparisons"> <name>Comparing PQC KEMs/Signaturesvs.and TraditionalKEMs (KEXs)/Signatures</name>KEMs/Signatures</name> <t>This section provides two tables for comparison of different KEMs andsignaturessignatures, respectively, in the traditional and post-quantum scenarios. These tables 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 traditionalvs.and PQC KEMs in terms of security, public and 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">Traditional</td> <td align="left">P256_HKDF_SHA-256</td> <td align="left">65</td> <td align="left">32</td> <td align="left">65</td> </tr> <tr> <td align="left">Traditional</td> <td align="left">P521_HKDF_SHA-512</td> <td align="left">133</td> <td align="left">66</td> <td align="left">133</td> </tr> <tr> <td align="left">Traditional</td> <td align="left">X25519_HKDF_SHA-256</td> <td align="left">32</td> <td align="left">32</td> <td align="left">32</td> </tr> <tr> <td align="left">1</td> <td align="left">ML-KEM-512</td> <td align="left">800</td> <td align="left">1632</td> <td align="left">768</td> </tr> <tr> <td align="left">3</td> <td align="left">ML-KEM-768</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">ML-KEM-1024</td> <td align="left">1568</td> <td align="left">3168</td> <td align="left">1568</td> </tr> </tbody> </table> <t>The next table compares traditionalvs.and 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">Traditional</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">Traditional</td> <td align="left">ECDSA-P256</td> <td align="left">64</td> <td align="left">32</td> <td align="left">64</td> </tr> <tr> <td align="left">1</td> <td align="left">FN-DSA-512</td> <td align="left">897</td> <td align="left">1281</td> <td align="left">666</td> </tr> <tr> <td align="left">2</td> <td align="left">ML-DSA-44</td> <td align="left">1312</td> <td align="left">2560</td> <td align="left">2420</td> </tr> <tr> <td align="left">3</td> <td align="left">ML-DSA-65</td> <td align="left">1952</td> <td align="left">4032</td> <td align="left">3309</td> </tr> <tr> <td align="left">5</td> <td align="left">FN-DSA-1024</td> <td align="left">1793</td> <td align="left">2305</td> <td align="left">1280</td> </tr> <tr> <td align="left">5</td> <td align="left">ML-DSA-87</td> <td align="left">2592</td> <td align="left">4896</td> <td align="left">4627</td> </tr> </tbody> </table> <t>As is clear from the above table, PQC KEMs and signature schemes typically have significantly larger keys and ciphertexts/signatures than their traditional counterparts. These increased key and signatures sizes could introduce problems in protocols. As an example,IKEv2the Internet Key Exchange Protocol Version 2 (IKEv2) uses UDP as the transport protocol for its messages. One challenge with integrating a PQC KEM into IKEv2 is that IKE fragmentation cannot be utilized in the initial IKE_SA_INIT exchange. To address this issue, <xref target="RFC9242"/> introduces a solution by defining a new exchange called the "IntermediateExchange"Exchange", which can be fragmented using the IKE fragmentation mechanism. <xref target="RFC9370"/> then uses this Intermediate Exchange to carry out the PQC key exchange after the initial IKEv2 exchange and before the IKE_AUTH exchange. Another example from Section 6.3.3 of <xref target="SP-1800-38C"/>section 6.3.3shows that increased key and signature sizes cause protocol key exchange messages to span more network packets,therefore itwhich results in a higher total loss probability per packet. In lossy network conditions, this may increase the latency of the key exchange.</t> </section> <section anchor="PQT"> <name>Post-Quantum and Traditional (PQ/T) 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 ECDH, will fall to quantum cryptanalysis, 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 traditional 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. <xreftarget="I-D.ietf-pquip-pqt-hybrid-terminology"/>target="RFC9794"/> defines the terminology forthe post-quantum and traditional (PQ/T)PQ/T 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 mitigate both "harvest now, decrypt now" and HNDL attacks described in <xref target="timeline"/>. If the PQ portion were to have a flaw, the traditional (T) algorithm, which is secure againsttoday’stoday's attackers, prevents immediate decryption ("harvest now, decrypt now"). If the T algorithm is broken in the future by CRQCs, the PQ portion, assuming it remains secure, prevents later decryption("harvest now, decrypt later").(i.e., HNDL). A hybrid construction therefore provides confidentiality as long as at least one component remains secure. Two types of hybrid key agreement schemes are discussed below.</t><ul spacing="normal"> <li> <t>Concatenated<dl> <dt>Concatenated hybrid key agreementscheme: Thescheme:</dt> <dd> <t>The final shared secret that will be used as an input of the key derivation function is the result of the concatenation of the secrets established with each key agreement scheme. 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></li> <li> <t>Cascaded</dd> <dt>Cascaded hybrid key agreementscheme: Thescheme:</dt> <dd> <t>The final shared secret is computed by applying as many iterations of the key derivation function as the number of key agreement schemes composing the hybrid key agreement scheme. For example, <xref target="RFC9370"/> extendsthe Internet Key Exchange Protocol Version 2 (IKEv2)IKEv2 to allow one or more PQC algorithms in addition to the traditional algorithm to derive the final IKESASecurity Association (SA) keys using the cascade method as explained inSection 2.2.2 of<xref section="2.2.2" sectionFormat="of" target="RFC9370"/>.</t></li> </ul></dd> </dl> <t>Various instantiations of these two types of hybrid key agreement schemes have been explored. One must be careful when selecting which hybrid scheme to use. The chosen scheme for protocols like TLS 1.3 <xref target="I-D.ietf-tls-hybrid-design"/> has IND-CCA2 robustness. That is, IND-CCA2 security is guaranteed for the scheme as long as at least one of the component algorithms is IND-CCA2 secure.</t> </section> <section anchor="pqt-hybrid-authentication"> <name>PQ/T Hybrid Authentication</name> <t>The PQ/T hybrid authentication property provides resilience against catastrophic breaks or unforeseen vulnerabilities in PQC algorithms, allowing systems additional time to stabilize before migrating fully to pure PQ deployments.</t> <t>This property ensures authentication using a PQ/T hybridscheme,scheme as long as at least one component algorithm remains secure. For example, a PQ/T hybrid certificate <xref target="I-D.ietf-lamps-pq-composite-sigs"/> 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; separate certificates could be used for individual component algorithms <xreftarget="I-D.ietf-lamps-cert-binding-for-multi-auth"/>.target="RFC9763"/>. When separate certificates are used, it may be possible for attackers to take them apart or put them together in unexpected ways, including enabling cross-protocol attacks. The exact risks this presents are highly dependent on the protocol and use case, so a full security analysis is needed. Best practices for ensuring that pairs of certificates are only used as intended are discussed in more detail in Sections <xreftarget="COMPOSITE"/>target="COMPOSITE" format="counter"/> and <xreftarget="REUSE"/>target="REUSE" format="counter"/> of this document.</t> <t>The frequency and duration of system upgrades and the time when CRQCs will become widely available need to be weighed to determine whether and when to support the PQ/T Hybrid Authentication property.</t> </section> <section anchor="hybrid-cryptographic-algorithm-combinations-considerations-and-approaches"> <name>Hybrid Cryptographic Algorithm Combinations: Considerations and Approaches</name> <section anchor="hybrid-cryptographic-combinations"> <name>Hybrid Cryptographic Combinations</name> <t>It is also possible to use more than two algorithms together in a hybrid scheme, with various methods for combining them. For post-quantum transition purposes, the combination of a post-quantum algorithm with a traditional algorithm is the most straightforward and recommended. The use of multiple post-quantum algorithms with different mathematical bases has also been considered. Combining algorithms in a way that requires both to be used together ensures stronger security, while combinations that do not require both will sacrifice security but offer other benefits like backwards compatibility and crypto agility. Including a traditional key alongside a post-quantum key often has minimal bandwidth impact.</t> </section> <section anchor="COMPOSITE"> <name>Composite Keys in Hybrid Schemes</name> <t>When combining keys in an "and" mode, it may make more sense to consider them to be a single compositekey,key instead of two keys. This generally requires fewer changes to various components of PKI ecosystems, many of which are not prepared to deal with two keys or dual signatures. To those protocol- or application-layer parsers, a "composite" algorithm composed of two "component" algorithms is simply a new algorithm, and support for adding new algorithms generally already exists. Treating multiple "component" keys as a single "composite" key also has securityadvantagesadvantages, such as preventing cross-protocol reuse of the individual component keys and guarantees about revoking or retiring all component keys together at the same time, especially if the composite is treated as a single object all the way down into the cryptographic module.</t> <t>All that needs to be done is to standardize the formats of how the two keys from the two algorithms are combined into a single datastructure,structure and how the two resulting signatures or KEMs are combined into a single signature or KEM. The answer can be as simple asconcatenation,concatenation if the lengths are fixed or easily determined. At the time this document is published, security research is ongoing as to the security properties of concatenation-based composite signatures and KEMsvs.versus more sophisticated signature and KEMcombiners,combiners andin whichprotocol contexts in which those simpler combiners are sufficient.</t> <t>One last consideration is the specific pairs of algorithms that can be combined. A recent trend in protocols is to only allow a small number of "known good" configurations that make sense, often referred to in cryptography as a "ciphersuite", instead of allowing arbitrary combinations of individual configuration choices that may interact in dangerous ways. The current consensus is that the same approach should be followed for combining cryptographicalgorithms,algorithms and that "known good" pairs should be explicitly listed ("explicitcomposite"),composite") instead of just allowing arbitrary combinations of any two cryptographic algorithms ("generic composite").</t> <t>The same considerations apply when using multiple certificates to transport a pair of related keys for the same subject. Exactly how two certificates should be managed in order to avoid some of the pitfalls mentioned above is still an active area of investigation. Using two certificates keeps the certificate tooling simple and straightforward, but in theendend, this simply movestheproblems (i.e., problems withrequiringthe requirement that bothcerts are intended tocertificates be used as a pair,must producethat two signatureswhichthat must be carried separately, and that bothmust validate,validate) to the certificate management layer, where addressing these concerns in a robust way can be difficult.</t> <t>At least one scheme has been proposed that allows the pair of certificates to exist as a single certificate when being issued andmanaged,managed but dynamically split into individual certificates when needed(<xref target="I-D.draft-bonnell-lamps-chameleon-certs"/>).</t>(see <xref target="I-D.bonnell-lamps-chameleon-certs"/>).</t> </section> <section anchor="REUSE"> <name>Key Reuse in Hybrid Schemes</name> <t>An important security note, particularly when using hybrid signature keys, but also to a lesser extent hybrid KEM keys, is key reuse. In traditional cryptography, problems can occur with so-called "cross-protocol attacks" when the same key can be used for multiple protocols; forexampleexample, signing TLS handshakes and signing S/MIME emails. While it is notbest-practicebest practice to reuse keys within the same protocol,for examplee.g., using the same key for multiple S/MIME certificates for the same user, it is not generally catastrophic for security. However, key reuse becomes a large security problem withinhybrids.</t>hybrid schemes.</t> <t>Consider an {RSA, ML-DSA} hybrid key where the RSA key also appears within a single-algorithm certificate. In this case, an attacker could perform a "stripping attack" where they take some piece of data signed with the {RSA, ML-DSA} key, remove the ML-DSAsignaturesignature, and present the data as if it was intended for the RSA only certificate. This leads to a set of security definitions called "non-separability properties", which refers to how well the signature scheme resists various complexities ofdowngrade / strippingdowngrade/stripping attacks <xreftarget="I-D.draft-ietf-pquip-hybrid-signature-spectrums"/>.target="I-D.ietf-pquip-hybrid-signature-spectrums"/>. Therefore, it is recommended that implementers either reuse the entire hybrid key as awhole,whole or perform fresh key generation of all component keys per usage, and must not take an existing key and reuse it as a component of ahybrid.</t>hybrid key.</t> </section> <section anchor="future-directions-and-ongoing-research"> <name>Future Directions and Ongoing Research</name> <t>Many aspects of hybrid cryptography are still under investigation. The LAMPSWGWorking Group at IETF is actively exploring the security properties of these combinations, and future standards will reflect the evolving consensus on these issues.</t> </section> </section> </section> <section anchor="impact-on-constrained-devices-and-networks"> <name>Impact on Constrained Devices and Networks</name> <t>PQC algorithms generally have larger keys, ciphertext, and signature sizes than traditional public key algorithms. This has particular impact on constrained devices that operate with limited data rates. In the IoT space, these constraints have historically driven significant optimization efforts in the IETF (e.g.,LAKE, CoRE)in the LAKE and CoRE Working Groups) to adapt security protocols to resource-constrained environments.</t> <t>As the transition to PQC progresses, these environments will face similar challenges. Larger message sizes can increase handshake latency, raise energy consumption, and require fragmentation logic. Work is ongoing in the IETF to study how PQC can be deployed in constrained devices (see <xref target="I-D.ietf-pquip-pqc-hsm-constrained"/>).</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <section anchor="cryptanalysis"> <name>Cryptanalysis</name> <t>Traditional cryptanalysis exploits weaknesses in algorithm design, mathematical vulnerabilities, or implementationflaws,flaws that are exploitable with classical(i.e.(i.e., non-quantum) hardware, whereas quantum cryptanalysis harnesses the power of CRQCs to solve specific mathematical problems more efficiently.AnotherQuantum side-channel attacks are another form of quantumcryptanalysis is "quantum side-channel" attacks.cryptanalysis. In such attacks, a device under threat is directly connected to a quantum computer, which then injects entangled or superimposed data streams to exploit hardware that lacks protection against quantumside-channels.side channels. Both pose threats to the security of cryptographic algorithms, including those used in PQC.DevelopingIt is crucial to develop andadoptingadopt new cryptographic algorithms resilient against these threatsis crucial for ensuringto ensure long-term security in the face of advancing cryptanalysis techniques.</t> <t>Recent attacks on the side-channel implementations using deeplearning basedlearning-based power analysis have also shown that one needs to be cautious while implementing the required PQC algorithms in hardware. Two of the most recent works include one attack on ML-KEM <xref target="KyberSide"/> and one attack on Saber <xref target="SaberSide"/>. An evolving threat landscape points to the fact thatlattice basedlattice-based cryptography is indeed more vulnerable to side-channel attacks as in <xreftarget="SideCh"/>,target="SideCh"/> and <xref target="LatticeSide"/>. Consequently,there weresome mitigation techniques forside channelside-channel attacksthathave beenproposed as inproposed; see <xref target="Mitigate1"/>, <xref target="Mitigate2"/>, and <xref target="Mitigate3"/>.</t> </section> <section anchor="cryptographic-agility"> <name>Cryptographic Agility</name> <t>Cryptographic agility is recommended for both traditional and quantum cryptanalysis as it enables organizations to adapt to emerging threats, adopt stronger algorithms, comply with standards, and plan for long-term security in the face of evolving cryptanalytic techniques and the advent of CRQCs.</t> <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.ItThis is of paramount importance and is 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> <t>An important and often overlooked step in achieving cryptographic agility is maintaining a cryptographic inventory. Modern software stacks incorporate cryptography in numerous places, making it challenging to identify all instances. Therefore, cryptographic agility and inventory management take two majorforms:forms. First, application developers responsible for software maintenance should actively search for instances of hard-coded cryptographic algorithms within applications. When possible, they should design the choice of algorithm to be dynamic, based on application configuration. Second, administrators, policy officers, and compliance teams should take note of any instances where an application exposes cryptographic configurations. These instances should be managedeitherthrough either organization-wide written cryptographic policies or automated cryptographic policy systems.</t> <t>Numerous commercial solutions are available forbothdetecting hard-coded cryptographic algorithms in source code and compiled binaries, as well as providing cryptographic policy management control planes for enterprise and production environments.</t> </section> <section anchor="jurisdictional-fragmentation"> <name>Jurisdictional Fragmentation</name> <t>Another potential application ofhybridshybrid schemes bears mentioning, even though it is not directlyPQC-related. That isrelated to PQC: using hybrids to navigate inter-jurisdictional cryptographic connections. Traditional cryptography is already fragmented byjurisdiction: considerjurisdiction. Consider that while most jurisdictions supportElliptic Curve Diffie-Hellman,ECDH, those in the United States will prefer the NIST curves while those in Germany will prefer the Brainpool curves. China, Russia, and other jurisdictions have their own national cryptography standards. This situation of fragmented global cryptography standards is unlikely to improve with PQC. If "and" modehybridshybrid schemes become standardized for the reasons mentioned above, then one could imagine leveraging them to create"ciphersuites"ciphersuites in which a single cryptographic operation simultaneously satisfies the cryptographic requirements of both endpoints.</t> </section> <sectionanchor="hybrid-key-exchange-and-signatures-bridging-the-gap-between-post-quantum-and-traditional-cryptography">anchor="hybrid-key-exchange-and-signatures-bridging-the-gap-between-pqt-cryptography"> <name>Hybrid Key Exchange and Signatures: Bridging the Gap BetweenPost-Quantum and TraditionalPQ/T Cryptography</name> <t>Post-quantum algorithms selected for standardization are relatively new andtheyhave not been subject to the same depth of study as traditional algorithms. PQC implementations will also be new and therefore more likely to contain implementation bugs than the battle-tested crypto implementations that are relied on today. In addition, certain deployments may need to retain traditional algorithms due to regulatory constraints,for examplee.g., FIPS <xref target="SP-800-56C"/> orPCIPayment Card Industry (PCI) compliance <xref target="PCI"/>. Hybrid key exchange is recommended to enhance security against the"harvest now, decrypt later"HNDL attack. Additionally, hybrid signatures provide for time to react in the case of the announcement of a devastating attack against any one algorithm, while not fully abandoning traditional cryptosystems.</t> <t>Hybrid key exchange performs both a classical and a post-quantum key exchange in parallel. It provides security redundancy against potential weaknesses in PQC algorithms, allows for a gradual transition of trust in PQC algorithms, and, in backward-compatible designs, enables gradual adoption without breaking compatibility with existing systems. For instance, in TLS 1.3, a hybrid key exchange can combine a widely supported classical algorithm, such as X25519, with a post-quantum algorithm like ML-KEM. This allows legacy clients to continue using the classical algorithm while enabling upgraded clients to proceed with hybrid key exchange. In contrast, overhead-spreading hybrid designs focus on reducing the PQ overhead. For example, approaches like those described in <xref target="I-D.hale-mls-combiner"/> amortize PQ costs by selectively applying PQ updates in key exchange processes, allowing systems to balance security and efficiency. This strategy ensures a post-quantum secure channel while keeping the overhead manageable, making it particularly suitable for constrained environments.</t> <t>While some hybrid key exchange options introduce additional computational and bandwidth overhead, the impact of traditional key exchange algorithms (e.g., key size) is typically small, helping to keep the overall increase in resource usage manageable for most systems. In highly constrained environments, however, those hybrid key exchange protocols may be impractical due to their higher resource requirements compared to pure post-quantum or traditional key exchange approaches. However, some hybrid key exchange designs distribute the PQC overhead, making them more suitable for constrained environments. The choice of hybrid key exchange design depends on the specific system requirements and use case, so the appropriate approach may vary.</t> </section> <section anchor="caution-ciphertext-commitment-in-kem-vs-dh"> <name>Caution: CiphertextcommitmentCommitment in KEM vs. DH</name> <t>The ciphertext generated by a KEM is not necessarily directly linked to the shared secret it produces. KEMs allow for multiple ciphertexts to encapsulate the same shared secret, which enables flexibility in key management without enforcing a strict one-to-one correspondence between ciphertexts and shared secrets. This allows for secret reuse across different recipients, sessions, or operational contexts without the need for new secrets for each use, simplifying key distribution and reducing computational overhead. In contrast, cryptographic schemes like Diffie-Hellman inherently link the public key to the derived shared secret, meaning any change in the public key results in a different shared secret.</t> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANAconsiderations.</t>actions.</t> </section> <sectionanchor="further-reading-resources">anchor="further-reading-and-resources"> <name>Further Reading&and Resources</name> <t>A good book on modern cryptography isSerious"Serious Cryptography, 2ndEdition,Edition" by Jean-PhilippeAumasson, ISBN 9781718503847.</t>Aumasson <xref target="Serious-Crypt"/>.</t> <t>The Open Quantum Safe (OQS) Project <xref target="OQS"/> is an open-source project that aims to support the transition to quantum-resistant cryptography.</t> <t>The IETF's PQUIP Working Group <xref target="PQUIP-WG"/> maintains a list of PQC-related protocol work within the IETF.</t> </section> </middle> <back> <displayreference target="I-D.bonnell-lamps-chameleon-certs" to="ENC-PAIR-CERTS"/> <displayreference target="I-D.connolly-cfrg-xwing-kem" to="X-WING"/> <displayreference target="I-D.hale-mls-combiner" to="PQ-MLS"/> <displayreference target="I-D.ietf-hpke-pq" to="PQ-HPKE"/> <displayreference target="I-D.ietf-lamps-pq-composite-sigs" to="ML-DSA-X.509"/> <displayreference target="I-D.ietf-pquip-hybrid-signature-spectrums" to="HYBRID-SIG-SPECT"/> <displayreference target="I-D.ietf-pquip-pqc-hsm-constrained" to="CONSTRAIN-DEV-PCQ"/> <displayreference target="I-D.ietf-tls-hybrid-design" to="TLS-HYB-KEY-EXCH"/> <displayreference target="I-D.irtf-cfrg-bbs-signatures" to="BBS-SIG-SCHEME"/> <displayreference target="I-D.irtf-cfrg-hybrid-kems" to="PQ-KEM"/> <displayreference target="I-D.ounsworth-cfrg-kem-combiners" to="KEM-COMBINER"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <reference anchor="ML-KEM" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf"> <front><title>FIPS-203: Module-Lattice-based<title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title> <author><organization/><organization>NIST</organization> </author><date/><date year="2024" month="August"/> </front> <seriesInfo name="NIST FIPS" value="203"/> <seriesInfo name="DOI" value="10.6028/nist.fips.203"/> </reference> <reference anchor="ML-DSA" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf"> <front><title>FIPS-204: Module-Lattice-Based<title>Module-Lattice-Based Digital Signature Standard</title> <author><organization/><organization>NIST</organization> </author><date/><date year="2024" month="August"/> </front> <seriesInfo name="NIST FIPS" value="204"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.204"/> </reference> <reference anchor="SLH-DSA" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf"> <front><title>FIPS-205: Stateless<title>Stateless Hash-Based Digital Signature Standard</title> <author><organization/><organization>NIST</organization> </author><date/><date year="2024" month="August"/> </front> <seriesInfo name="NIST FIPS" value="205"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.205"/> </reference> <reference anchor="Shors" target="https://arxiv.org/pdf/quant-ph/9508027"> <front><title>Polynomial-time algorithms<title>Polynomial-Time Algorithms forprime factorizationPrime Factorization anddiscrete logarithmsDiscrete Logarithms on aquantum computer</title> <author>Quantum Computer</title> <author initials="P." surname="Shor" fullname="Peter W. Shor"> <organization/> </author><date>n.d.</date><date year="1996" month="January" day="25"/> </front> <refcontent>arXiv:quant-ph/9508027v2</refcontent> </reference> <reference anchor="Grovers" target="https://dl.acm.org/doi/10.1145/237814.237866"> <front> <title>A fast quantum mechanical algorithm for database search</title><author><author fullname="Lok K. Grover"> <organization/> </author><date>n.d.</date><date year="1996" month="July" day="01"/> </front> <seriesInfo name="DOI" value="10.1145/237814.237866"/> <refcontent>STOC '96: Proceedings of the twenty-eighth annual ACM symposium on Theory of Computing, pp. 212-219</refcontent> </reference> <reference anchor="RSA" target="https://dl.acm.org/doi/pdf/10.1145/359340.359342"> <front> <title>A Method for Obtaining Digital Signatures and Public-KeyCryptosystems+</title> <author>Cryptosystems</title> <author fullname="Ronald L. Rivest"> <organization/> </author><date/> </front> </reference> <reference anchor="RFC6090"> <front> <title>Fundamental Elliptic Curve Cryptography Algorithms</title> <author fullname="D. McGrew" initials="D." surname="McGrew"/> <author fullname="K. Igoe" initials="K." surname="Igoe"/> <author fullname="M. Salter" initials="M." surname="Salter"/> <date month="February" year="2011"/> <abstract> <t>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6090"/> <seriesInfo name="DOI" value="10.17487/RFC6090"/> </reference> <reference anchor="RFC8391"> <front> <title>XMSS: eXtended Merkle Signature Scheme</title><authorfullname="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> <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="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>surname="Shamir"> <organization/> </author> <authorfullname="E. Rescorla" initials="E." surname="Rescorla"/>initials="L." surname="Adleman"> <organization/> </author> <datemonth="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract>year="1978" month="February"/> </front> <seriesInfoname="RFC" value="8446"/> <seriesInfoname="DOI"value="10.17487/RFC8446"/> </reference> <reference anchor="RFC4034"> <front> <title>Resource Records for the DNS Security Extensions</title> <author fullname="R. Arends" initials="R." surname="Arends"/> <author fullname="R. Austein" initials="R." surname="Austein"/> <author fullname="M. Larson" initials="M." surname="Larson"/> <author fullname="D. Massey" initials="D." surname="Massey"/> <author fullname="S. Rose" initials="S." surname="Rose"/> <date month="March" year="2005"/> <abstract> <t>This document is partvalue="10.1145/359340.359342"/> <refcontent>Communications ofa family of documents that describetheDNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t> <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4034"/> <seriesInfo name="DOI" value="10.17487/RFC4034"/>ACM, vol. 21, no. 2, pp. 120-126</refcontent> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6090.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8391.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8554.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/> <reference anchor="NTRU" target="https://ntru.org/index.shtml"> <front> <title>NTRU</title> <author> <organization/> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="FrodoKEM" target="https://frodokem.org/"> <front> <title>FrodoKEM</title> <author> <organization/> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="ClassicMcEliece" target="https://classic.mceliece.org/"> <front> <title>Classic McEliece</title> <author> <organization/> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="FN-DSA" target="https://falcon-sign.info/"> <front><title>Fast<title>FALCON: Fast Fourier lattice-based compact signatures over NTRU</title> <author> <organization/> </author> <date/> </front> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8235.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9180.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9881.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9242.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9370.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <referenceanchor="RFC8235"> <front> <title>Schnorr Non-interactive Zero-Knowledge Proof</title> <author fullname="F. Hao" initials="F." role="editor" surname="Hao"/> <date month="September" year="2017"/> <abstract> <t>This document describes the Schnorr non-interactive zero-knowledge (NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings.</t> </abstract> </front> <seriesInfo name="RFC" value="8235"/> <seriesInfo name="DOI" value="10.17487/RFC8235"/> </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.ietf-lamps-dilithium-certificates">anchor="Serious-Crypt"> <front><title>Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)</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><title>Serious Cryptography, 2nd Edition</title> <authorfullname="Bas Westerbaan" initials="B." surname="Westerbaan"> <organization>Cloudflare</organization>fullname="Jean-Philippe Aumasson"> <organization/> </author> <dateday="26" month="June" year="2025"/> <abstract> <t> Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. </t> </abstract>year="2024" month="August"/> </front><seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-certificates-12"/><refcontent>ISBN 9781718503847</refcontent> </reference> <referenceanchor="RFC9242">anchor="Grover-Search" target="https://link.aps.org/doi/10.1103/PhysRevA.60.2746"> <front><title>Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)</title> <author fullname="V. Smyslov" initials="V." surname="Smyslov"/> <date month="May" year="2022"/> <abstract> <t>This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA<title>Grover's quantum searching algorithm isestablished.</t> </abstract> </front> <seriesInfo name="RFC" value="9242"/> <seriesInfo name="DOI" value="10.17487/RFC9242"/> </reference> <reference anchor="RFC9370"> <front> <title>Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)</title> <author fullname="CJ. Tjhai" initials="CJ." surname="Tjhai"/>optimal</title> <authorfullname="M. Tomlinson" initials="M." surname="Tomlinson"/> <author fullname="G. Bartlett" initials="G." surname="Bartlett"/> <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/> <author fullname="D. Van Geest" initials="D." surname="Van Geest"/> <author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon"/> <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>fullname="Christof Zalka"> <organization/> </author> <datemonth="May" year="2023"/> <abstract> <t>This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.</t> <t>This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.</t> <t>This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.</t> </abstract>year="1999" month="October"/> </front> <seriesInfoname="RFC" value="9370"/> <seriesInfoname="DOI"value="10.17487/RFC9370"/> </reference> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="Grover-search"> <front> <title>C. Zalka, “Grover’s quantum searching algorithm is optimal,” Physicalvalue="10.1103/PhysRevA.60.2746"/> <refcontent>Physical Review A, vol. 60, no. 4, pp.2746-2751, 1999.</title> <author> <organization/> </author> <date/> </front>2746-2751</refcontent> </reference> <reference anchor="Threat-Report" target="https://globalriskinstitute.org/publications/quantum-threat-timeline-report-2020/"> <front> <title>Quantum Threat Timeline Report 2020</title><author><author fullname="Michele Mosca"> <organization/> </author><date/><author fullname="Marco Piani"> <organization/> </author> <date year="2021" month="January" day="27"/> </front> <refcontent>Global Risk Institute</refcontent> </reference> <reference anchor="QC-DNS" target="https://www.icann.org/octo-031-en.pdf"> <front> <title>Quantum Computing and the DNS</title><author><author fullname="Paul Hoffman"> <organization/> </author><date/><date year="2024" month="April" day="22"/> </front> <refcontent>ICANN Office of the Chief Technology Officer, OCTO-031v2</refcontent> </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/><organization>NIST</organization> </author> <date/> </front> </reference> <reference anchor="Cloudflare" target="https://blog.cloudflare.com/nist-post-quantum-surprise/"> <front><title>NIST’s<title>NIST's pleasant post-quantum surprise</title><author><author fullname="Bas Westerbaan"> <organization/> </author><date/><date year="2022" month="July" day="08"/> </front> <refcontent>Cloudflare Blog</refcontent> </reference> <reference anchor="CS01" target="https://eprint.iacr.org/2001/108"> <front> <title>Design and Analysis of Practical Public-Key Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack</title><author><author fullname="Ronald Cramer"> <organization/> </author><date/><author fullname="Victor Shoup"> <organization/> </author> <date year="2001"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2001/108</refcontent> </reference> <reference anchor="BHK09" target="https://eprint.iacr.org/2009/418"> <front> <title>Subtleties in the Definition of IND-CCA: When and How Should Challenge-Decryption be Disallowed?</title><author><author fullname="Mihir Bellare"> <organization/> </author><date/><author fullname="Dennis Hofheinz"> <organization/> </author> <author fullname="Eike Kiltz"> <organization/> </author> <date year="2009"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2009/418</refcontent> </reference> <reference anchor="GMR88" target="https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Digital%20Signatures/A_Digital_Signature_Scheme_Secure_Against_Adaptive_Chosen-Message_Attack.pdf"> <front> <title>A digital signature scheme secure against adaptive chosen-messageattacks.</title> <author>attacks</title> <author fullname="Shafi Goldwasser"> <organization/> </author><date/><author fullname="Silvio Micali"> <organization/> </author> <author fullname="Ronald L. Rivest"> <organization/> </author> <date year="1988" month="April"/> </front> <seriesInfo name="DOI" value="10.1137/0217017"/> <refcontent>SIAM Journal on Computing, vol. 17, no. 2, pp. 281-308</refcontent> </reference> <reference anchor="PQCAPI" target="https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf"> <front> <title>PQC - API notes</title> <author><organization/><organization>NIST</organization> </author> <date/> </front> </reference> <reference anchor="RSA8HRS" target="https://arxiv.org/abs/1905.09749"> <front> <title>How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits</title><author><author fullname="Craig Gidney"> <organization/> </author><date/><author fullname="Martin Ekera"> <organization/> </author> <date year="2021" month="April" day="13"/> </front> <refcontent>arXiv:1905.09749v3</refcontent> </reference> <reference anchor="RSA10SC" target="https://www.quintessencelabs.com/blog/breaking-rsa-encryption-update-state-art"> <front> <title>Breaking RSA Encryption - an Update on the State-of-the-Art</title> <author><organization/><organization>QuintessenceLabs</organization> </author><date/><date year="2019" month="June" day="13"/> </front> </reference> <reference anchor="RSAShor" target="https://arxiv.org/pdf/quant-ph/0205095.pdf"> <front> <title>Circuit forShor’sShor's algorithm using 2n+3 qubits</title><author><author fullname="Stephane Beauregard"> <organization/> </author><date/><date year="2003" month="February" day="21"/> </front> <refcontent>arXiv:quant-ph/0205095v3</refcontent> </reference> <reference anchor="LIBOQS" target="https://github.com/open-quantum-safe/liboqs"> <front> <title>LibOQS - Open Quantum Safe</title> <author> <organization/> </author><date/><date year="2025" month="November"/> </front> <refcontent>commit 97f6b86</refcontent> </reference> <reference anchor="KyberSide" target="https://eprint.iacr.org/2022/1452"> <front> <title>A Side-Channel Attack on a Hardware Implementation of CRYSTALS-Kyber</title><author><author fullname="Yanning Ji"> <organization/> </author><date/><author fullname="Ruize Wang"> <organization/> </author> <author fullname="Kalle Ngo"> <organization/> </author> <author fullname="Elena Dubrova"> <organization/> </author> <author fullname="Linus Backlund"> <organization/> </author> <date year="2022"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2022/1452</refcontent> </reference> <reference anchor="SaberSide" target="https://link.springer.com/article/10.1007/s13389-023-00315-3"> <front> <title>A side-channel attack on a masked and shuffled software implementation of Saber</title><author><author fullname="Kalle Ngo"> <organization/> </author><date/><author fullname="Elena Dubrova"> <organization/> </author> <author fullname="Thomas Johansson"> <organization/> </author> <date year="2023" month="April" day="25"/> </front> <seriesInfo name="DOI" value="10.1007/s13389-023-00315-3"/> <refcontent>Journal of Cryptographic Engineering, vol. 13, pp. 443-460</refcontent> </reference> <reference anchor="SideCh" target="https://eprint.iacr.org/2022/919"> <front> <title>Side-Channel Attacks on Lattice-Based KEMs Are Not Prevented by Higher-Order Masking</title><author><author fullname="Kalle Ngo"> <organization/> </author><date/><author fullname="Ruize Wang"> <organization/> </author> <author fullname="Elena Dubrova"> <organization/> </author> <author fullname="Nils Paulsrud"> <organization/> </author> <date year="2022"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2022/919</refcontent> </reference> <reference anchor="LatticeSide" target="https://eprint.iacr.org/2019/948"> <front> <title>Generic Side-channel attacks on CCA-secure lattice-based PKE and KEM schemes</title><author><author fullname="Prasanna Ravi"> <organization/> </author><date/><author fullname="Sujoy Sinha Roy"> <organization/> </author> <author fullname="Anupam Chattopadhyay"> <organization/> </author> <author fullname="Shivam Bhasin"> <organization/> </author> <date year="2019"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2019/948</refcontent> </reference> <reference anchor="Mitigate1" target="https://eprint.iacr.org/2022/873"> <front> <title>POLKA: Towards Leakage-Resistant Post-Quantum CCA-Secure Public Key Encryption</title><author><author fullname="Clément Hoffmann"> <organization/> </author><date/><author fullname="Benoît Libert"> <organization/> </author> <author fullname="Charles Momin"> <organization/> </author> <author fullname="Thomas Peters"> <organization/> </author> <author fullname="François-Xavier Standaert"> <organization/> </author> <date year="2022"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2022/873</refcontent> </reference> <reference anchor="Mitigate2" target="https://ieeexplore.ieee.org/document/9855226"> <front> <title>Leakage-Resilient Certificate-Based Authenticated Key Exchange Protocol</title><author><author initials="T." surname="Tsai"> <organization/> </author><date/><author initials="S." surname="Huang"> <organization/> </author> <author initials="Y." surname="Tseng"> <organization/> </author> <author initials="Y." surname="Chuang"> <organization/> </author> <author initials="Y." surname="Hung"> <organization/> </author> <date year="2022"/> </front> <seriesInfo name="DOI" value="10.1109/OJCS.2022.3198073"/> <refcontent>IEEE Open Journal of the Computer Society, vol. 3, pp. 137-148</refcontent> </reference> <reference anchor="Mitigate3" target="https://eprint.iacr.org/2022/916"> <front> <title>Post-Quantum Authenticated Encryption against Chosen-Ciphertext Side-Channel Attacks</title><author><author fullname="Melissa Azouaoui"> <organization/> </author><date/><author fullname="Yulia Kuzovkova"> <organization/> </author> <author fullname="Tobias Schneider"> <organization/> </author> <author fullname="Christine van Vredendaal"> <organization/> </author> <date year="2022"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2022/916</refcontent> </reference> <reference anchor="CNSA2-0" target="https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF"> <front> <title>Announcing the Commercial National Security Algorithm Suite 2.0</title> <author><organization/><organization>NSA</organization> </author><date/><date year="2022" month="September"/> </front> </reference> <reference anchor="LattFail1"target="https://link.springer.com/chapter/10.1007/978-3-030-17259-6_19#chapter-info">target="https://link.springer.com/chapter/10.1007/978-3-030-17259-6_19"> <front> <title>Decryption Failure Attacks on IND-CCA Secure Lattice-Based Schemes</title><author><author fullname="Jan-Pieter D'Anvers"> <organization/> </author><date/><author fullname="Qian Guo"> <organization/> </author> <author fullname="Thomas Johansson"> <organization/> </author> <author fullname="Alexander Nilsson"> <organization/> </author> <author fullname="Frederik Vercauteren"> <organization/> </author> <author fullname="Ingrid Verbauwhede"> <organization/> </author> <date year="2019" month="April" day="06"/> </front> <seriesInfo name="DOI" value="10.1007/978-3-030-17259-6_19"/> <refcontent>Public-Key Cryptography - PKC 2019, Lecture Notes in Computer Science, vol. 11443, pp. 565-598</refcontent> </reference> <reference anchor="LattFail2" target="https://link.springer.com/chapter/10.1007/978-3-030-45727-3_1"> <front> <title>(One) Failure Is Not an Option: Bootstrapping the Search for Failures in Lattice-Based EncryptionSchemes.</title> <author>Schemes</title> <author fullname="Jan-Pieter D'Anvers"> <organization/> </author><date/><author fullname="Mélissa Rossi"> <organization/> </author> <author fullname="Fernando Virdia"> <organization/> </author> <date year="2020" month="May" day="01"/> </front> <seriesInfo name="DOI" value="10.1007/978-3-030-45727-3_1"/> <refcontent>Advances in Cryptology - EUROCRYPT 2020, Lecture Notes in Computer Science, vol. 12107, pp. 3-33</refcontent> </reference> <reference anchor="BSI-PQC" target="https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=916626"> <front> <title>Quantum-safe cryptography–- fundamentals, current developments and recommendations</title> <author><organization/><organization>BSI</organization> </author> <date year="2022"month="May"/>month="May" day="18"/> </front> </reference> <reference anchor="PQRSA" target="https://cr.yp.to/papers/pqrsa-20170419.pdf"> <front> <title>Post-quantum RSA</title><author><author fullname="Daniel J. Bernstein"> <organization/> </author> <author fullname="Nadia Heninger"> <organization/> </author> <author fullname="Paul Lou"> <organization/> </author> <author fullname="Luke Valenta"> <organization/> </author> <date year="2017"month="April"/>month="April" day="19"/> </front> </reference> <reference anchor="SP-800-56C" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf"> <front> <title>Recommendation for Key-Derivation Methods in Key-Establishment Schemes</title><author><author fullname="Elaine Barker"> <organization/> </author><date/><author fullname="Lily Chen"> <organization/> </author> <author fullname="Richard Davis"> <organization/> </author> <date year="2020" month="August"/> </front> <seriesInfo name="NIST SP" value="800-56Cr2"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Cr2"/> </reference> <reference anchor="Lyu09" target="https://www.iacr.org/archive/asiacrypt2009/59120596/59120596.pdf"> <front><title>V. Lyubashevsky, “Fiat-Shamir<title>Fiat-Shamir With Aborts: Applications to Lattice and Factoring-BasedSignatures“, ASIACRYPT 2009</title> <author>Signatures</title> <author fullname="Vadim Lyubashevsky"> <organization/> </author> <date/> </front> <refcontent>ASIACRYPT 2009</refcontent> </reference> <reference anchor="SP-1800-38C" target="https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf"> <front> <title>Migration to Post-Quantum Cryptography Quantum Readiness: Testing Draft Standards, Volume C: Quantum-Resistant Cryptography Technology Interoperability and Performance Report</title><author><author fullname="William Newhouse"> <organization/> </author><date/><author fullname="Murugiah Souppaya"> <organization/> </author> <author fullname="William Barke"> <organization/> </author> <author fullname="Chris Brown"> <organization/> </author> <author fullname="Panos Kampanakis"> <organization/> </author> <author fullname="Jim Goodman"> <organization/> </author> <author fullname="Julien Prat"> <organization/> </author> <author fullname="Robin Larrieu"> <organization/> </author> <author fullname="John Gray"> <organization/> </author> <author fullname="Mike Ounsworth"> <organization/> </author> <author fullname="Cleandro Viana"> <organization/> </author> <author fullname="Hubert Le Van Gong"> <organization/> </author> <author fullname="Kris Kwiatkowsk"> <organization/> </author> <author fullname="Anthony Hu"> <organization/> </author> <author fullname="Robert Burns"> <organization/> </author> <author fullname="Christian Paquin"> <organization/> </author> <author fullname="Jane Gilbert"> <organization/> </author> <author fullname="Gina Scinta"> <organization/> </author> <author fullname="Eunkyung Kim"> <organization/> </author> <author fullname="Volker Krumme"> <organization/> </author> <date year="2023" month="December"/> </front> <seriesInfo name="NIST SP" value="1800-38C"/> <refcontent>Preliminary Draft</refcontent> </reference> <reference anchor="KEEPINGUP" target="https://eprint.iacr.org/2023/1933"> <front> <title>Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols</title><author><author fullname="Cas Cremers"> <organization/> </author><date>n.d.</date><author fullname="Alexander Dax"> <organization/> </author> <author fullname="Niklas Medinger"> <organization/> </author> <date year="2023"/> </front> <refcontent>Cryptology ePrint Archive, Paper 2023/1933</refcontent> </reference> <reference anchor="NISTFINAL" target="https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards"> <front> <title>NIST Releases First 3 Finalized Post-Quantum Encryption Standards</title> <author><organization/><organization>NIST</organization> </author><date>n.d.</date><date year="2024" month="August" day="13"/> </front> </reference> <reference anchor="ANSSI" target="https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf"> <front> <title>ANSSI views on the Post-Quantum Cryptographytransition</title>transition (2023 follow up)</title> <author><organization/><organization>ANSSI</organization> </author><date>n.d.</date><date year="2023" month="December" day="21"/> </front> </reference> <reference anchor="HQC" target="http://pqc-hqc.org/"> <front> <title>HQC</title> <author> <organization/> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="BIKE"target="http://pqc-hqc.org/">target="https://bikesuite.org/"> <front> <title>BIKE</title> <author> <organization/> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="PQUIP-WG" target="https://datatracker.ietf.org/group/pquip/documents/"> <front> <title>Post-Quantum Use In Protocols(pquip) Working Group</title>(pquip)</title> <author><organization/><organization>IETF</organization> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="OQS" target="https://openquantumsafe.org/"> <front> <title>Open Quantum Safe Project</title> <author> <organization/> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="CRQCThreat" target="https://sam-jaques.appspot.com/quantum_landscape_2024"> <front><title>CRQCThreat</title> <author><title>Landscape of Quantum Computing</title> <author fullname="Sam Jaques"> <organization/> </author><date>n.d.</date><date/> </front> </reference> <reference anchor="QuantSide" target="https://arxiv.org/pdf/2304.03315"> <front><title>QuantSide</title> <author> <organization/> </author> <date>n.d.</date> </front> </reference> <reference anchor="AddSig" target="https://csrc.nist.gov/Projects/pqc-dig-sig/standardization"> <front> <title>AddSig</title> <author> <organization/> </author> <date>n.d.</date> </front> </reference> <reference anchor="BPQS" target="https://eprint.iacr.org/2018/658.pdf"> <front> <title>BPQS</title> <author> <organization/> </author> <date>n.d.</date> </front> </reference> <reference anchor="PCI" target="https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf"> <front> <title>Payment Card Industry Data Security Standard</title> <author> <organization/> </author> <date>n.d.</date> </front> </reference> <reference anchor="I-D.irtf-cfrg-bbs-signatures"> <front> <title>The BBS Signature Scheme</title> <author fullname="Tobias Looker" initials="T." surname="Looker"> <organization>MATTR</organization> </author> <author fullname="Vasilis Kalos" initials="V." surname="Kalos"> <organization>MATTR</organization> </author> <author fullname="Andrew Whitehead" initials="A." surname="Whitehead"> <organization>Portage</organization> </author> <author fullname="Mike Lodder" initials="M." surname="Lodder"> <organization>CryptID</organization> </author> <date day="7" month="July" year="2025"/> <abstract> <t> This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-bbs-signatures-09"/> </reference> <reference anchor="I-D.ietf-sshm-ntruprime-ssh"> <front> <title>Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512</title> <author fullname="Markus Friedl" initials="M." surname="Friedl"> <organization>OpenSSH</organization> </author> <author fullname="Jan Mojzis" initials="J." surname="Mojzis"> <organization>TinySSH</organization> </author> <author fullname="Simon Josefsson" initials="S." surname="Josefsson"> </author> <date day="15" month="August" year="2025"/> <abstract> <t> This document describes a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-sshm-ntruprime-ssh-05"/> </reference> <reference anchor="RFC9528"> <front> <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title> <author fullname="G. Selander" initials="G." surname="Selander"/> <author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/> <author fullname="F. Palombini" initials="F." surname="Palombini"/> <date month="March" year="2024"/> <abstract> <t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low.</t> </abstract> </front> <seriesInfo name="RFC" value="9528"/> <seriesInfo name="DOI" value="10.17487/RFC9528"/> </reference> <reference anchor="I-D.draft-ounsworth-cfrg-kem-combiners"> <front> <title>Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs)</title> <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth"> <organization>Entrust Limited</organization> </author> <author fullname="Aron Wussler" initials="A." surname="Wussler"> <organization>Proton AG</organization> </author> <author fullname="Stavros Kousidis" initials="S." surname="Kousidis"> <organization>BSI</organization> </author> <date day="31" month="January" year="2024"/> <abstract> <t> The migration to post-quantum cryptography often calls for performing multiple key encapsulations in parallel and then combining their outputs to derive a single shared secret. This document defines a comprehensible and easy to implement Keccak- based KEM combiner to join an arbitrary number<title>Exploration ofkey shares, that is compatible with NIST SP 800-56Cr2 [SP800-56C] when viewed as a key derivation function. The combiners defined here are practical split- key PRFs and are CCA-secure as long as at least one of the ingredient KEMs is. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ounsworth-cfrg-kem-combiners-05"/> </reference> <reference anchor="I-D.irtf-cfrg-hybrid-kems"> <front> <title>Hybrid PQ/T Key Encapsulation Mechanisms</title>Quantum Computer Power Side-Channels</title> <authorfullname="Deirdre Connolly" initials="D." surname="Connolly"> <organization>SandboxAQ</organization>fullname="Chuanqi Xu"> <organization/> </author> <authorfullname="Richard Barnes" initials="R." surname="Barnes"> <organization>Cisco</organization>fullname="Ferhat Erata"> <organization/> </author> <authorfullname="Paul Grubbs" initials="P." surname="Grubbs"> <organization>University of Michigan</organization>fullname="Jakub Szefer"> <organization/> </author> <dateday="20" month="July" year="2025"/> <abstract> <t> This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a traditional cryptographic component and a post-quantum (PQ) KEM. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. </t> </abstract>year="2023" month="May" day="09"/> </front><seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-hybrid-kems-05"/><refcontent>arXiv:2304.03315v2</refcontent> </reference> <referenceanchor="I-D.ietf-hpke-pq">anchor="AddSig" target="https://csrc.nist.gov/Projects/pqc-dig-sig/standardization"> <front> <title>Post-Quantumand Post-Quantum/Traditional Hybrid Algorithms for HPKE</title> <author fullname="Richard Barnes" initials="R." surname="Barnes"> <organization>Cisco</organization> </author> <date day="30" month="June" year="2025"/> <abstract> <t> Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-hpke-pq-01"/> </reference> <reference anchor="I-D.draft-connolly-cfrg-xwing-kem"> <front> <title>X-Wing: general-purpose hybrid post-quantum KEM</title> <author fullname="Deirdre Connolly" initials="D." surname="Connolly"> <organization>SandboxAQ</organization> </author> <author fullname="Peter Schwabe" initials="P." surname="Schwabe"> <organization>MPI-SP & Radboud University</organization> </author> <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan"> <organization>Cloudflare</organization> </author> <date day="7" month="July" year="2025"/> <abstract> <t> This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-connolly-cfrg-xwing-kem-08"/> </reference> <reference anchor="RFC5652"> <front> <title>Cryptographic Message Syntax (CMS)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="September" year="2009"/> <abstract> <t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="70"/> <seriesInfo name="RFC" value="5652"/> <seriesInfo name="DOI" value="10.17487/RFC5652"/> </reference> <reference anchor="I-D.ietf-lamps-cms-sphincs-plus"> <front> <title>Use of the SLH-DSACryptography: Additional Digital SignatureAlgorithm 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="13" month="January" year="2025"/> <abstract> <t> SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA 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-19"/> </reference> <reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology"> <front> <title>Terminology for Post-Quantum Traditional HybridSchemes</title><author fullname="Flo D" initials="F." surname="D"> <organization>UK National Cyber Security Centre</organization> </author> <author fullname="Michael P" initials="M." surname="P"> <organization>UK National Cyber Security Centre</organization> </author> <author fullname="Britta Hale" initials="B." surname="Hale"> <organization>Naval Postgraduate School</organization><author> <organization>NIST</organization> </author><date day="10" month="January" 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><date/> </front><seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-06"/></reference> <referenceanchor="I-D.ietf-tls-hybrid-design">anchor="BPQS" target="https://eprint.iacr.org/2018/658"> <front><title>Hybrid key exchange in TLS 1.3</title> <author fullname="Douglas Stebila" initials="D." surname="Stebila"> <organization>University of Waterloo</organization> </author><title>Blockchained Post-Quantum Signatures</title> <authorfullname="Scott Fluhrer" initials="S." surname="Fluhrer"> <organization>Cisco Systems</organization>fullname="Konstantinos Chalkias"> <organization/> </author> <authorfullname="Shay Gueron" initials="S." surname="Gueron"> <organization>University of Haifa and Meta</organization>fullname="James Brown"> <organization/> </author><date day="21" month="July" year="2025"/> <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 a way is found to defeat the encryption for all but one of the component algorithms. 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. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-14"/> </reference> <reference anchor="I-D.ietf-lamps-pq-composite-sigs"> <front> <title>Composite ML-DSA for use in X.509 Public Key Infrastructure</title><author fullname="MikeOunsworth" initials="M." surname="Ounsworth"> <organization>Entrust Limited</organization> </author> <author fullname="John Gray" initials="J." surname="Gray"> <organization>Entrust Limited</organization>Hearn"> <organization/> </author> <authorfullname="Massimiliano Pala" initials="M." surname="Pala"> <organization>OpenCA Labs</organization>fullname="Tommy Lillehagen"> <organization/> </author> <authorfullname="Jan Klaußner" initials="J." surname="Klaußner"> <organization>Bundesdruckerei GmbH</organization>fullname="Igor Nitto"> <organization/> </author> <authorfullname="Scott Fluhrer" initials="S." surname="Fluhrer"> <organization>Cisco Systems</organization>fullname="Thomas Schroeter"> <organization/> </author><date day="7" month="July" year="2025"/> <abstract> <t> This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-DSA is applicable in any application that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. </t> </abstract><date>n.d.</date> </front><seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-07"/><refcontent>Cryptology ePrint Archive, Paper 2018/658</refcontent> </reference> <referenceanchor="I-D.ietf-lamps-cert-binding-for-multi-auth">anchor="PCI" target="https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf"> <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<title>Payment Card Industry Data SecurityAgency</organization> </author> <author fullname="Michael J. Jenkins" initials="M. J." surname="Jenkins"> <organization>NationalStandard</title> <author> <organization>PCI SecurityAgency</organization>Standards Council</organization> </author><date day="10" month="December" year="2024"/> <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><date/> </front><seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-multi-auth-06"/><refcontent>PCI DSS: v4.0.1</refcontent> </reference><reference anchor="I-D.draft-bonnell-lamps-chameleon-certs"> <front> <title>A Mechanism for Encoding Differences in Paired Certificates</title> <author fullname="Corey Bonnell" initials="C." surname="Bonnell"> <organization>DigiCert</organization> </author> <author fullname="John Gray" initials="J." surname="Gray"> <organization>Entrust</organization> </author> <author fullname="D. Hook" initials="D." surname="Hook"> <organization>KeyFactor</organization> </author> <author fullname="Tomofumi Okubo" initials="T." surname="Okubo"> <organization>DigiCert</organization> </author> <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth"> <organization>Entrust</organization> </author> <date day="16" month="April" year="2025"/> <abstract> <t> This document specifies a method to efficiently convey the differences between two certificates in an X.509<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bonnell-lamps-chameleon-certs.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.connolly-cfrg-xwing-kem.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hale-mls-combiner.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-hpke-pq.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lamps-pq-composite-sigs.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pquip-hybrid-signature-spectrums.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pquip-pqc-hsm-constrained.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-hybrid-design.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-bbs-signatures.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-hybrid-kems.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ounsworth-cfrg-kem-combiners.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9941.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9528.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9814.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9794.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9763.xml"/> </references> </references> <?line 1459?> <!-- [rfced] References a) Update -01 version3 extension. This method allows a relying party to extract information sufficient to reconstruct the paired certificate and perform certification path validation using the reconstructed certificate. In particular, this method is especially useful as part of a key or signature algorithm migration, where subjects may be issued multiple certificates containing different public keys or signed with different CA private keys or signature algorithms. This method does not require any changes to the certification path validation algorithm as described in RFC 5280. Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-bonnell-lamps-chameleon-certs-06"/> </reference> <reference anchor="I-D.draft-ietf-pquip-hybrid-signature-spectrums"> <front> <title>Hybrid signature spectrums</title> <author fullname="Nina Bindel" initials="N." surname="Bindel"> <organization>SandboxAQ</organization> </author> <author fullname="Britta Hale" initials="B." surname="Hale"> <organization>Naval Postgraduate School</organization> </author> <author fullname="Deirdre Connolly" initials="D." surname="Connolly"> <organization>SandboxAQ</organization> </author> <author fullname="Flo D" initials="F." surname="D"> <organization>UK National Cyber Security Centre</organization> </author> <date day="20" month="June" year="2025"/> <abstract> <t> This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatibility, hybrid generality, and simultaneous verification. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-hybrid-signature-spectrums-07"/> </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 approachestomanaging 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> <reference anchor="I-D.hale-mls-combiner"> <front> <title>Flexible Hybrid PQ MLS Combiner</title> <author fullname="Joël" initials="" surname="Joël"> <organization>AWS</organization> </author> <author fullname="Britta Hale" initials="B." surname="Hale"> <organization>Naval Postgraduate School</organization> </author> <author fullname="Marta Mularczyk" initials="M." surname="Mularczyk"> <organization>AWS</organization> </author> <author fullname="Xisen Tian" initials="X." surname="Tian"> <organization>Naval Postgraduate School</organization> </author> <date day="26" month="September" year="2024"/> <abstract> <t> This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient hybrid PQ security that amortizes the computational cost of PQ Key Encapsulation Mechanisms-02. Perhaps: [PQ-MLS] Tian, X., Hale, B., Mularczyk, M., andDigital Signature Algorithms. Specifically, we describe how to use the exporter secret of a PQ MLS session, i.e. an MLS session using a PQ ciphersuite, to seedJ. Alwen, "Amortized PQguarantees into anMLSsession using a traditional ciphersuite. By supporting on-demand traditional-only key updates (a.k.a. PARTIAL updates) or hybrid-PQ key updates (a.k.a. FULL updates), we can reduce the bandwidth and computational overhead associated with PQ operations while meeting the requirement of frequent key rotations. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-hale-mls-combiner-01"/> </reference> </references> </references> <?line 855?>Combiner", Work in Progress, Internet-Draft, draft-ietf-mls-combiner-02, 20 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mls-combiner-02>. --> <section numbered="false" anchor="acknowledgements"> <name>Acknowledgements</name> <t>This document leverages text from an earlierdraftInternet-Draft byPaul Hoffman.<contact fullname="Paul Hoffman"/>. Thanks toDan Wing, Florence D, Thom Wiggers, Sophia Grundner-Culemann, Panos Kampanakis, Ben S, Sofia Celi, Melchior Aelmans, Falko Strenzke, Deirdre Connolly, Hani Ezzadeen, Britta Hale, Scott Rose, Hilarie Orman, Thomas Fossati, Roman Danyliw, Mike Bishop, Mališa Vučinić, Éric Vyncke, Deb Cooley, Dirk<contact fullname="Dan Wing"/>, <contact fullname="Florence D"/>, <contact fullname="Thom Wiggers"/>, <contact fullname="Sophia Grundner-Culemann"/>, <contact fullname="Panos Kampanakis"/>, <contact fullname="Ben S"/>, <contact fullname="Sofia Celi"/>, <contact fullname="Melchior Aelmans"/>, <contact fullname="Falko Strenzke"/>, <contact fullname="Deirdre Connolly"/>, <contact fullname="Hani Ezzadeen"/>, <contact fullname="Britta Hale"/>, <contact fullname="Scott Rose"/>, <contact fullname="Hilarie Orman"/>, <contact fullname="Thomas Fossati"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Mike Bishop"/>, <contact fullname="Mališa Vučinić"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Dirk VonHugoHugo"/>, andDaniel<contact fullname="Daniel VanGeestGeest"/> for the discussion, review and comments.</t> <t>In particular, the authors would like to acknowledge the contributions to this document byKris Kwiatkowski.</t><contact fullname="Kris Kwiatkowski"/>.</t> <!-- [rfced] Would you like to make use of <sup> for superscript in this document? In the HTML and PDF, it appears as superscript. In the text output, <sup> generates a^b, which was used in the original document. (Note that if you would like to use <sup>, we will make the update once the file is converted to RFCXML.) Instances in document: 2^{64} 2^c 2^{(128−c)/2} 2^64 --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "tradition" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> </section> </back> <!-- ##markdown-source:H4sIAAAAAAAAA+S96XIbWZYm+J9P4cWwtiI7AXDVQsVkd1EUFaJpCYagyKiZ 6WmlA3CQngTcEe4OMhBMjeXP+T31Y6zNep5m3iSfZM53lrs4HJSUmZ1V3a3M kEjAl3vPvffs5zv9fn+ryZtZ9izZvizrpv/DMi2a5Tw5q1aLpryq0sX1KpmW VXJeXOVFllX19lY6GlXZLe744az93ThtsquyWj1L8mJabm1NynGRzunxkyqd Nv08a6b9xc/LfEF/j/uZ3dif0X11s1UvR/O8rvOyaFYLuuvi/MPLrWI5H2XV s60JXfNsa1wWdVbUy/pZ0lTLbIsGcrSVVllKAxpm42WVN6vtrbuyurmqyuWC h/njxeX21k22ok8nz7aSfkIj39raus2KJT0xSexKHtk2fSBv3/6JnpIXV8l3 +B6fz9N8xteN/wlTGZTVFT5Oq/E1fXzdNIv62d4ersJH+W02sMv28MHeqCrv 6myP7t/bpgHUTVpMPqazsqC3rbJ6a5E/S/73phz3krqsmiqb1vTTaq4/NFU+ bnrJuJzPs6KhT4i683SxoCH+H1tb6bK5LitMj0aUJNPlbCakPyWSVGnyPC2y 6g9Zxt/SiNIi/zVtiNTPknflTZ7y52Oi3rPkTVlMykI+KJdFg/X8scibbJK8 ppdNyjl/lyk5Un7BYKQv+KcCjxvQMLfXB/Mhr5bzdJbVd2mVvM8mk9UXjIeG fkVUqmTsVXbFV71OqyJt0ps0HuhFMdGbbXw3gyZ468cKb31wkC/yOc0oL+tk OL4u8yJPi/Qmr79gpKfNNW3OeEDfVVk2zqIRTewFgzp8gQyqP8pmMzoRo3oj DedlQ+fyVTmbZaMsu+kY2Iv8Kj/LqiYY22XeNPVoWV1dt1Z2eBoNrsnng2t7 9D9N6EFjelA0lryg4/d2kHy/LGo6VI08UUb3Nr/JWl/Q0J4Rl6DzWjfJG8w9 m/AXxkr0O/6MtnmWNc+Sw0f7+8mwnNERaZL3ZTpJ/vynf0mGS7o5OdjfDyb2 fdOkd2kv+b5oaCuW8ezOiLQT2yITGt/rw9fJ0XePwinPaciD0ob8T5mMBjOm Q1qU1ZyIesuc4u2b/uvzt8/45sQ458uLy2H/cP+I5l5OlrOs/yZtGiJaf5TW ODLZqn9ejNNFvZzx6iRvs/E1rVU9T4bgAGk12dYnptUV5m6cpLidLZa0D+ja ZnBV3u7hB3yyh3fuvbsYfhjgpwG9fbCYTOUpzCiTaTqrMxnyi+Fp95CP14b8 nIeM3dOks2SYX9ERW1bZ33Cgx5sGOnzzavNIHz3DEJqMznCdvErr67/DSB9t HCkx2lrG6aXnbFWU8zyd9en8ZEk6IzGYN9fzmkXkosKH03Tc0KdyRhMaZjLJ 63GV0Y6elVepXo+vkp9VENMeXCybrJLZtCeTVr/ktyxeaKR7fE9/cb138mj/ 6f7hE7qFJNdt1h7rKQ2EDqK9Yi67cUxUdKPmQdOkU2zhpM4gvbqHMJkN0vGc xzAp872D/cHBwfGjvcOjJ08Pjgf45/FjuvH92sKe0jEgiTXhV30/alJigyRr 1xa0ZkJdLkezfNyns6S6Sb2qm2xe/2bDMreGBfLY0I4enRwd7w/4n8Ou5X3/ 8uzx/sn+M/nx6dHJgf346NGx/Xh8/Fh/PN4/4k/ffXj/Y0xofNJNNXAYHlxe TLJfBvV1M5/RhS+rclI6BuOOgH7a/agpvr3JZK50xdksJQ1q/HZ8PstJ7sSP 0i8T+7b7kWO5ajAfZ3yVPfrlu64Dir30siTFK6uSWcT5sHlpyye1X0tsx8TT ZX026Yw0vD7uGECF3PuCBTo8evSMGDUud6za7f2+bN7WoM8Gyf+Wzm5IaPz5 T/9VLvzzn/5L7c6E3IT96I9ETqNf0OFOZ70//+n/TS6vVzUfmvfZbZ7dJae9 5LacDZLH+71ksRgkh0+OH/cPnzw66CUHJycng3jCXdP6cE1qbNN/ny1IDLUG bIq5XAMVgJamyBK5ODncP9zfQNGrWTlKZ1Vekypb0+OImwjH4BPFrKje03n3 GxlCo4/vV/z4Ph7fuRI/nPVfvBtuGOsZ8y4mIp1g0owSunbDKO/u7gY0mqLg sZXEJ/v7RwdkIWziwWDUrfdutmBMJijr3TCGcV2NvVxYVOUfsnFT7y3wWCPQ OHjs5m/6dfzCrgmczcrlZEqGQtaaBmbGm3Exy9KaHp6E70nqZUXSpM42TGJE kmQwds+GEsMirh8N1h7Suahnw/2D1pheZDiRvI6nRTqjnU+HYZpcVnS8+RAE /Jl0HZACIo7U52xOp54NMxKKVyn2YHI6SRc4psnZdUnGXHKWL65Jxcx+oa9I lxvfbJhbRmMumkGejiveJof7+wfE1p92TeL5q9f7J61ZDJcj+qHJaUR5IRsy m5LY4bHSdC7eveifnZ0+S34iLZ4n+6q8g7RfziY01pR04uIq67/I3ARH9Ii8 pi/Ku2zyH7982Cd7xwedw/7u7funT9ck5USFomOkSc2UJT4VETY1wo6ZsH2i fZ1e0fdM1XqwYYCLrKS9NhjXpA0PSDsfZJPlXp3PbvNyb0gq15j09X93uD8c 56Qa59N8TL9cpgtSLPZUXONbx+T3Tj/qxx/dhx9lK3yUnfDxVAb80XbCR9kJ /bcy4I+yDTadfTLfTy8v2qf/hzOy7OnzpCibrP6iM342fH+2N8/IYNy7tOMe cpF+yEVIkRgv2fLey35J50Sx/jQnfXQvXeR9fuem8ZLy8/TV+zabxN5qSlUK iYMfP01GeYOLaXc22RWRF9v0aUL7j35c1uCkh/tkrcxm2HtFmdcrklh006bZ ev2QrMm9gxNSafdPnhyfbBjkwf7wrDXI5yQP2AeCYQUnu0/HI/lxgUdAYcVZ Yv28X05JiGT906p5gNP/vMQMa1px0jDU0GXOtTfS9/WrOiXub+/rL/lV4Kv0 d6p27foMhuICiUR9Xo3JaGQ1E18za/VSXcla/OboS0kZqdokGB/tn2y0FN5c PP/+h/bCv8lH9CGR8PsFsRkTWMN0uomn01m6Xo6YSCXd4rk43bI3y0flz3XX y1+vRlk1zCdtAXOa4MM+MbSiyGbKcsXseEUy647ERnKB/Y3NnhpzPHv/vw4/ nL4Z9vmxX8zqDg/3SOnu1LOH6abx1RjfWMeXBuObp/UNKZZgzfX1cjqd0S91 OW14zPnamPkNG4ZK+s3NoMZ46aQxbWlb5eNZxobC/v6Tvfrg6OjpSX//8Ki/ T8rIo/5R5yxorGdt/bKDwGzYxWY26fR1ckojf1c2JEuzWxo7fTxaJa/yK5KI /e+rCanLb1PobldfQ/KTg84zrq/voPl3WZFVZBgM1ynPAyex2FdhE+v4l6/P eTloLiqUNp2g9YEenOydHHeKwbckk6/ok7Yecvn9m9cknz+UtOCTOnlDzILE BanMpJA0UJViHZAGraqH6CdJrJ98DUWfPulcfRvoYfuMByObQWwm8MZBdoKB yfKfLuEtbPijiQztF5CeBDZJo6Ycl7MNI8yzLPtlAY/oAD+qmSvSae+EzNTD w8cPjfboIc05HlbA803LUFkdaG1d2/3rtmvncM/eDU8P+/tt9lAU5bIYg21D 7JzBHV6Nc1KP3vHBh/NAAwHJqePz4jg8HGwyk1gLGEyyaVbUGSsHNLJHe2/T 1d7RPlS2oyeHT58cH+z1+f/7pDucfsQAP9IzP56++e779xcfXr0dDi5fvNx0 9F6SfrWuWTv64mvs1YBfqEZqCnTMPoYPHrd1/kZ7a9FkleNvJ0+e9om1He33 D54cPjrpP/54cPKNXtTn+M0D82hv+J3vi2zXTeGiZp5GOsL3C3FIPy/Lpm4q CVeIvsA2NstlvY31nXiO68bEJiX2a+Z7/OjJ4ZP+0ceDTstheNEnZbLbqGWZ m4S2Hrulp0sy91j0zOpeQmtV4chPiKPPygXrjMwkq0yCNxMxux/QkEZ1PhjR Q2lH7g2vSbpNXpRjUrfLu2JWppN67/zdHg107zK04p9X5fia6LgXKgiRYTqA o+k/FsVv6cQ9jnnEwdMBqYc4jqxhrzvsLkMrlL7epGFXg9Vi0JR7C7EQFj9D lSNm/2T/+OCkrSjh88H+8YDl1fCy/3R/v//ocZv47yO68ZaBV/0Fiaxbc6nD l8gbiP3tJA2IMPU1aP+Zg7LZIzxcZOArEY3ZQTy8HOhAq8ONqt9q6QxQN5Hf DfA5Sc7r7La+WbH76WWeNn1a43leJT8Rr0pOR2XV1M+S08XCvReWgp4M3kkv xZVMirLyAmd90RN7yenw4pQUtssPCYzNbRtFl9PFGLFGLPfSGh/RlmEz9dHJ AWm4J4/dD366bT3osn8Aohw9PWvP+m1Ou4+XiWax2UtjH77P0klekHnwzD4K BHx0x4dsfF2UZDeskgtSnSrSjqt0RAKXWD97jbOKfYJkZqin7CFSFONxmflt UJPAqPdIIqTLWbMnpt4hlMGDQ0Rw+3ObVZ/9K/XC5j/uL6psls/zIq1WfY58 b6Ta6/Pzy4t33/14GftpX2cZ88kfF8kdtgT4JbRFREGqEhzOyzhitLxD+FRA o8TM02VTzlmAp4G/hr5WtW2hCkbd7QHukNJHZD8eHann7eXFu9M3LWc3fUxE hs+KGPnLvCJN4Yj+pdfnv0JRDNc9ZOvqKtswEl4YdzKzu7rPanLNP2Ncx3v7 T8XDVenLySynlxOrn9rLY+dXYFaanw720+m74fCiFSnBRwncu7VZuZu3Lwm3 os69XrnGGGE30TSWt4Np1bm7nAo3LeFR+rhcfKSB8yM/Mjf9iB9oAB91Kh8j 3i577JWJLudn+OFsfUDw+tAevv55bM795xevz+Mb8cmX3MkJFv2fvovujuj0 Y00qQeG02jrZ4VSL3STKsOikGoJQRNnxDdHOJVNwwsYePyPwytD9ztjWUaxZ 2In6eTrfBeNaKQvJ6SIq7384E797K5jiPu9e8Dqd9/+Q/rwknYXUnnpRckjZ hPNHRLbrMS3rR+xiONPxhbfNIs0DH39JDPDwiITp/hFZq9jRkwnJhdaW5s82 7NDIOeY8YljuSX6FoMzeumP7+WWL5tv45EvZysHTvcePnurWvTxrnb/LdMUC /IzeiMSOJWmQq+QFbQnP/uJ479r2Ia2J2PHtYDHOa73FHXoeA7303x3uvxgO 9+xJ+KhPH/Rvjz/ufzzgwW1t9fv9JB1BhaXds/WBWEE6AScCX01DjRD+8Nkq ATe6hcRqh3KTHWyc3eSO3cqkKMLGr0PnWVo1PbCTSa72jMRqkhsyEYPA8iQj E3BFrLUpJ+kqKUd1OcuarJekNbMq4v+k96TioE/rejlfiKRY4pUkXwpVxUnx MNroqIoymYmYuS5nkwEZ3DTbSYXge3Odk4rr5AdLGzIWqpRIsxyzc3qOPA/P DiH1oxCGn0MvuSN6XSdw30w4xsDTIapA3iejErIvIARe5p6iTu3kA40oMTaQ wDCGnUpPXiUuwyyhv/nJI1o39hZh2ehpTAveEfEYIxV/h+yB3R6NsCFDxeyX XIKb7Br74YwFRPYLjRrfa3TaBb7GFjyAhnpbzm6zCYcgHI34oRvJNEh+LGbI qyHF4jYvl3W83xLxjhI1sThJfZ1PG1p97EFikYgWEGHZ94Bgkq4cfSkUTybL DO/GOJdFTvwK1yzgrshYa9g0KDkT83wymWVbW99ABavKCe0BMIatH6Jtj/nR 0Py++gP2SIqXllUmW3Rckp62aEAYucnM+RqBB1V8Fxx2rb9N8kYeeAcrE2Go 2wzbKMWIafuIccnK08JFqeAhNI16kJzR38RWSWOcZf6WbDqF+s0vy5D8w+Qu K9Ie4ezGx1eIFxe822D4YW5QvkDAwORj0rlX/7xGDrdHaIHUYiS2McqYVMVt Rt/SyTtt+LmcVNJEG51+Zr5AtsSk9zUMqBYOVO/SA9MmoV2RsNudqDXJ6MYl FMS0XpHFhZTDkOXskNpaJjdE9QJcppMv7fKMCjL/Vxkt8S2yIYnCAwTTiDoV dmkGdy2OzFWJ6Tric05MQEIN003zjJgS0XONij2vH1+VRGa6ZrTMZ7wmc9pZ tHnvyAhYCusgcctjWScJbebvi4xzK+kcz1f0zLwW+qyTD/NDCk2GNU+xWwtI AtmsZ5c/yub5Dj/QBGgxeGMap+JdK6s6JnX1W2KXmHktN5TLZiFWS3IFn2w6 6y+WtPlIg+InlwWtEA2xhm1KR5pzVeWYViVNDTyVlugun7X3HI2cSF+WveQ6 xVlJCuK8CCE24d14tvBkGiAx0F/G2QzsB4diWSADSxKCg/3GD9aQ1ZflOPXW 5ZN7fyScmDQ0Os1IiUVhyKIxqQWUPY6o0dyxLXT3yDwfWEsSGRzjxM08YZIt dPJ8Okjj7UwS+jAn62AX4x2k3GEH0ABBnOmS5eD62+gFSvyQJZskKZznKGbv yikGiBFM8nFjEkiib9Mkm2ek9YBDsi6Cw41xpU7s8A1pfdMzgRQfv2WBDE8S mg24xhXUO/r0DkFw3gS8mUbwwWSeo2Ef0KbOcZzu770u/OkTnaXzX4gcNViy O9rX4BcsHxCzASPAam4QuTHX4aUrp9OsatEa61XUIHW4F/6xRpLEbX4Lji9b YJ370utDjtQWxGk8tJaCo0c4RbJqml9dN7ToiEisEZk5IbHrioWIVwLoDZAh oOgguWhMUPOalfMR2a0WwjINhscsoom1L5N4NRm8NfNKFlg056W71/Fev4Fz 7Fx2EBDzqTJmjAt+3DXrHyLAIx4sPBmqJn6lxb2U7VXT4CGWaho9LU0l54dW edsMbXpaOd3u+Q9gVdHvdELcR5V5draZEHqcWmJ0484IdUYNT4GFLwuV8jJ4 2AtgxKTcViRH7nhpulmBExck+pdXTBORjaEW2nk6ie0qH0eofOd9Dgn+5z/9 i3j26IdTUpPmabHLYzo/O0t2zmeznFTycXJG2zWLvAm7A2Q5hFPlCCcxWWKP psg62jHhNWowWnXxfWHpJNnty36Q9kksvKDFLFImI7TTDbyZD6IMxJ19FgaO PYcC9VTWUnLKvJ48qdI76OP0HDp5XkOn2SygkdlDZW1Zxs/BmyRBVHavmCt0 JDqXQgwQ0pUXLKlVNQs5roTZdEL4kjV3Y6EyTuF6eMvAl7g4OyKwG64lkcOF nzcpzLwHA59uz+7UU5sJuWijwRKc0lJmzV1GTNgZZ6wAe5+m0MIeIoxwRJuA WREnXza5ekNZSzLpYmSSg4AZQdMMlRPiWBD0pEwXWZ9e16d/aYHIshpndij9 xL7FzGhEK1ZoVLqLFQKHL+1jpqVaPs7wwPo9aEdiV49ZJZsYdcJFnOQQCVg0 Ji3tn3JZ0QoSg5+FCgh0hTr/NfMEbZuU8VEbJC+8RQSduE/SgWWoJl/R5Omr 2kxAVOKQjrPkwiVTxcTGsn1mhxceY+yf6wrchXS9lk5f4dipVimWAOmW01w5 HLSG4mrGaV8Y/QB+iPD2NJ/XysZvadymQSZXy3zCTnDeJ7aV79T5Br0jOkaz fFSRpoaVLIhidJnbgr2udQq4dU83Fay8PvGBud+8tHlEqcthvi4RWcGmy/zw x5ysToNckIXn2GnNGWicRgpJtahybIZ4yXrBeXTaUbA9bOFxF7ZDFtVjzK0e gwwceNCFRYeb5AU9K8/6r7LZbJ7KrgKXr5sVrcaN6Mmy1EIgXQDsyxr6AX5g 5VIVTbqFTDYXQFem5rP7eLfqg2j8nKPEJuCmSbUHHO7m04l9PKO35o3t1qyt uiqnhhBwxl/kB2F2k9bXMHvHGnWoyrkwTNqNIsDpVJCaomKpIn6B+j2VHX+l VTmDe89MVDD2LqHvKRPWRNVQO0h6LkjlbZTzw0cCdsc6uflW6PE4qtBzYVjX ZUtbT+eoLWK1pCyhKqeaCtrxTllYtUXwo11FyrRxYfDfWiV6k97Ql7xXwPno PYNkiHPgFVRhJlC+lA+RnVs3zO5nmrOhSi+UPvpZvaYykNnMO4Wa9IoudmEs ZqKqJyyuIIVIS7zi2LUJvXHZZ0HJD/M0z0S8FJynF9+ZspZMmgHkDHL/R9kU ZjkfV57tQJypHbkbMGlWyc674emuTVWrEDnVsE404DNhD5Akb4GZqfUVcQib tcTisXN+HCaFczDZO21NyKCR3JNPnxIJmGn4xygBDk9H2eXEeAW59hqEeS94 PMLrvssgupOX2YQZ8/fEVsaiolxY+QJiYjaenefDi102nfiI+Anz7NzSdSUX eLZ6f68pDTQZWV87RumM9nUtqxeT1i3HhRUNcD6dec75hUH0dQfRP2GbRDcn b3rJaGlyWtQfuC2agLebFyNeLKIuR8Robwgl2f+RBgyKPcMBMykij1VLK9TE kcgBFTyr+8YV2zj+3BO5rnAH7WF1mCKb9B+xV7gejIjrJmD6dtu11me+FfA3 HVrCzl1IFLUN6NR/OQdO4RpNkIJeJajzEJ4sVS08Pq0Ci0eYzpprMXG8L5tm zAV2bJ6LrxNTaFYLtfiJRc01h4zzFCcl5kLCiZk1O3tIBjYJzNzm2jRMvIEH xtovVkIEhWoBTkMnSiEWEmvXzKjNFwGdZcK53tt4wFy8bp7l2Z5nMTfPUnDL Dau7g7K8bmfSrrBtNvGLVdIpsxxXQL1qOldhTgx/NCvHN/7XeLF6ydvTM/o7 a8aDMPbBVL9dzgr1RhMJ1l2UrUDHpMxEWWe1SY6Uqk5prRTr1AjAN64bc+gE b92RhUiJfHXmiemP6/29FPxgJxGBSiirNZmqW21FtDW2ZUGcSzTfwBEhu97m iUUgxYToTDwDPG3nh9cvdiG0wytEo8X3HTYtEVvTl0XXmpW5d/llxITAegLm 3dIa2LUvz2eljtYJNmnGnpbZSizyPFj6yO8LiznZwZzpm3ZtpaqULlXZThaM +GXBuc3Fyqnr5vC1pV/T8x15r0pRFsRnki0Cu531HSY3G+bGaZ1ziJMZWko0 uLWaIE6DpVFiDbnGLTIfVCKaUan81EW1XezLxSE2+G2us9mClS95CiYuz4Lq SlJP2HXLBQR+b4+j352Bc0VLVQg3CAlWSw2P07DSmrUVwUzIGy4aTPIpuAYM LmIKjYpF9q1aDVsGAxa/uPcxq8X4Lt5/eEnMVnw4ycuy4kQm9X1yekOyc/by /Xe7A4TKPpAakIvsbEfKsupZcuqDxcz+1Oavw7iYVYQ86M9xcnZJj7BcEg1t EXe9EocFH2BXz8hlEM9YW6GdTsRd2Dd0VhpxpLWZkx3GnH28BR9A1KfILsiq qmSP0NYbOvjBO1CJvJw1/aac0cbnUNVIlkCMSyj5IPCcLsoXxKEW0SBbJJD3 IFZXiX1sQUJ28PDxxzLzLMDpkKTVEQ1K1bTe2pzqw/HgZ+Fnm92So7UqLecZ AhNwnjMLZ5PKsxbKe29HKC6tdLkEoORamgFv33oJDZMT0Gch7etuz+ZGHSq0 1rLBFQkvaCsAfzlDKoMaOEG8E9bqtErnGRzGPvk+JiMrtZgisuH9qyNHKJ8G UOlBR7AzXWo4/YyBs2x1tmIWpLKzT9t+ZY80W5PqlcLXxPMcv4To7fbYqC6Z 4XBumiZXTXbPzg+QTU7xIdCeXOFIfmjHabyXKUlHGAoJefEXlSwGbSjJduiB DBzwrGGt4g/M/R655XXLbiNgiN08JqmcrYVkNEuDVXQXVTB8HrZaLAo8gs1L Lyd1dzLgDEL+elyKa6t73OI+mMr8cE37/Qs2+vKFGb3Y1tj+WcP7uc/6hbqP iGbqS/nWiQcaq3hf3ABUJvNiLBC05CMMRTLZbnywtD2QdvoKKYUSMguE3xRn cj3owPb0dqBwSiqQuPNGst/CBJ2Br6/2a9e1dLxxRubRCAPk4rsM5f61GEbi VZBqUPGJVGkuhfyIEBY621kKhBo+J/5khpGKumt/dY5xzGKZjFp1LxTTJW9v EsWQInQLB/F50GU0aHUHgajTclkYqyUGK8y2rEQGuV3aEe+pXeid01BW0EIQ X8UeDaiMI8PUpCUs5LSGOzNFyERU1n4fvtCcPfMwdcQGBmMxxa/mWja6jimJ M6CnApqbZmCBb0sYlrm0+Y293lbDD3G3kRmCW9HD6zSfyNYWNadmDwExuF8z F/cQ/sJ2bXKbVrklT9MJ4bACv0u4m3GqthmyrFlJXPmxyfUthhaRTNSSMJPo g+Oi26pQ9raT7bWsuG0+J9vKEPFrbeyzzZfdy+C/7rk4dE9za2DDikUWuG54 raKqDXe8NXADdSENUnLg7PflAdAavjGMhjAxLOT5W1tcXj7W7CNzVzsfFCxl bM66HOfM2VyGi60OR/nX5L2LAW6KVYrzt+2gnUjK2jInO9XFR4L0tqLb/mXn tDef6bQiblKRkZRhMHCJ8DX46E15q+4IIy6O0F25xkdlu4hAuEtXZvHP8Ele 3DCjcXRiH4F4sLG4UfrDYF2r5h3cg9NCGKq42on3rUZVPqnjLJMwzzDORYP2 SDN9CX1CqsB75gjy/ite21pcgWsR/W71r5Xx1mQLPsfLOpBOjn0i87Sq04r4 UmDZsDtH5FMQhM+Ka7ChSXBTjyWabryVZqSMx5zdqa61LyGFGJec37y19YIs 5bzJTEJUV1lf3L7rfHdSOr1AvMkaGQFGEhzrhTnofGpgnJDYMRw+ozQ/Yp8k m8x/VJbEroRfMUZDHZiv4jIVpqCpOUjScroVp0MuFgC1AWJZ+GJP02AEFhmb qIdYkysfTmrBqOMoPoKokLb5baqB8Hk0ZTzOSjpgSn4TeAojzfL+G3duP21t Yb8uCxey06QIZx66R6iObBfEiV70PdxZHOQy76GwOOhNta/nc25dk4xE7nFV 1rwMcOZKlD8viHjh8XDGhXNeOoLt9pA8uhZUBzuTwJG3Z641vDBbcZqliz9G e0hEFW/zrKXABM7X/nqemRq6xXi2hHuELuByGuwRpHw4mkZ+QJvX6flQPEEO mcMX27YjkXLHq7enZ/3hq9PDR493e2yyZixRaFp0OMTKqblAMOLetaSVa1yA dpP7Zc7J0aolZeotaaU7Mc/d7IOG1eYI0PJG67BpxH0M2W/zdsjOKCAeY044 yxs2sNjnKlMC+VHGVHGwGLSQxDa3wZyrgPPM8S6J/ksq1drWdQNVa8VT8UuJ 6JKk4HPfsIoAGqSzub6JZfAxyFTwrRg1zvEWcUC6aQIlcIy5Z5PlQmnpcKqK 9fMNR2VPEkE0OyvUDNqvJ3bCnBJK6Uwvv/YpsWR7Sn62o7TnGqCfufyDRHuO DuiqR5o/2zGsBa3KpdOENClUKoTpRPKCITVGEuZEbLN3B4lCHOfnS5iNrEeR q6yfz2l1dlmrg3j3Bet8OGs/xfCZXD4QXMX1FJvJi5VPAgixcDnd8s1cLn7t YyZ4tc9NUZdsp7LlDpHPE3fFH5u1UTGplkWjpF3fQsyJNLfKZwcZw5xBV/N5 QaNsnMLL0DlXoslyrAkFPkDO9ZiuflXY88Hh0z6cfBvCMnTd4X++f3z8ye0Y /xBjvhK/qNnsi1SSICc1iPatP0gyuH3NNuipiRWNeBy9/gPNFjtARxV84R+n boPMfG30PHihZrOMyw97m6ckqWqjzFy8nBsLbodUjblA78CjH2bcsSuju65A Eu+6Gc81UW22Yr+3H5wYNOzazpzZLXsLUx53ab8QGPYEWVd6MbLEmCdiR4tb dn0YbIBwEgKnKyApHIZbPpeSEzJKVLPkTbBDW+XP/9f/Pd7dO/yEM9xLoC7U yLMj4ihwz6PHHRomv4Iz5WVfIsjCbxkhp00Rl2h/HjzuJQf7h8d/xSOODjWy Ay6HCBAiZ/f3cHFplOz+3kO9ffq0G2SX4VwV17LrWMlURZKdNRoLYsW4Cdxq VpZAqkSfCJTsnEpG+qSrqHa3LfBzt3c0e9AzIFXLiwyGQFrl2CtrvFySfO7M 5mAjShYsrW+cP1IzMIIyHCKmmn6QuohG5DAQY9En3qCgAqJrIxcReZBwGBz1 s2uynhtaFkZ3ZFFGBtKdCqyOx6UkPbNbZVwjhK6ddipb9BdwQomLgvKrRSZG qPgSzI4i1TROFdDyEKevWo51XvskMAvMK0TlJ6jpuWVpFSrvgozuMQ0ZvIGH c/nDWU8cqXmtWeBrngRm4JaQiIjiZGNq6mileoJjOBat4OAJiS4aBwfoNlTj uZfS23Rr9uSHk0PZafiFjqsJFBK2Y0414aWxmXC64yQo/WEgh2yTFk/P7Dkl tu0K+LLqwVNoWnTXctb0nHAKKKO83ZSUzD1CoEAsdwFZTXT0xWjThB+3LTlH mhO0OGio8V2u1IHUjjPGau+TTF4i1e/aZ+NoTpS9dBgQPcof0jSmHS5g36Wd xj8oQ0JqE5Bwkp2vxc7ZDROjej7jSGyuOrPFxzKzbboh7LG19ec//dd1MDbA qoYylFPRhRDd5UWamE6qn481s8tsvebIrt11eQNaZ6Srt3R5U6qI3QLXdp7+ oTQCb0gWcb5U9VSxP5Qrcm2nzznpRRMr8rBCx3nDenKHwH52Fvv6qFuvKxs1 s1KCMZcSxCYr0kHgFUk1vUdUektHYr9vmOVxPvsundNOuL9XoF3dN0OkblRV COfLlwCAlwSb5atqPrcWEnsJounjnDfUdiS6u1xFopT7eHcH5maekrGPpUrm KTAw1PXUAfEHWFnEAZYFdlQm9XNpR9ECqydBKY56EiNfX90sJ1jNWvzj8ZJK FcGkJ3kELCNZ56VV6zPAI/vVgeaIR95Kaj+ZHVzLnYn5gbEFtdrijGpHtkF4 QTv89Il/BL6k/ggUx0+fYF/lYJxY1DnEXKF56MR9MokIOeOyZUPcEd241EJU lNkMGaTKq8Vn0CzpLsscck5phIRprS0bGHTb5HHym7yOc5+JAXqXEnoeKBto u3WQ6hMUDVoMYIPnW9Sytp+WdLHnatSkkCBjOAAzJ3kQKFFmQOMkpZnEsZXH OztdnAictG1RoB3aG1VjBOEpOgOOqySu8qt0tGqkbIFfc3/PiEt0inriMBbl uFVxEcVAuVTDlW6QYIIE6sUCfhPLYqOj0pOwXt3TsoXwWraCuqi86RU7+SAb 9D7Pu+USRuEFnirqfDczb1da5/hdX/jdA/xeBJHDAAnxDRVorZVx0YU+Wbt0 MpeBEqNNhnIbyD9XPSklY71BDzP7ITgaTVRNrwocPsQ+ARQo7mfN5POuPY2M ufrn8ecH6tL5cXJgBrDtDXZJO2tUIlccP/LVyPPiUcKz02K23rvvzFvzenNA qssJH9xzf+9wSzwzSvlEh3kMgWs7mk3wJHY9rEpd+HpcLvRYRuE+txycmtam lEsM9OESQYEQeaOeD+j/fTOPas0ICQYVyB+rHEB2j0+xWcvw0ZBLziGSb5IP wcGJ99yldyDzkM54mM8ZtspJTW5bdEoM5PNpOj5JsfP09fTEJZtOXK2bNdIq urpVaG1wK3nVNqMY6WvxMZa/LF1bweQp/VBnLrcQcDHI75gFDmYOb3X6jp5t bf17zr5Jr6osc7WrYE1cPsGw+q0LNAG7F+Q4t6pZW8rWzotXnJTaqt1sX3V+ RtdFmlc0jPB9QiOICp+g1PMucwTHDM0Owkbc1PGy49mbqmFYOkiiEadUaM2I DzR4EIhYR2MLU+wQud1tKQdzson5s3NdEr9FLrW2R3tDkBUmChSGkc3hfVrf NCBEYBzQBp7YJnG9VTTiyvHHcHQ7KtPhLlDBvOtDOQkpHoXjcsLoLYhX5ap7 LBhrkFWBAcCswsfFq98zdfA6Xauw4nS3MQrP5KkdgktXyLSIytfS7ba3mZ+h HKSeTabn0IVuMy7sykyqqHrbnt1aBBDMGc/FmXrRhp+vn61/5moZwp0bBEbk PWzbuxwGCbAwsA7ysZeFJuQCL25eTlz+HYsw6I89j9nDpht3lGLJJpU7AxLw c3Rfww034UnvhWYLRwpE5RZeJITsB2ucsLoX1f7U6TyLEqxTkRE3D7McrdIV BBs1CPIvOETMWXmkKeeuRmrXWkcAZHHxKzR3gxM8xA+iVia/K9QO15/Bq/38 +TBaafy+85x4x3X/ebnKCmBVEvOg3RhSFCkyckbGqz57YSrOlF5rWeDBHOrk 16wq+4jYzLLJFfuAy2lfgY6cm4fNxVl5J8HcmWbx4uDMylrLcX3AWXLwSP5w HUFWu6iiHAXzkWEXVi6fT+/CDpMyrdCbFdMjCMHiOVAsAFVpp/Yh3TV0538F P/RRbbag3JHierWWW8wNGJn8hjLDtznHGrEhriwbqiX5eHCCm+7v/+NF/8Ug r5ppfzytrvqjUd3304bjGpvjDCmTQNlyXOJZx2dtaeoibcElRjAMTkRgHE8M 8xNNtWZ3XwD6Ec9Jlu6zRazQN7QAlq2Z+3ufKPGJ1TR2RqI2wrnAyEYAEFPb PtZE1tss8bh4Ut6drRdXsNbM6Ywh3swouNclspkLMdmRSALDbXLs4EMrd9Nh LYVu+wlthj5XxDvzUTjVV6Z6S5oTNFpJZISOwi4GdQgBxCJ0EqkEVfwo8b+m nfXW3PgLtda7WrqnNbYhp9BScpGhkqjow5/FJqw0r85YEIGH4fRHjTtLnWqE QNCZHacklM1rHFs9nRuqq6RsJOdAiNRpAhu/tF/8NIUMvdj3o2mX3Q9P7iSw bVm9AhEgWZlxlTfK2Fl7s+Rt3er4HK5b8ZMj3dgb++idwsgDOvhYrqmgc2It yHlpOdFZYQzh54zEfQ5IMCk8DIZ+aEgJOSqotQqQ83kd9NpELHk+c2eo82fM u8Qa1EiDjxY8Jd3wjSyBAP93NWG0on+wt/t76fD46dNf0cwx2bGOkMQz8cxX KL19lrxK5/AMwBdR5/2z1XjGCSyTuM2YK6SJdI+2nKlXBZ1yAAJk+gTzhWuy Bb1hbG8ooH4V7Bh/n2WT/lsywjWvhX8flrMSOR4779++H+5y+oorXrZBC6sY RA+g6+1qkf8uG1ySn9hr2TevJYNZ4FpzPzt/0l1eSWNHKcvIFv16gUMX1+ex vj7L2kMehkMIEexYwZUibc4T4FG4UiIO82hhEjBzWVkfCdqKbiictbRynjfe eJsxIrVfGEvetdKHUDwM/K70qN1u870Ad/3qtpxuyx3rltNmmnjUF/bNtCc8 0idIsz88QH6S3CVt/rGu1tntj3chtKIeIS4OXgNEli8XdeKb5GL4/Ref5dMN Tmo849rhhETiF4w3LkwY+5exwRy/IyzJXastFlBmVlSWI4/A8hUMhsmqzRxB 2PV7nFm++fTPsrQqLF1Od7DADF5loyo1p0KYrKSrUcvCthpEYiDPN71snc3Q h9+Vi0Uqh24Q/tJmAhuOvxPQdiTpFoGfS6TVt7tX5iUih0QN1lYz7hQ4ps37 FGGoNleqafu0Aa5yLtLVhD3n19a8vol208IIUWIulEKfSlunDYgx8Tptv+vT mkwyCM3kQ7UsBI9j4ZrDJu8Z1R1ZNNvJDp6/61cn+Z1F4jS5EmDvWTqfcZEU LmY3IVwD6B+6ePL4YDcovJwxpt6Vnp6lBDKGw1dOtUfz9bq+nvf5bjwJv6rO 6zpK4uYPHrv3/htrBvlJqzT0VzFrJ2TxCdZmY60YVNG0Bxj6Qz1D1hYrLZJh 2W2WSJjT2wm7HsKtlWWplzpOtIs59xmBSoNPXW/osRdMMg1Q0xTWV9RlX4sR t+kQoEoE+LI9qxSUciNat1fvXrzZtWILgThAayoStozNK7lB/NR0QipQypEc AacSZ/osXRaMduoqNshaaUo2SJlut1k7E1swni3WvCI9cZGJiJOxleJecNiP Hna1IwidcaY8PbC3+YVAv1jWnPCpViqHn2S8I/F+O6d7WIjMaRESMFS4wVri oZZk6bw5lmtjiizNhVM022aQLme8/qauS1WW88ZJZqo31xVukycsHrVZPs0k k8vg1dpVnxxg3DGjcyJIc2ny4c2QHkfjv05vaLdB0HP+Rmtful2IjCpTgeHD c28OLFp79zSv5gJLHRSLCfSFOtgV8FGQ8ca0seqeu3uWXcEnZHgNUnKm3419 36k6fiJwmSYTqT0tfYhEKtgCjJY5KUFjxktPzhGzZsEJUvZnzDoDaoPrBBhw LZwwWSrvQGHHpjyjKktNZg+QUyQSmY9JZeMSV203WDmrjMMbFjWUYdNe+T/x J0nT+vZqa+s3/Q1/Nn7BX279MdnwZ+MX/GV032rzfb+07/uSca5f88A4o1f/ L637/sPafb923pf4dKCrdLF5kNGQZAG27p8l37wt63EqcP6/3ZZf5iRiZ9si TOoIGZ1B8lyywQS4vVDmpWIrYM7Bc9qenKiFMuKOF/iUb4DVu/3LNu0T7tXp dUnNZfeA7cyaLHFF8ic1skJPWG3znV5TWZE+xhxNkhUEk0mCYAIYEp0BkZrb v2779yOvdGasu4XI3YEHvFpj75nSgtNGaGZqvvOjWkw9rG8Ga8+0lyJkz8Sw uTg+5KCl8trlIzCRQQGeM3OZNrtl3hJWP+d013KhagHoL/SScmhN6ceaaaQK zjkM1NJWAz+pJb257Aj/NLHQ8spxWLCfpawx0YSu/A2N+orDq0tO5kfJyVzh k0XQzALMAplWMBBXVxzSmxuYaqQ9Rc0mfDeqXQj4KPjvxQe3uVSSSCmzoyMH pxhKh9GNFBYUz8FqkfGdz6VkN7prlwvT/ZdZqHMtrlkUdm/BIBwR3S91p4gX YN4ikbNfJG10TRxbnqqM24JvQRYv6glnAqWjOSCuN0CAUq3heI2kc1ynb0sz 6QlA0NSnX2labR9eqr7zohokN0a5DvTMNQ7sdXVhegTlLZbckS8mMpulcnbH Sbwjrvm8KIry1so4Gy7hnctb70jJENx1BRwpddKCvcfPH2VFNs2bgKfcklEy SzVkZGi1JHBpeXlHuVRkpCmlFYOs5gx8U5cqydkhEr4q4V45tacJWzoaYnL5 2NYJnolgcn5Z5EwYDroowN+CjBxTG7TZgJ40cfaFMOgSqtJi8kkmWANSCTpa Tq4ynxbhxuEgTicC9qLxN2H6yEuEOu1Q+phr0e6oo4Qn2frLTHAT1stD4egS YljXBOwqJMcoBrkypGuAECg3EHphERyCtm9R4IIq2pAh7MOANgIR5qRucAE6 sTonRd6eKZwbcqtgGN2pck/U9ezXzC0++XTMlsxucmzHKVdPcWW0tgWYeqli yq0YuKLALtIGBZrYEXRnFcLak143QYUF17qVM42TMcYG7imXjVY6YRhaf5Mh S7xWrZpd+HReEnrrTYy1l8MeV4ezdqbJC5dW66fKiuO3hvhAB6y3hnMY4Qij 0DhDlq5o4a7qyGmyQfyjVbEdgCj3vQUUgjPLq1gL4L4LbM5dsp9Qn+44HIsu 05M+/zg85MMl3PMfzs/pb+3teU42v7ARB63WCsyMy75CmLDTcmh6eceLzOzo SCAcC36jT0zRzwV8L9S/GR7OkJ1Brr7y+WdJky4YFpqeC0Oy1GJ/pB5A+Lun 9ZLLi3e0hyYuBZWYekpzWihF0ayjQazKWRn+VqlOA7IEiMH4suIXcXqIolXz 5udD6aAcEtECYKPx2RP26o/UsxBWgzaplKDSO5cTdStK1Wffm08queI1yYrb vCq5F0zQUUbeuVwoNqCDnhPxWGhsGqJgG9X44u4RQy6d9AVUH2KPT6kcTQOu 41ok2kJ9xiUxwH5fGpeuAIOTzabOiWRTEp4eTYe0mBQwd8wxBBLril1cdPWo 5DxnKBGTctHwtl2U8HFk4R38dB2eIgpO03k+y9PKO1aAVhICsAoAonGwOR3i peqdrIfF3I9XmpnWnVaMepqMsisoZ6EbAuO0aJ96fAACYsWmNQ2Ke4pM5Umz lL08BfBRycBYMLM3EBfH8VRv/pkLIWC2fmtSRAfPW1IkydRyuxmXF6pixTKt X3NwuFXtweyRvQPoLRUqRDBtaIRwV6pGYC7nWMS0cfMV3ZC3kzewPVuywn4t QmQQ/Vz7I8WKoudZvLhXax2r8jm3TcbseorGRNunYgTlpB5nBUS4oYCaVylO fYAvzRfjXP6w94GToVE8x1VOEbp2wqJklgogIzz+0z7OUwoPaZzDZyqcxRWF R2i9bwfauXM9omXgcPhml21HPqxEkZ7tyY42XTxMGvZ6Oo33R4+qkqFNHexz 4uDC/eHXLl6cJBY4bXrJ2Sn+8h8lb9OCtgXzuUsfvn41fKtcU/KiSLpdM+7e sMHSQJ3nteFjKbAnMXVDEGPFy4gRtC2R2NWvWoEi9+eyAB2He7EWynMc8PvU SCUru0awCOoIsJC15otNV55yfcT4DHlfZqSGI1s9E19rZzXJHoveMxYF2WEg xFrzerTrLA+TlRCtALSFYT852MsZXJslsnrFJf5AFxtLiovyQ0i55WCilZbp 4341V5wEsNhG4E6XJHCjgJqgytrPoqpP9LtB8r1kHigVQmdjXpdXWbGyGzkU ytU/TRY+7O3lGUlkxlx6BXkkIY5WSREUIAg5ZyfOSuWCUTOvVoDNWtjw4Uo1 Y8HVMdbLTBrTzAQTOJ1sznfTksZ0Vit8jFUGWD+rcE1CDyVDOgRVlff30hJT 4iDftPqPb8L0u/8mDnFubcV5ApuS+ixIo74JllwxiAUbTRIRsiKKVOUyqglm hmbHc8wlWkRXnC/HMzoYwGFZSMKKFnNAFIFX4tMJew3Y30JiFd3YobptuxIQ yy9yJSFpZDczngDbVKh5gjSFhSpNIV2CaR7UIUL9inpQ+QewTneXo3r3XLRy CThiq7rXmwrDj4eZgZDMbQYltJcg/S/8XewQS3e3apxeZ8C0B7m8nGUbvsRe ir+pSm3050l1OgvQ9NyQp5mGxblPs6Q0Cku5K9GVuCn7qWwBiVcwk5KBOohS ad6Xuj5f7eSP6AHWpwRPl3LozXuxXWvleypozxFxMkVQWI6DBd2NBPdT1OsA HHwl5YX8pNTyeGDipVdF3mAhpxHoNjA7uLzt8Z//9C8H+//f/yPBPnoOg21y eZJM8K6Up9Xrjwtmo0872OfH4Xm9uKOKN/o7nhYnaDZWD+5dAK3cgXZ7PsQ+ jEhid9n6LV3SOc7q5euLf44EPFDjwjMg2JQdwIp2HCRHqaeJGb1E0kaYdpZe 4JpxwNl9B2QCDR5GbCvMx7R1NtMx9XseaGTmvPSoqWpxcHMC1qCRzcsHISgJ 3HYP4U3KZ+IuXW3bEZu4fmvBg6dEcfaVe5gyxickBheMuFbYTXNwc6oYEgqg EERQ/7D85plVBrnszmA9GVvFeWXGOAUoFnXx1va0ZJ1toIJl3wbtLbKrGUmt EfwN07RSgH49ZmtPJL16gpwEyXWQ4ihNgmBcsajajA7elcjQAHAX6Ik9ZUdV QJqAoq6Uq2ERMPFp7UDbSwXHcZpC0Po8Px7FM+24wMhEAsHhEiyJDvToa0lz NM2w56Da2fXEeJUef4fZkFSyiNhg4z5GN+sJD0nH7E6wLGLL9FcBF1SyYWo/ LxHnpcuYezs8ioAStHJjrppkzF8iC1SmC1tR90LO9ZQh+BewaRbjPCg4SNPK GY9PmR0txfzkgHRgxgCYxW0l2Iot5AC2I8MkNDbFTf3pteJRrsBDZwKSqCFv EC3rG4P9t6PyNujvqLB3HL73uXEMpsGhNsiYl3T3AcJsb8tKcmmKhvE2Ne5O +wQIFxoBEi8Tu43XHsHi+86ddYnzyLQ9xlVLJ5xqM2a/ryyuFGLHCr1n4i7h SXCxf8+OQr3g8aEtnfa7oyXxYzvE9N5hMWhMEG+9qFr6oZa8uKjFZ0zzT6sI UULrthyiZZ25CjrR7gsBCJyT2Y0iPhypOj4tgXPfAUaLQhtk/W3WZr1BQaos 7tDEpsvXQWZkyswcTch0yx+cPNln1xMAOBrOTvYAnzTXNynnUotVkVU3s8xa f1iGpuqi6+p9CyEAsEPugLWTY8OT18Rl4g9AwA1gRq88/IEijtmZDdSKV8+H u7KPmAx+ip4SRIfAkrfMMlqyf347HCpMwtEJb/RXw+Hem7f24aNHx+LqeH75 Az7DP/SB61mjjb+9H7SDVr5YtifMomseUX0Wx0pI2Dm3IbdKccFchrThgoK8 cXX/mn4hrSukdSgHmzQrsLkOQjCBPcDFaZfspuREMYPyj7JGHHQNZFEIytdo 8pQxjVlZxyiw4iReJXjsXGJHWSGQMW7mxDeuIBfcmXLQNmmjRW5DJciGLcA2 AHvpuK6JFt3l8niFyXOm0D8SwAg5JD5+nKxmsIpo5NyKU7iQUZoc7vfhX3SZ Mt8GkbdCS0pSD853uK/uSHUvhqqHi5y6VChdMt8/RSnDWWCSHGAIp42r6WwE GKHtJrQUCP4Vct9HTDRUw3brIHmR1xLO1WzN1ZrLsNHyTrjnihIKP3FkX9J1 pxaacXIp/YOfr8rHN+YWcoAetmvD1bE4pyLzGL0dfp5WGjE9UHMSFAjK3nSF s1L1IiincQYFMrZ0qombKqNoDBI0HXcOK5Zvt2VuPAQpnHCK1BpTtqR5d3wT 4kxBOhb7uFwKliYxGAi6bFKuroTHdMZd2TjSEQbYXS4ccVjxk/vUNEZTrG0T wNHT5B6+Wm+U4wSvmKagr3fFgpjo8of1Wt6RV9+/J1G5w0wbsx9xjrAqypyD 3WiIocoyJEQYG4yQTjn/tzAwBHvltRdx3RWKvPE1cV6zScKl8ceao+UtsG7Z GnPnpR04YshpDQPSgGu6fHXx7myo5AmhFNstIXN/sTC+m4yTK527kpQ3kfpn 8Ah+Tup7t+EnbTGERvWtKBdTrgr6CrLU5/c/3V+TxHPOs+aeofQYSzKXznA5 ut5VWc7dSXiurXp/gOus/Ostb8YXnndmlBN1hass2EcWY+W4tHMznsOE9R2r QHHjjF68y4nIWqAjHUPkF5cWL4+xp1itTFR+s/PqhzOBII0+trgQ8tFqruBM WZ7RFhzfJDs/nPXfvrg809qWQeAgcGG92UyVnVFVoqcRK5bvWUM7RnU8nW4y YZ4lmu/v5tjjcpcdVy5hOmlHPYQ2QiOt5OL1uSaKo5SBtg4Xkm1tnT5U+KAV fvk6Fq8/qi1Y4JkLR6xXhBoQsMfovSsl6oQdJAjHvgGEgna4XnPtoiMNgKx7 QHoupbsF3B5UTO54J5Z29uqqnwfY31xgWiVvDBZyXEgQqDZkRue/ZJO+AOm2 5h6CNPAMJL28Cy42jIOlEQw1wwMYCMRdGZT+kflfM3zGC4EESCVaF2MBJDsv zl/vilSUpHNNhEnDG7XcM7rvNe4zlf+O9gBdR8+yHNAA7CUN0oTjpvK6XoFj PXjLzqvL1+e727RT/4GU6pODpyhHdUUaQX+JZDuiP6cQqLuHm6s7HFluvDEx 4AIifquWaJSxQeBICGILQVBGKTWNrsqks5IyK2RV+LO9VnFlG59DGkhLlx/B luvEMUnEM8O3sMPGjkeQdWBoB/TONbwDK9PWiKBF9D473I7XNxGqRHR+Pc1H 4uLFKEWV33YJq9IwBptlgV8s+1O0Zr5hoFWuKjzkGyTo92x10EO3MhdjE9Vw YZUC1HbEnM/os0+f+BhMsikNeU40/i4rdnaT/n+gI3/TS+qbXf+tcD36XL6H njBugu9fZPz9uOH7cE1db20Jc/n94ub31prMb+le8vvaf+7tIPp83LjPAz+a y6tSCHC/uTNtMg2i/r6u/UMjrxtzJU+UaX61jJKwuS5bUy9nyEpF5iZRXS2k MHr8LE68785E9wnkvwl/3nD1H0l2ceCJfvpjMiTLixY4+eNXP3tD2vpvopx8 PPaPiSxy8tto9f/Yb1/4xU/c+OcrLlzcfNmFQXr/l79601Q2Lsr6I4g6sveF bP5Y/F1H8SUXjpvPXRgUSjxUk9F6NQggk2+d+fbO+eInfvGsfa1Fk476NAL6 zwouILLWDypqLxibNcDmmYgap1eQWrfxu2TnlCStqB+sCgo/2yxsMIhAaCsj LjkMhyYEEupQX4M1XmdVogVeYIAlJ4NjBSyBqH90+BQeWucwhytplvVhxU8S jpJZTI69lCxtMpYTtQ6OX11oFapl2Fg2gYob3HHHXsJA+4FIIttrJxW7bO/t xdtzCC1kEF1+d5nAAJ3tOkezQk1P1N2FiFk4XWgw4hMU9eULeDMG2AVP9vq/ a7bcyZffuByesbybVu0Zv799pf2pbw56xDoP9LsvZeFfcxK/6ko3lM9d6Yfy MBv/Qg76MAtd4+Se0LUsLBP6a+gQrcEh1uDQvvqqhzBLpa18/gvJkgPw08Pd r3zI34ImX3YlTfIzV36ZZNkkWowOh6DDwa68u32lMibFYyKFdFe/+1Ip9JWb 3xeXfZ5KYwWJ+re7+el/GhhtE/BvNJJYVE+u+6kX1S02LlKbJC2E9U9kTv1j C5cIaR1Bo7JQR5c4rrWJWNP5nTUg6H8mjiIDjQ1Xgc+n25Xbm0gUhm/OXEkU mubih5ROOTRuLdERf6cK0QCiLI00kp71AH5HMvEikImx4vHugjUPdZJaQoDr gXvtGjZp8QLnmW2Yv2R+ihy3remR4ix5WIfhxDQ8DRxs0SHRTIqsYWenIkvU uz7rvUI5e87u3/t7v+SI7l0jtzZtC+8oGdfhOghBexpsjBQtgVp0md7MtltF 1GwHOwDRzHKDd6ZhmOk2j7QfOD6R2pVbBhENFcTvBQFPFcMI+8gypNpVW/L9 hSgh4QTgODPASWuo9Y8R4D2ZxYe/tzrUvPnSlZTc9PEaDl2gFxKxX8UENrWM yav9wDBL8+NwLJKjY/n0gSGHDeiCPZg7L39QyMJ7m4gTAN4bCjcnEoRH5MWr DiO7Xd7ezZH+Z1TnNmkuDz3TayZCh/Uru2Vv15XdsvffhNrZ+7Ir/8eS5v+j qbL/GspJv8g/r6FIaA98s86R3JEWGYMTKsSDRtfHVr9pbgPTT8QG/706jXZ/ LxKn6AO6rUJ9et3k429ZFDlwJ44Ac0K0dyMHrJeTGdImwoqyauEQXtDlL6qA DcQaN0iIRJpuIVTASF5jppKOcwmDIXHFiz45mFbYTsnzPNOiQvTOoAGJyVHO u+o3Vb6IJhO6Yk2iCIS2IEB46cbokyLCOSdfOqKMVJ1oCzwpZKRhcFyj5+C5 OsSX5n64VCHObNTWtwjcjDnu5oulpdu0JbzrMFcOHkBqSZqqa+rcNGW0clna VTpBb/CpdNFY7w/1b1ZUfoVbUbnFwWcc0n97t+JDF3pPxt/VIf05/r/ukz6A U/qg5ZU++Bq3NFaAxf5hawW+hph/mxl99kKaau9zboi/wr990HJwy8bcDbei XHgIqh+2qH642+nWOOMIe1bt8GLRvbtt3ervu7Ux8C+68F97ax+2VkM26ddt 7Q0r8Lfb2uuxibQrOKFujlcZZNrv1wf0+153SoCoDnZ9ryvPZL09dCMpU5I8 EpmT1hKeQQwYjxqRBE0Cydr1CgITz2UZtfUwh9lXB3i7eOnvcXL+yEv2exW+ eq0UY9witzEvwjTRCA96vV45gMa3XP9W1qjaq2H6itaVKzB/lly8e9E/Ozs9 TO7v6Uf8hCzkqYlk6cxuPWF9IMRH7h3cIRQETgdM46JZR/okDwd6qt6gONNS GyQKDVV9QAaeB2Qc5a7+Tme/7bQGD259fnnx7rsfL5Fm7fEQLPcxjp3bcquP JipLc9jTDm3C0zOrOO/ADzdIRdZUfMFBqAN6aCDNpx3VWYOYfZjoig3JqrEL 6gcJOiGQfOS6kfsVdUoKw1rBK/oc3Whkj+giocsGSuxarZjCeaFumFvZRlRV LNFJlU6bPqlmNdeWSccAHHB3Ny6W3LFWXwEhAC6ureTWYcxdRs09QQyxIbq6 f0axQdYtFZM32XGbm31DsnF2HVI+O/CuU9Lw4YtCkpyU2c1861fQwb0z2qm1 ttO5yxis01LotItcY61ygt7SHDHUcmPav/zoJenKWvrFDXlVddeNb91zXMpa BHJnkHCoLIGGrHDS/kB/Ywd6a8t9CJIIeP0yJz6m75Z6k3SSLpgUZ3yy+2c+ vUQapO3GWasTTxoip53e9Tw6zryz6no5PzHWq4EtuX7rciDXejwKx+mH5WOu eWsh2dMLLmJH4g3aWuludrN348VA+Yip748rgYR3nA33DxxQ9fNXr/dPuK5J DpSHhZcGqq2MStcLcO2NtDg/gsicV8locGtjQpKgAclJSJmupKctUdquNi+P UXYHi4UqhjxpQQ4EUIbeUAsNX92O6lJtKkk4bDcY7GlbYam9CbYsZ2taw5UA 8dOjKSQeP6+96JwsaXMPMWEUdLtByctnKaa1t7NV1PtipeioUp5DAjYC7RBH OS38xfmHl/3brGnMuWrecU5ti5pTwF/BuQHADgxOKmoHZ+XdwI+OlQ+Fnwcy FDvSug5KdwKjz/dzZch5o1RXXJdUUETga5DQQwj7pG0tdHZueQzmZyrdP7kc g5MionqqmMOZriC1sMZm1QM+o70T41FGGkkIZ2KkGSTCoZ4LI97a4hPI4BGS pIedSTS/4oIMg2/wjL4JkNM4h8MfBL+9tTQNpdvPjOXHskurQfTkbwfcRC/f 7iXbweIEn7K3M7qQ8a6sIMt57a1woB2pky6BI8HcY3Eh+ctgLTjhbg0vCtvZ 6txRfdLqBKGXMAKgc8ngJHOAwj3f9daRkumldKwPylgDl405nJCDLDkwXuOI Qy0G0MwhQ+n3UUQKZ7sS16t/caZxqIBpOYg0h3eJiy6QwrVg4Si+Bd3jh6dh NuTXPs8KLqMBBnpgz97nF4/eUaqC4GIyEi6FCmbZTIzionFP1Y5VAHprRCNr 6/uwl6zvQhlJvA0Z+MkAI1zjM0ZiihUK5oQp6rSkkIa3kLtGalVC1A5LmFLk fY3fXbzAGArGGbfKeFrxbL6QrCiGPFhF69tBl1pa5gbbTL8yUGrOV0clVdNh +khadaBtmVtWNmb9wAbmItJaCnlQf1oYAJUBqOsCwbeu+eKuoa/SjJlyKHtc RpcHCYgUOR7uMy1AcM3S1X5FMVFQ+cjF88sGZlc88EkumAYuPO1AkkRG6F6L 9CAbiPVdbeWum7rCVWx4y3ilXXu0Wiwvri2pXQW6oNdHzcd6hjTmFDXdAqqd 8Z69Wqa0h5osE4wAeMgNZKZLqQ/as04mVcY6L7uHrQtQSC6Zuae6ltdbsTKs sV+tuERhZZrMukAxkjkIenUttTiFaIa2+VXzM8Q9CENGOywXq5bbwIDoBfWY lOS8djLbH9W0VgCtRcoqFb1bLDBJheANrLaw1ieTCvLipfbHgrAMC3+YsWsE BTg84dH+VhjOVCB69evZzIAH4t3lat0A2s9KUra2m3kbay05Jyl+c724QTuI t0K3qFYM9OdCWSn3uM5M9wEYyFrNzbbV2hRhdU3U47qrCarLbFfHw0O38jIs Zzed6QEfeJ7ST8vsR+n1zJBygSTv2q1qo/oU03VdNbBAVUGeA6ZM28QJpeuo 3SGHnlhhWODdcgDk+zaDkfJRVToFvM2hTSiDFg5VJ4ZUywu480rWISgMPA8a boRJqFtbcsdD1TfRHQr/oOVJrQoqoRZta7FOTs9PXyQ7aZRrHOjE2kHDY4CR PbHrrUsemB4KTBCYafGzrLQ/1EoZUYhJE1xaG5CVQ6emTdHXk8LFO9hrACFa WIV3YccvanHafkxX77u4OC5qK8tTcn1oGycsdC+Y8yjCNhP71Hd4wdnsL34O rNdJmYmuYY+xUv183M8WoCYQkaLcGJmZQADyoFwJ5otX+rNo8QrN4OgSL8Bc 2gK1Gi6an+Zg8CjoPCkuJTqkRUlsS3xFvyDzGa4irT1s98xCL+x1OITwAKio Y89wqH2Jp4Dr+fWkqjOkBRwnbrpkSrSoHT4HmxGM2cdOjKirX/2gS6s9AdhF 5z++7J+9Ffimofy8tWUf7jAQjXoHlgUjGcTuG/PHamejVF029/ffvX3/9Ckd SLZMuyzRTZQTz42T3LbPC9fOfNUT17Ac0PGYQb9KbeEoDgpAz/QszsyjRhMW RnCKcBn4sdUobxiC00Xsbfpu+Tycmopwp3S0wB16orGYniDKknHiqHcqkO7X ITuZ2XJxPkNybu5IDBdAlS6BIleELRAGCsfl4bl4YbX+21Qvm2DgKBrakutc v2a1AaM8qQVmxx49CmFQ15bQ1sYUnFBz7lwn906nZkWgOtpC1zIxoo0wSN4g kUQH1rNd7le3KkcMWFrTyils/UP7s0c6UsWmd1YQvzKctTzwxeMUc7uGhxZD EOtFRLpBbXTddZzTB7x4X+uti/xzhcNDthf0uJeG7gWDaQfRDBfwgcMs6rYc fAV2VUcjbL6M69pzyKy+eJ56DqI3n4VxjV6IlGE4B1wurs4/P2ebVciDv/wM S6jiq/x4cWdVlQCf8d71GAorW8jRcutMxHxwqWFKq1PHOR4ZJYvXSwthdVh0 HNgfl04kzFOqvkekoFdloV7paDnw3D98fxsySojpbh+RmnE9T6F7tbyMXZhK MdZh5GZkAKHYtdjhUhS26Ay20DYJ3YrosOZaiW47oXgWORy3nUbgoOjVzUha pULFOVRsaXKjdosdK+yRVBsrV1JN38IbuM5IWItofpE1jCJDL4sBFGPmcP9N 0K6SbB3BWPQ9OkWuPgBc9UALR22i6UBDGbzAEElb4K+4WbqBJm8iSNJzQQe0 3oc7b9/8dL67a50R2QHRdumvIWdtv8zTBg3d57nCtZ+OgM+LSvo3qyWCIAl3 xLF0bou3AtxrtaRnXWe39Q27D7gdg+G3VNkfdE25NEGPbiUJejE6XjiEnZdD p+EbnokPGTh2njBoyLLIwcBIWURWmRQcWiqeAeK5tzOJ63k6mxlEbB3C0Y5L B3PL20dARARaNgDXv8nCY56QVZ8Ly3ZbsQXypL1TfTtVfRRP4LsUode0iMYv A6d3+qw6U2YMYwlGOjEw+YLBlBLpNZ8RWQ2o0+9IA2Jk7HglYClNGTn9L0q1 FNHCNGSlJ2yOxwWajEQXYN0ceXhNqMvmXWJ3ceDl05PPvoTat8tomdOGZAr0 ytBkcLWfYjD8g7N2ZrS+NdFvBla/nPfDKgY2GtYXoH0Gvrv8naB+0RT74reL 0Ru9HrThJHzHbTB6yWVGak7VCB/5XZrfLAvg8wF3K+jTmQbP4VMTJHyaW9+h vzpuIPUJBtmsBT+Vh85QnyWDhuvpJ9MSmA2zzLM66+ZFx6pgYCPhMQ67T7U4 Fpp31m/SORG4XRRHtBvupTqHATSikd3lE2Ak+2hessOnBOj4U6cQeiCjZDFb trEP+Itda1fpmx/RfnYu/GDojOSKlqi+fapOkbU63d8CteUArNc6PZo4474q E1HfHRkXpRlek/KuEOhTT0lORrKBIWO5QStUF9nOm7qNYeiO8FQUkA3n16z0 UCO0zzo5xgaO5zNLJEzlWjcrezUXOmM2exohRcnzNXvx1/BaYLmGktnTLACJ Sz3OnH5pi0NrD0RUIHbF/UexAn2F9fHm3rLgCRhGJndPSR4fc39vI3JfiOyA 36xySnB5fH6SgXgiBZl+AcYtUY1b30hSFn3Pqh7K7/iYADnpHzllh6ikZzBo LgQUIhRA0V4Dc414HNCaZebQKIVXttC0LMjeQv/lrlEGqmcjHIANSWDCIUK7 2iQpVY+aZ0y5c1KHkDDQFx0c3FGmwbf6qPm7w8MkJ4gMVWw2nhqTLimLqFYv UDE9B+QXTCtJPe8cnbU2XX9vsjPkfKU3F8+/B4bmrpgRZioSSxWMUKUt46lF 2Qgim3pE0UyQ2YMDzvqxwta+z8YmvlzGyBlL/RxOfhY7Tov0ndiTZUNi6lef DIO9zViWrkF7J/ik5XhlgAgMemWwAmRod8uCl1ZjS8Uq8Gr7Du9tR9z9fQD7 +sl4rwtnZ0AALhzSgGNdYI6QUgIN3o4eTpZrmIDatcqj4EXChk82iavlAj8e /ufHx66Y0jnlxIAzmKKe+h2Ny4vvd03H4LPoob85Sykdu0SX1vWS0qX+Fem1 xHv+4PBpMsqbCHW0lxycHHZ8imEdPnq89o2fuY6YFdGsaos/7o7FaPwt4L9e Ugt8ePeB5W0sF0QngtMlnEJKk1rjPX5kzkvsdBvNF3GWC5te4pofZauSJVrJ bcYlWmhnJYDfjQB3xa8YuqrCulTOxVLuHNtvqzAlJlVHyCwLnCCbncDiuop8 uqR4zdCoL+rfEJrGD7mMXEeKuzJ4Gfu5n9Fq6s+9QPhChahcaJljbbLvLbDb 00ytrM/UCu9n+zLz6N9rD1mzaBluGM9783Yo0ij7Z40jCACzdz8nQyHRDu7Z DTGK+QGvSANg4G1gga/f9Ar37JFJil6ApP28xXV5cOEOjcCeKiDHIfDwgxDF IfnWwIBdQycux+JqpYtC0entdqCxCorp+u0lMMnnOeyvlifOdTp2nm8ib0jQ CIDPek/Ie5yuSJKVjzDrUQzoF2CzO77m1EH3lfMWeh1F5GbtwdNZdbYmj8Ty BtFyO44VT6vDx+0L3eWUli49BUY7dzML3RVztNBQbHTns+ixKYiemWr0G9OP DboH8LfhKQdqcx9TiWeirg981n/7QbbjcNiLMl52JVadXK8W6AiLZ8h2ug43 rsPW1YCkHgK+HO2R8ZVklRgEst69GkQnwtLgauuDwChD8hhUd/uJhHjimICp U+FJ8E/DK9tn6Psi63+AFhsdpv73H+AbkeYHQftGfsLboREpeScacHCoxBeL oj7TUdqcIsnrbnv7YF8Mbjd0VXH9vuU5z9IVpBp6RXasKEYVxOFc4Z7Lg2sZ h4bnh8QhThcqJAgbKIHWxoZVkEXmVWYD1Z4wWwC6vMuw8WPW4RrQbuvZTD40 Pi58d+fgdfw1OrJKT764V0Eev7I1MbtrwCTR8CqXPpAMg7/FBcpF11uOmJDM DGml7TiYpO4lnH/OglHPojqHfLqb6+XntB99Ki3ki9iwdmjGPrOeoUTEBRlt F5dK713HYadRrpmlVbbA/ToGPWPau05CrIechk1MpXc5w5TTSzifJMQqT/0j rUm0gVQrSr0DlKXzCkqlArDOPMEjZJuYgRbjvI4KJr7kuKa26cXYVNp+wxR4 rUkBgWCEnianAxeo/sEFM2YCKtb1FH0nrRC25T179qAGRSbOq9PDPlRMmiD9 /Pocv+z21JAP87hVc9g5PMa1R6SurgTZwxgG761r5j3BIHyPUk6rJeb/C/t8 YkmlgiRoj+OBRNVgxNlySTqJeIh0aD8xLkiRN7/GftcdKThxzKbnAgPHg4Pd ZA0DF5vXMZPofEaNofjwDZJLbwroQ+YQz73AYfl037udHElc90OzG3hlzdYX BX7n8vWuqnFCiJ0hfWBqvZPkyqS6F+rtrhWVRUyjda9c3WvT0S/gzk8b1njn 1a5fj64hyOvlOI8yRAkd17YcmDYeOYeaWoTyADg6M57G29/SFmxT8I/J5WsU UuOvn1BZ+Oq3j+ifV78lucP/yG+H8tvhIxSOcumq/aV1mA/+Q2+h80J/HdJf B/Tf08dPj/HP02P8c7K/z/8cPOZ/jui8xLfgv+PjxxjD8WMeyvGTp/zPyTH+ eXSwv9+6BU86PDp+in8e7fM/jx/zP08P+Z+Tp09bt+Djg8MTHuOxDPXxAf/z 5An/QyOjW1xDFyQy9MF9trZ+kjCnRJnsK/EAp+DCV3PZEBbAz8XRwInoDLTj PG+0BZ6vnCnCoWCRxMtaWgu52hzuuegzUySAC+FhtW/XWXoryeUIGDdex5zN JNYcPMx1nwhZnaAdy57cMC3OQmBfkkaqJRCDlkOReyl0yI20Z5MX0aJTq1Hm NHTp+OD9ldqYqwnz98N3cCOJSNmVeJ6h/9xs0AmI2JN83DiDVpoG4FfJsgeQ PdGMY8y6KK61wRwR46bUbhK+EURsZ6BW6YorWp0rjINe1gIj9H2WhSoE4kZA rSP7hHzkK6SldczxK2NCVCsfi1q2iBS+hqU62BqxNxH5Fmq0xRsh6HttEOnC GJ1p7HNTfLmZYVqE/jL2hIg7Wc0B7iXrCmo6K6dgdVyRNTQLGjA6x6y9V3ZR lYgbjFRtUrtEdcSiOF+tzyHgvYGevdFZlthFV4cx3eeuxz3XVrk9WndsUp3E 2CVRp/QyHYeLvmlgmax5SB/Xvtz3YfG1AArIkUGff0sqmatoDTOHpOSL/f4e /RwlvLywwXFhtwz3fOeG9NgrhdRSCpB/8uPwucCHTUmrZBNfHDVaayad1WW7 RIlJ2Ky0XqzscAJ6br+wFgnJ7+tdaEfywTOwEXhQCyTDMwAN9/kx3mit0q25 N9JtM9cZwPWI9DdKeIx29bvSIOT5YMHtPk//UFrDqg5QFdeHSV0J/jhrxpXh y3A3Hf4JprY6h4xLdKZx96R2A5UQrFVox56yUr1aczbkfEhBQdZwuli74stO R1xmyIuOaJjkjFhOi3aTH/h21aK2f3gzTA4GR/yQF++Gw/MzZ7+0TobxfN4K dpvoiiScyaYO+mP/DszLZRNqhzwjj+0S7sMD+ENruhb1oXZZxXqoyCBaCGmt SmNn6HRT0k69mcyj2TWrXyfFXx3vH8H459B/3oQ+ZtoMALALkmdNpAT5i5Yc Zy2oRPuiF/CpiwqAMOyzaMHe6hkZroom/SXZORPnHCCUHz1+hOJ/N+c0kCt2 tEyTQyNQQ+crbssOoeYcqdLRUc6/9D81v6oUrdAuYwbpaztcnMGqOYXcQdCu ZuRDC68675t7pfm3Xc1M4+SWkJjD1jylnhp19Zq88WMLagyWtT5HmIezzKTC zoFEdQWsXPSjRQ51KbfpoWe7DpMwbBnYean55ebhJNU8m7RFpllK+u4gxVYV fzsba6Mypzc+cwZmm0JaWhGsRzx7ey2XV1lDkciTbTOSukLnzP7gwa0e8sJz FEWTP8MyW/EJy5l13ocNjMSVka3VF01WBYmWds8K04ziI9HTWgHNI9KFcFqu qb1ORJXSqIx1zaK0zmyrPENMJHBrWEpkyy8SJvTGuhgXmrhUjBFtv6kGoVrz R0RWSpVcyKFTUsCULSW3yU56e0ngg7BNDAWvo+4wKOjyAf9JyYuOfLC+izbJ 8brL0ptCm0g3LWLW/lwzwdaoxRJmaH6Aa6naIgbfl7UKDlKrHk+jLSGlcXqa ciZIbzk31dIOS3afXoiz7/SpveQyWJMPcE4wQtn9N2HQWHtthVFTzgsiciBn Rz2J/ksVEw6IJGwCC489MXJ8hBCLU1E/051U7KoPrLMcogdVaex3iuPajo26 EYTNojACHzdDl1QBj+ELCmWJrAfAfOCotFOcqxYVBcpYcqTil6tPMy6ObgHQ +fRTS3SU9IMaW9t1nNS5WPEqPVRdQXRx6ZJh8MqwllKOfV4lixKIN2pUiaKr 2MdjDcNqA0Lcco1mKdVVWjjvEbftsVfpRNX2hCNUeyM4k7e9AtLQecpVaWnI CNrGnFRqqrFTWZUrNGFutaptIF25NjjU6fkw2Tk4fCphbQ1iiz8L/sY9+uso ipBKeCZAUcHoXWtD7A08EvejMGjOXTCNI2qX2qk4MOXhgAj4I+0nf5De8DqE WFN4JC7eOdw72vXxqQfQqewP9ump2xkPQVvRINZgrJKOzx7+8/V3RDdv+Tkc +KFh+n3kIuxsIPtuJyWkBKz/6ODQ2Lb8rHy7b0tAcp4ePt2rPSXsz2HwSLoS +gAvGisGO+2F3e0YxNofEST94+OHViMaxFGbErRR/yJKPHn81HSL/uNH3YQ4 OXSEiAZxHDwSlDh6eiyUoB/+Ekq8KwOO1YiEYlmMnq18ADoG8ahFCV6FL6aE UuFg//DYbQj5RWny9EknTegtoMkfo9ae/V/6K3y6TX9tm3AS+Hmxq02uWN5X 0AVT1Fd+uMYy+ocKH78x+rH9yzYzFXuc1F2z0EoZ03yX4z6c5L1T78KJVVux 2/ZqG2k5zJhi3jogka6ZXmEdpWQWj+d1vyYLqhjXfSStIh8+SCqbWOZFsd7u tNYQgW/hIkTRfJzuBp9S92TulLVnWt1hLqINQoAskI4M614ALbAtMHXbRg9N 0PNPMvG5TRSUTmsPJAdylzairlxoiUwtryYumkrH2zAhie6eac291A9tTmoa JM8RaFeGY7JIzZH12Ix5CH3ks0VYA9VqXPtiB+9GVrLup8Ln+g02SSQvSf5o BdQuzrOTFxpmw5dhr+C1b4cxwcLvuqTQFwmVh6/5a74NLtuSIIqxgHswiR4v zScWIfQdIhUJh1MOnuxrpOOhe+ronidPERWhW4423kIMGlEWxExOEEE5evT4 8fFn76mjew4eH1qoZ9M9YHpuJhy4OT6xwT10Ux3fdHjy5OTQWGebG7T7OeVS 8wIIpNDTXmwupuBtm8FjwLhJ8aarex05hhyrcDgte62jsmHnt5Sxlj714Fn4 zGEArPKm0fyVB+OvOhFfcyTsz0EobN0fr4W1v3y6v9+hGAS3Hjw+Onzg6yQh habjCXzZZ8flNcK1cZ08+cy4Dp8ePPB1kjx+/PgLxhXMLbx7TUG0Lw+ODtbI Ed1Kx2+NotG4Do8Pu0iebNI3O9YxILkb18HTDmU2HNfx+kpH4zoAp/wLx+UV 2rVxnTx6mF7H+5/ZX0dH+yefH9ej4GP/Y6Bgtsf15CSYSseth0f7jx74mjfg F6xj97gCLbg9rkddxym49ehg/YJ4XI++ZB27x+WV8PaXh49OPrOOT0/Wzls0 ruPHh11HmscF55ZmB5Jggr0MdI89j1SR3CKfPnCqMvrHzuvzf653w8vuvwkL IdTPZUk8LpsEydNaUKHAv0FeopdzDmEkyDgKM0B7TmELBsbhqAjCw2KZVgjv 3jxe+sbzQZrwXyY1XQwg9opZBCGPM+LGiONmFbznUiignqN2DYPqDHmFzhEt 6yF4HFbHVi1SB3xpgs4nzFHaOLcH9YD/lmqA/TmLhxJd9Rd4af6+WkB4TPyc LkkwfXz1+sXLj2bSBAf08Rqrax3fdR7dlradT0iS5LPjenR44MelmoCXth1M Onxxl4yPuWHnEz4/rn8+fPTo4KRNMPu2ixxfR6/uJ0Tj4uF33fyvr815NaBj XP+K2kmypn8E4/pvJG03EUztrQJM5AtY53qO8kN8tLeJiX6ZLfX34KGbHQzJ f688VP68H54e7h8/ddSSP8pRN++Vrgtiw6DzCUatzwyLk9j7l+4ZjrN3uri/ irNvdJJ/nlOtGXh/b/MuWWOR/Kdt3v29rbtu/rlmRf29jahu9rlmRf29bagN w2rbKn8nU+WU0SHGsywNUgyDoEPPa8Ithqx8XctAZitBRI2zLbX8lruAxEpx vReYIRxDfVitN3NDS4ICIMngOWI6jBVDyepuHS5Q0ByiXgPdvnh9fnsoiUk/ vri0UjDOVmPIBqv596k+QAsdX8Nhzw1m4YEPwYRTo5wku8jzrU8fGvxNq/TK oxD4JnJa2O7yE7gHA5GD7vk4PP148e7ig4OWJLKUBu6bKCppvczQWeQfACJK B5iT0VxWSOpxmEcrj9sotclBM1duE8PhDs6onGcTDt9b++DtoCfuKHNTyUIM 5vU5OrTOgY3v6AlATsOcMJpC5xsZXiitgBGpXZpB3ghmM502mrAUkIyI7i8o XJK+DvDj6Y8fXgXUtH46ui3kSNzfDy/7B6SN9o+enqHfsFrgjwdHgyPtPix5 kJs3p+1NzpFymT3R8H2yfJnUCyIs55FaMu0CYPCNZF9WrqOv5M/VkjgMnA+O vKFAdVbWgmZl2fyMeMsP4eQPfL9yTx+XhRw7fkEuCOc2HUnlkGReS4gJRy5g ovAS/KBeAkw9lO6KkDtUnnH/zeUPH7ShpYLRSWY6ltQjMVgVRl43ig2q0NJW hBtBJeeFZXBL3syaK8N7ESybJvJshF6GKtN+DdzeWaoWDJ6bc1XMPWGdmFw9 nQIldL/YQxu/V9gAtBLqSdYNQFHxHhsPT86DBUoC7EOjRmo3kU5Bj5Dj6hqa BzFgX34cIxAy32AAGME4CUELc9PHXeo97+1y2vAvMZ6KSza7larG65QuXTqU kzmOg6ssA4oZUuZ5oCHrd5NnEC1Bp5EU3hi8ZbS8qrn40qXxMcuWrjUi0ILH Yhm7qafnivf9iBMssxpAA5xZH9Z0cI1WnFvOaY/c+dOnH6wW2AphBHxBz1jQ 3431bBKYsHJWXq24iFm6ivAU/Ddup8XjhhssmNfO5Q97H3ZdNyyFquTyJnxj 5+8s7h4jB/CBCzx4SatOcE4vvgJ35mlv07a4RTZqARRI6wBAv0h+wat3L964 JYz6TN3fYxOgjhf4yhdTZesJBC6XvinKo2KtT2fpXW/tXO/QxIMuOw4YTAtW XadYJIz9+U//pXaNNeCWFGxa9BgxeaPD5/LQzRPbdcP90MIDrMqbrDDWNV0y 7ydJe/b+hzNNnfcT7AkIiGJxWB2SDDwY3IwTzT4/ML4OQzu1ndBq2GeCw7mO 19oJaV1HyvkQAO5puHAcfIILuFuDJGYH5zM2O5cvyVtZ+F1VmRwYUxRjFDqu iKQd+u+x57TBH/J9Nz/hWSLOWy6BXkfdt44XlkqdFtp2LxBYXW0B8jARPUAG CZoOeoQb7msYwqyw1seF4F1DbjcSLCKG0MxqYwWS4YsSXX67dMV1SfKoz/D4 9VdVuVzUAmheq9xkHOImrx3OvSK18NmOuIKvWdVeH9yQhSvfRfDz49GCJncI 5yFIo1YQyrAlCVmHK+BP/MywuYDr0CeNb1YhbY1jr/WODI6xrScPIVp2PWNc OIlHWRkLe3JosKjFkh2W1uN08pfuLq10WyoALdKaWZCmXDFIekfjKio+s9V0 Fr72u/ug8GFzWvQDY25tL6k/UZVa8O7lha4milsTmLpptUPJ7zSvC33toC/v 8o5iXGOcfQaxrdYiMdA4tZmAQ/XqUnqCqoXGURimgWTp1oHBMJZ1sp5hadQ6 wqNoHA7ofwp17yZMC/07xKWWIahmsCi1bLMvY1UsbxiHGwMoudMmrD1rJkF2 CKPuMCBU7WAjZM9Gxy1KQlY0rABLadFdv/UZLsGFuq45hgeuxlu4Gqu3oc2b IfFMfImNjGUT33fs0Nh/uAHaDTqydYXjNCrBCvQNJVKrRMupGx7KnKYM9hL2 LyT9G3DNXIg1IgPlhisTGd+dljlbU12xd+LN25PtHUJrB40xTDGtpUXfr5nZ jB43W42DUjCqSKBLuxDuvDfQOK0HftMq2tZkreKok0d/Vg7789WWyBFPiB8f wLl2JGcufu4r62ky1B8jO9O6Z8y1GwpNmcwMEFa60z+8mNo16VV5B1Cj9mg2 XO+h00KA3o0T+ZYmjgRGgFEFaLXqBQrhpXwnyO4N3ZGuSg/sa7+ZPj2iL3g8 GDgU1p/k+He93QAxuRxNbQqHhcGy2ZRQZp7cyBnY4alUgAHKrpFPwnTKZSEg LlA8uHzWN2LJ0IFL8PDpNX1HTIcB/4FFJZLhqry+UU+LdsaV8SpMqIPmtGi+ fxaQEbVomCtfUykJWm/Zi25stHjgm8+hpi4A2eKKLIOWEsCzT3NBNV0jIHdr NfkP1xpXF62hGbN0ktRhbT76/dvL74cXH84dnuT78x+H59KSOSrisYwAgcgc i89msqyc3qcAUcvFFYqPPNIY8whm/6zYm/YJsAbXttJVMQe4B3cAD5HfDCc6 cwnYmoxdhEixTctCO+3mmNpPSq24qFbVB8TOfPug+lkLNV46CCm8l/VS6Xxe +JStLenGxoX2bn/rkdXWyKk0Bw8OWril0zbrY436VkW5aAIur2WUWy3aXPhc ZBQHhj+xZfrK1ypHbZPSDT4AQzHoVmPUTmA8f2SYAgSGhnWHcvtUWl9bAZwc tqVUgLp6qU1uG36rT9OJ4OFGjKsk3UHqUlQS37VgoGsRVe3WLbhpBwbLprrs QjXjdRVMPkkPhKAFtzmdAvrVVnLIDNpagfOj+QjU6Zjz04OKq9FSkUUVTcwV U7LKMyLudMc17QYnkbvGtuLeI8HPHzECmXK7eJFYiYO81HaIEaXxpfS7BxkN c9vXdkqGsGJRnZn8g6rMlFzzXHrmsrX1kwKC6hrc6D2047fp+dsKPqkSgKv2 +EwQy62zqBGrcnrxPAkaXuJksfRnM0wysDA6TniXoon4DopurafZHXe3EWxH erAdKCf4pH/S64uEtq3qQD2xZ+hzUWQNloyEhEM8nWREPEEk0kFAWLFMDXv2 fIBBUAae7j470nxFaJ9B41B5ULMjJkVbWJ3vdligwR9mbtrbbgLbLV2UqzJW GsgIuy7DLA2N4gnvoOiqqAulgkKwWclpepnofO4gh2OQyFbtVy2chuxLbswb tAfmvt8NO/rNGxy0SGqJb0BvOjW8U4FxsbWgw5Q4fumhUmhMsyZDVuob4WRu 3ewYgYG8oOADAq6XcHqgIK/kgSnAuxIMkWsgJxEByhHX0LIzGxXIQKyGP9lV fHfB+ih+7BoCywRKb16rNs7gF9DH2ZDkel6x5chSNT8Cz8gFMluCR9vAj9Si 1CZbPGz26jt8P/V2B8/1QAVBvNH6nz/wXB8AkotFNpCgulPfy4itL6kpwk+R 66lnZBecAY1MMAwqAxDWOStsqkigk3DzJeXKvbBnuFaQ5sjevCrVs2FNfrv7 SkRjVNhZvzECAoGKTCHkBQnvg91WW0e7AOhCrjQyVhpwyAtlRu5EaNveWhmM EK7y9wku7jLAQYLlPoMFFTXmNoHuaqidHhpqKgFGni0w3Ksk7Bn8BB1YorCy blbWXMWFkmoFnff6bEuA5aosSUSwB/ZqWYXSlSUFC4meii4GT1cW3EJzlsOn DbiBH5ltR8LCWboetCKS51wcH/CVYDiu7FtHtRJgDdgQaIsB4VJBqMAWUQ/H spK21PRkqBW1C3g7xuIgZD2WgRTxqJXmxWnMKCLrvdB2nxEpZQH9Y+G7QW86 5CHkHMXb2bbP/Hbd3o3I9QfunPZ5mkFSgi9sGiS9i2UKfRi8ylohgxCtNvHs VxT1XzwDTt5EdpGANGpOQspzFiw5gasX9mfOHa7cWzJDHiTnMP6QpgGuhpGH j/VUE8S0SdQvQ7orMzySiqJF3kgTR27DVhaGbhp07iU9iDPLcSBT2WYIWSBu xAWJAk+2NpKbLFsopn/grWjKcibMV/hkMWkr4YKZYT5hDr2zQjAvbw1rzfJA WH9pNfNjFXbM7a44pFn4dqFhUEEB89kR6IokQ/Bya8MeuAqrnJ3J4iYwGBx+ H1/E7QHpm55Djw3mLavBDJw1JgdlLikfag3VWdQdLDUcdwhf5V4wMPIxbSmI 2tClpB5A1+gZnL6UZsO+aSmTT7daezuyohSpAOEEeEMLLA1HmCcBLJ+umQLE sJZR0/HUJtwhVwpfyU8U70KyE3U7HQH1bDYz5801bf9ZRgKKlxUdGUTJhxf8 PetVXfq9uArQDLWrXTEKsHsM0wNiMmZxcGTNlHVSTdreY5KsB7JiAOQ7zjAR eDG5BaJPLs5rrTk3lI61sLiD8XcbGmtcjmmIWgdc9jWBZ7vbG7StbgbjEYYz G3rLvN1qsu1bcd5oZozBRcFnTXbGpL5mcKgQ23m49/bi7XkC/yQSrqR5ulSZ S6oTmWnmGZJ+ZlgUZmF3HoSTR2iD6EVj8KEDN41o6DqAaPtEzBGgJb1gSN4M iLzM09IbxYE7062Tg+lMFWIu1Ju4nZzOR1YbLmIHDkhk/0/3733bvP/0KYxN eOR+QzWRLpuLBWlttW/JqAjqgeHk56ygVNxmt2bV1nkf1UtqAHikR6Ab0WIh gHe4ZtsPQfC/RAws8kwQK0VvFgQmh1TbnhAbsFU2LzUIpLhisfanvki+gJ8K p9/Ummk5hmzrx3DXULOimX4QsId0Yi10syZMONeEN8MkkjMCfD1hz5Yp5ZTd bQtEsgJWGxQNg8U3Md6AsFGBYa0je9shgYNcpK6wKzHZS9qkdh5o4WZB0ojG f9zb+ly1VS3n6I4DxctQvmQnh1hM650dNT1KNq4IS26pEUbEsJPvrktEEOBl 0+0xpdldt/HdRcVs25RINlsqMBwD+tcCWNoIdJEP2lqinAwnV0Hin8b+Ohna YEv490tJqnjB6FXOd/m9Gi/v1aDZegsVLWVKhRG/WHfmHho5w1pN2CEZqShv Tt9eDpOfvoNlzMhLcHVquZyGBh0D6raUTDh75VEIookhHtGRvWe0jBqIp1W5 LWe3gkhkunRpqJ2Sq8Vpdxda4F6wPxcqEU7ii+zWtbl7Jyl+9dZWK4LrmR3H O4Nc3V6QqNtZiKFu3UAyBQV+IYgVn8drRbYTkelq8gtNT5EhT3TIvGEFpVCT atE3CbotMwUu7XcwexflB6RKjgVVX9QgeWKjUVxJHlTtYlJx46MgR1kQlQxq O5tOS2142hjY1k42uBr0aCu8Pu8Rjd+fS3h8ki6aaNEtIax0oFH9cHpZcZtX ZWERwtMgvdjF0BWD7Aqanfqu6yy60zIFGUlVahxdBjJR5Y0sYQijK8qBy+R0 ktqDs9IA+S1ZdcXJGdaVSNsiq4s3TuSdlVf5mCQ6N2/0joOQbuyyWU7E3sDM TBHNNJSYd6+/otav582N+9f1PKSpanS+GiiOaHBE5CxMoiTjqzPFsM4l06CE V9og8yRu7AWqBN97sX9+LUky7E6t2R+z9K7Whq7aVBcvSh1sssCe4Wncp4Xh XtV5vesSLnuubUVneiiu00FLruCduBokOIWlIGYSAi139aBpIUijsYalQxso bvfL6f/brj446Cq47aOPdF7F2Wl9BlNdcAcYC1eiNE75/xu7liW3jSu6n69A eZHEVaQqsuNIViqLeXg0Y1nyWLSldQ8JzsADAiyAkIuaytrlhT/C3xLnv3LP fXTfBsE4K5U4JNBAd9++j3Pu0aaEqYcxn+Tx1oLF6exkRjmMZupHNvN463CE OD3WD2RFKs0fW36vDBuNWngaEqJVFHf5GJ6Q1J56vF6b6myl2x0e4DBxdiDa kzV+iwUNSWYNWtGk7fIENhyC3SawGVYwVZq5Ppp1MLzELuEeBfuiw4MTKM20 80osqicMSHWAEYUwBnH0OG29jHmZOPlRMhVm7a3kxcyfiUJLTmlyDBYWH56F w2sTZJaMoqxit8SRS+CO3vdI+shB0ZRZwngZwG0Yeq1cZUrxGV77EM1kK0Ew jdZYFeU+zfbxKRq7O+HOqeefkDLJbr3a35bdgh5Ya8/51xYBOcDHR/5XvoVN lg573Qc1zPQybEvRM43Lah2WO1upIj+qydcMCI9BrlBz5g1tNuq46qeU1zEs +uP5PWCIj4/fyA1skLCtoiOpHZG7UuC5HA4oHpjPsbgeVDZkJSJj/n4JIJ6n HGwcrxVe/FSGYv/9DP+Vgr599Dkjv8zQp5q3lAwpzMo3inw89pExTqmOjjof TJu7wP2mGXDBNYC8LaW6BjAxGzpS06TC6GEPpzqrNwUcKOw1fjevUNuB02rg Mf7xJk1OY4afd3NiAAYgRsW95jMCGpssPFYLfddhdhOO4UDEgXvs/SNffSYa HzooEEoNCBKBfK3tIM3ULYi7ZXCI4QaMmdQnkKr0akhucoL6RmKKkZssGuGd 3VkvZCteslhiJU2d0O6MO/9bgkcb/gYOCQUrtEFBBaZMrovPspmeaQ92GSqH VtuOZfCkVtXRCkE364hyrbqx1ZbFyBhwYW854SgRPfbWi6kxTWqfKs/MGHZR JTDKtBVzGcoiZwiakEeaDS+nXIlaLpkU+9pQR5OTT5FkrZ6M0mNs6LhQgT6J ddtC14C7m8OF4rtMJPTTZvQSqGH0NYRkDfg/TyCvAPZP5J30Yk1cy/MDRlAz bKRGwXJavZe+NMeZ56ctBAa/5rKNQkiXyuax6Hp6/FKm0kH6hK2guugsYX0C 9qH6F8UlVvQsU2/QWRIRtX4LL9ZgYvFZ+RWRzeGO9ZKsj5Go6wEbBy5qIt2K HOZVOdZSGaFPqkx7pVdgm835THI/elMVQ9/dR01iXzGzsq1kdGdJf9k/blZj Yu36tlnBOAKcwc3bWuZmoEEw9gHgJFYPdISlHbtyOix+10jOWm0mvQhNmOdj gCDdoWZlXoxLlFO71GGVJHLNOm7D6E3EnNVQfuqgH9KMBR+s+TEACcOu3XDx ZuI7+6g3eHLyxtYyn1wdO3HRZI5MdTzSUBxeaoP9P14NFXYXYtcCX4xvvIJH jQxGJxYvySUmsa/JwbvdoCJobH4iDtCspslemBkfRct0vn9NpqmHtI+czpc+ HIU1kjglacxn6iiW/EGJA2lTLVqxIhPLj2gXzZQIjlEImd25FtcivDrL9rOh bMIH4UNxgXT+Yz7Yg0XWlCbZeRCQOifOkCiOXHu7L/y1X3gEUdip08s+q/9a HwEwX9V1tYVHcD50H5BCo81Vzq9oMmmmZoUJEPP2/qHhrMtiJ1UXbXG/VmYl dyVf4ip9pCbqj1+WHQOJxj85Q9i+bVHD59+RU0mmJ8yKtwNZmiAbXOYxHz17 inJGwfFvwtQLiz6CJp36ajfE6Xev8K5ub4/+VsinAKbVmfwVu2UclV2vHbbL LStGfjqMSkpUI2rHU4wqpTOJXAXVzYT1DVRfy5EALJvUJeNssiK/dAhWoFYs vGULLUp9IFc01DS2kqwHzgv6tF9XmizIf+SojnyGsBEhN1nikAxmmrFJMvVG OubO6BtRxPZl2BZnqvL1P3nCzl0n5/3mCGJSGBcmGhzfucq8dKVUw+VsZJyX OJP7xEnlsEMr4zFkR0FoVW5Fx09yV6E/wuSVLjfjWJZXvCI1/Z2VdsfhWFpc sIi0I6YYrYV1RKATdLeDNK60s1ZE5CThVh+8UvVW0B0572LMhlmhzGBPVmBU h7n0Xcl/PkKaXg1apLsbapGzccnWvC53eX2zENY8SPNf/B2keSgcnF/7A/zx kT5AbHmVKg+RDD8uY7SmT+KAdCnDcYSCKoRIDTsp0I4cD8Sw42JtlGWQnWvs 5FLhLkpQiggItGsA2XoTqxTkxgWoYqeKThwi4yobp6hg0FosRhVFBSS1FXzz waGQnICpdxU1boSE7DKKEtUc4GHTWxYBF/KDaw6QIu/G4cNWEJJnbLw+TDpk 81zpJMemVyYiil4o5buMN8sdozA09Vt4hOixpPDguRObExeUvmQhuF1bUmQq mQkEJLODTNUhYYuFtGkVqCjofOn8Z7650rFmCaSevTzWuhBQmGrfwbZGnqab hTTrhviUhmwzg5wfAaQzQlpSS3qq6Tuty7tAMyLMy96MSdUMviY+MQBddZEs oryGlb8Sx5NWzZ14bjYq7M0FBDKI+O7JT5n3W7grDgah85RaQ2ZKkTffxZ+O OUuRhSAvQByLEXGc6wMUwZXzTd3PDf2HpNsG3OqPfAPoSPdwmpSjxydCJHDS F0TemFdvvqNcTD1miiHECfXIFCEHoInz5d48EO5DfecIYKNWmkJQt+SYTA3g T/aK7P04FUsfwGYolKgcLRi6o4UnAWFw0m5qTcsG6l33HEeMy7VRcokkG6sw LlLb7TFOP/VicVA5KbFZB7ZPGTQY2woxfJLMdVlvNVTHO4ovSMJ1LW9VTay+ SfnZvTqBhjB9w3Y8LWQlPR17YzOUrwTtIctw6qWl6p8yveA2MqyFHnoVZcHJ fdUOLXGMmbelDfVWkVeYrZaRCHj+LuOOceiUo3Ns+xKa2bSjhl2pG/LczWKS WN0ocPf/WmDGc9XEwPHbj4WYY2lKGVfZmzkgnvEB7FSFIqgUE/AhdMqHOudq AIVJrgMqfIpqJ5DohnFXwCZfXAky03VtVYyDqX1yI6f+QHU1BopkTx9URPuQ qR7BgnQrQYwzNjgDK7neWOLuLMO2h6vlZRj8Za0CZsfgGplDPeLUoLn4287E EjzZpWTaMP9ciScHs51LKNJJCmrFnFuT5vVj4yRjxtbPzyYFS+G5BdQRGITm KE70xqptJdurF/09KZ3GiCU4nLcNHC+hMe4ynGvrx8CeJyZ/4NUB57ha7w1c Eld5pRqQ8RTKzVk6jLLjLY+OLC/O51IePdMrv+fH07UghdiEitCFIVT41Xgm N2WQ7GezL5JvNrpE1uzJCRj4Swko5PTN6UE1/PuMDgBMRtPKN3MkMl/hUhVZ 3uqR/ifgakQK6+TklAHX5G22XNTSpkzj9MWiFAiUj+lmxWdoemQBCW2sr+nB 5zd0KFXbbVmcDhvyWfCn68XZm+LLZ8+fPnv6/Iu/fv78b88UO/0tmY3C4sdF WJfFX779bvEp2hmoeBv9Fz3PuAUIrahmrsbW5N0kWqrkKPc8yxyNoYY3Kmvv sifU0QDq8OeebOcP1zcMh8DLesktNCi8wafz9y9pNJbhZohgJcKNLrWU6A3c jcuhH3EDuhfaecIXxtycLoF6r8uV7Oz+5PGFkAvK1T8/WVP4WX7yr/F0a1IB IT9sGxNkAMMi36FCbxkgzjAdN2Go6QhZr2lFc76reeDXdEFffs/5skv0Q4Bt uJjR3+ky76u7O87PLgCWDPT0FDCQ6ZyfDxSkkm8zo6s2bV+8Iv+O7NED+hOc 0SQu8JM1/eKcotZZ8bqsl/fQSDwtsZ/oS5ehfmiLBVgWHx9oa1/QEbqio4hW dtNyDHdFu6b46uNH8mFLus8Zkq0QZoajtFi2u13xtoVRuAJUpqLF03GeC+Om 9X9JZonW/Iy+hA1Mz7ivKwofX2N3n1X9fbul/4S6+s9voXg3/P5r1VS//zwr /v0LYP3v9s1SRnVLI2prYBwvKpq9d7R+roa7VmR4aYTk3L0LyIshQLW0kFKY eR905YdKswUS8rKrdt04F0/8KjDPW+A+OWMk3jHdJy0IrSI10eRpHcevBZrm Vx198OonOjsfyGQ/VE9O/guh4D18vIYBAA==H4sIAJWz/GkAA+y96VojWZYg+F9PYU18/SV0yQQSiwMZkVm4wB3SHRxHREbm 1JftaZKukCUmM4Ut4ArS+3Xm6z/zEvVic7a7mUwCInN6anrKqzIAyewu5557 9iUMw1YZl4k6Djaus6IMP1dRWlazoJ8v5mV2l0fz6SKYZHlwlt7FqVJ5sdGK hsNcPeAbn/v170ZRqe6yfHEcxOkka8Xz/Dgo86ooezs7Rzu9VmucjdJoBvON 82hShrEqJ+H85yqew39HodIjhd29VlENZ3FRxFlaLubwxsXZ7btWWs2GCgY9 Oto/bI1htuOgt9M7CHf2W6MsLVRaVAVNqVqwxN1WEqV3x4FKW/P4OPi3Mhu1 g2Ixy9WkgF+yvMTf/tKKchUdB4Ozfusxy+/v8qyaHwe0rNa9WsBn4+NWEAaw 4VarVZRROv4SJVkKky9U4Q4tI7qTlHk8KtvBKJvNVFrCJwCCWTSfx+ndX1qt qCqnWY6jtwL4N6mShOFzksdlHgVvo1Tlf1OKvs3yuyiNf4lKgMlxcJXdxxF9 PopLgPjHLB1nKX+QVWmJp/BjGpdqHHyAycbZjL5TsyhO4PQimqAzlAn+NcXh OrDMjeXF3MZ5NYsSVTxGeXCjxuNF58MLVgSLvwM45bz6XN3RUx+iPI3K6D7y l3qRjuVlvcL7TunM+yXHedcu8zSewZ7irAgGo2kWp3GURvdx8YKVnpRTQB1/ Qe9zpUbKW9FYT9Ap3Al4UeFQJUmYRMNiJRRnWQn36TxLEjVU6r5hYafxXdxX eems7Touy2JY5XdTD4zXJ41HPSjhUhRBNglOZgpQzwdpGc86Uz39v45hshFM 5q03TuECXXaCT1VaAOaXPCvv4DK+V7UvYPnHQAHokgcfET5qTF9oMiHf0Wdw GZQq4cru7+wEgwwu57gMbrJo3A4GFbwZdHd2nJ1/KsvoMWoHn9ISsDXz99sH 2I81Do1hcR96H4Ld9/vufmew3n/N9Ho7AIxWK83yGQD7QcGlCy4/hh/OLo/p HU0IL7NxlajwY1SWAJ3wbVTgDVKL8CwdRfOiSuiogks1msLBFTMEeTqO8vEG DxPld7jHaVnOi+Pt7fQhmVeAE/Bo2bnLHrbxF/xk+93F9WD76mJw28HfOr2d 3c58PGFAwdGpAmkorw3/4ZMBPokkb9d8fPrp4hjg1jnY6R3S2J1JPC86+hFD YOhfaF6jc8Mh6RNDSffCnUOGy+ngRN5aCxhE2DJKgkF8B7e6ylUNHP8IPPYM PJYW2AwjD0R7+lMPQt74/IQPIgdGHpAGH88bYELXDQhUEZxHxfR/AUz2/yGY 7D8Lk/1XwQSeKfzbc50lizSbxVESAr1TwUkC8kBcTmcFyQrXOX74LhqV8CkT vQBAAyArRrkCCvAxu4vkefwqMBJJNptXpcqbL1mUf40fOrC0bYDO9s/4Tjif bh/t7xzu9N6svQiWPl/D/HnwU4e2Zb4nenjtfAh8HUSNEpj5cfA7eSzK/xQ/ HNfnfeg5l6t7dARiSjfsIYTf59mDqoPuJJhEQER/lh3PmMCMAJEiDUSCIYwX DQHR4LSjfDRthsg46USjGYFknMXbcNTd7t7+dm/3zWF3r4M/Dg5eCJeP2X3w oSNrXtrRG9jUSrgMbj/1g98cHQAE82yk1BgEEWJOwG+D8hGeXYQqvpuWU8CC tIKtnvQvUXiaZ0UMMAAUuJ0qECjxHUYBGKEdzOedoNfthb3u0Qp6qRG8cdc3 S/f4BOg5wGFMAP40LCNg7und8k0uCFuvq2ESj0JgCiIpF4uiVLNixfWunQWi qF7Z7v7R7t5Oh370nrt69khusjRKxsHHTnADnEy4q/8w4e0J4m00i/NVD8AI J+ME2GXq0pR3aphXEUC9e/RGKEvT6eKJzCpEUbzH5lzhCNvBQ5bgEbWDNIOf fGLd3k7Y7R2sJFXemfmQwUN71z8AJeKYfz3cPerqX/f39/Sve3sH8uvezi58 Cr9f3d786F80/GQFswZZhc4pTsfqa6eYlrPEwfhJlBQoEb7Ls3G2JDjoT5uH nuC394rRoGHMfhKBsjO6HJ0lMcid/tDyZaC/bZ5ixE91ZiNFT62a6t1VAyd7 d/Kx/+kKzh5p0LusgtPJg0R4/ZD4GoiJc6DcQWFvA5KEwMJzeddRAmgT4hsd POttF814PctH29vdh5Nr4fOOrDYAhMmqIqQbV2fD/J2nt7aDHlzVs3GMyLnx 8rv1BxWl4fU0TuL5HJAZFJCiyLzrcVLdobSLnHf5clwM3l4FcG26b7qH+zu7 h3tvDL0PB0Swa2vn735TGMLPZB3Jj6X7MYB6DtJ7lKwAdBKn9x0QT32Kv7O7 fT1dFDfq4QRYfaf3Zu/g5YDoT3MQQ+BS/x9RItqaAOATsG9Qw5EDHC1DAGck tgXTxuoxOBFqcLDD1GBP6DcsJuy92e++gB407+N2Cnp7Gd6oOYj3NahquYGf Qd0L7kSqAn4Yz25nBSTvkmwYJbD1e6CQMBxIHSxZENFnUrctZxWWvIRShg9z Gj7E4bdfDunLeDQFKTK4zApR2FY+CaiRgUoIgsEy4N/TyoElFPegTsvaa7Ji l2QQxMnP/fD0arACbIbXEr9Dqg7PrgDY4+NjBwCTpgSmDHAj3Nnthiq1oupL gHAdVQnoxpNJjRmxgLsX9noNl61/cnUVfJpMgEhp9tOfxmoS3IL0lGZJdreQ r3PQI/u3n3BpJJehCFvb/GoTmJbfRWRdAYhRkY+sDD/Ps7+pUVlsz3FYjTAj Z9jV34SFP+FrhPJgmbNk1XiSRLmq7RdfALozT1RUwBoCdzlBUeVzuARqxV6H ANrOyIyMJgTSWkJvT3qQV9wFUKGCn0CkUfkwWkKEHsmbDSKJ3WPwFlaGux7s dGv7PVXIhwijT0B+AipFMst1DkyNCJYj14Gyj+eB+skALucMeN1AjVCXi+4i JAwgN0Vz5E2AcFmh0qAfz6cqL9VX+Koso9H9CsgpgEhaduJolNOF6e3sdIFa H75a+uvn8FeTZGef/GOMihbqLtXcB6UI7T4QCQPpzqhrXGRwgozoQbXhcs6B 3jtLfXv+YeeozoWrIfxSAhkH4ZKJhpqAIE1QBEBfXJ2G/f7JcfDTVPExnGeP tDjczTRKEpXeqfBUGdAPFWqG8EX2qMa/fzlAj7b3uq8A6GU8jfPgrUoQgdY+ eapSwHIkU1MVp7+sffYMrWUf4qT8pQb6Bp75EtDrTb2/vDk8XNJfxqKqGOEs KAhvgbF6aBtptB0R2oaA2UV0B98Tzq5SYeYqAzLRGRVRnHRmcdlR42q7iJOH ONseAOsalWr8X3s7g1EM24mB3sIftPBiW3Qo/NbIjdsnX+TjL+bDL3zPvvA1 +3LC6/2ir9kXvmbhJa/3C9+x17EY0IUmcfA+S8aPINQ9c3cGtDvkzVES/wpt TGRFQM4EBKXDBqI1uDi5DP4Aoja8jqquo+CSwNR946lPvcNuuLvG0mPFpd03 28Dp3+x0kc9ff+6fXF/UWd3nfhAG8DlMUKpVp+4ztP7gpr89Ax0+2r7WvM1l maHLMkEGHVXk8dhWX6MZIE84iRM4+WgehzTnS45uLV8DLf7w/KYuwSBJKTN4 iChfb2fvMBjGJT4MRKlUd4CSSJ0OAyA78GtVoJDT2wlmcZIgyUmzuFiALA4v rQKLtTZFw2K7e7Sz39k5erN39ArROo/iu+B9PE7V4jl5DxAiOLtXeeRTEZTk 9sLu7jJasTHKLuthl4HV3Rn0a8B6C9LrPQIAweOwvBCoc/DjHOdCxERSTpbO MJuAyKvCk7xcIwz+XCGk4YKloIiKP4QEhu2hzBfmRQQCop4vrGgqlHrgv5G4 P+qQJGT47Iz9Ecb2gdI9CncOGCiwo4F92yjScT6qAB0mzBVR7bJKluBC+i+7 Lz1/z9oIMv/+ztH+K0lSqebTCBSTtyoCsncHMl+NW+yGO2joWnXO9enptD9e vP30uX4zPsZD+BDO9tMc2K+WcwfRZJWMBwR6Wg3p9DJ4xUp18AoonMPsZw/8 V6DHoncWkXN/ebnoAQXIH72ZHAwPUX37sICHB/G4LpaeBPhhCAJBmqpEhCm2 Bp8DeB5RyLtAioLkJdLCRf/mz4Pbk4+DkIZ9sajQ62139/ZfYXr7M6wK0eQP z/CEKv5FBT9F6d3axz6g0BNc3WXrJQkQjKLgtBrm2cN6/fBjnFYFyNCj+6RK a5jUpEC9QO6wEBpEqw6swAMbyYFFzoHNouJejUnWK6bVZJLAH0U2KekQ46VD pBnWWTgKPECg4YSUSBtHiSJTx87Om+2iu7t7CBSgB1cG1Lz9cPflx/rPPojb aQZ7B+4OQKnbj3q0wr2w6ZYYcWDiaqDxyERZOOLBLssFe3u74d7BzvNywUoY 4Zn263aphktIPpmaY/TssgCcAdBlJWhS6gF2AR8PF8F5fAf6UPgpHwMaXUZo Trl7zbU86r6Cob7s+F54KV9+yldxUpDhosirf9pt440LmBuu23uVomefqaR/ 6eiAQMUKRej37bfXH87oJsKZiXKwisMtH0j3aPto7xUqFSjVBawsCm6ih/WU clD9LVvAZtIpPJytF4dO0moezVBXLMtsHo2ni2j9CwOALrzwdhrBnajLCr/q gAwgLkGvvYOx6laG608fP4COe5sBjRsXwUeQeEBfCW/gVqJVB26JZ2aCwxLD AlsfAt/68Jobc/jmFQSvn/z7/0Taq01u6dqn36o0+/f/CyM8hjo6ZeXA0ygH QT+4zGbx+kGFRpLftVj75Ls8Sv/9/wTJPPwToBOcAxvkzFL+8UvHsNNn2quL Ts4hJqjiBhikg3ouCqxMCU8qDCIq6aMxn+JXvJ2gW4O6VGajbJXtPlZKfZ1j oFQHfxUTPqtP20eH+/u93rNme/Lm3XaCEP53C1r6qkcG8Aj877xqJoL0zJ/h mUscRq1/5rwDh/3cQOc4mX5k3TldnJ2dsWjq8EAy6IrrPxhko1iVC2F/wv1A 2Q27ey/RineOtj/9oY9BDr1eZxdU8h3vzHfXWYP9w3U0JW1WEeuEYwRs4p+v 43+v8NVcqiQuiig4+SWroqxaT3H/XCVxFHyofske7p+VY7JhHFFAXapgQ+tN JuwxQjfLA+iPf8zVWMEtjZJ/HmdEkPSvBie9cKcuhKZpVqUjFM0FaWYqH8WA RlckXqIXH+lsXC5sUIqEnfU6q5xBZO7ojNVEpYUiKwgqN9uX0WJ7dwctjbtv eodv9rrbIf3/znZ/cPIFF/gFxvxy8vH9p5uL2/PLQef69N1zp8nGjsGJC62B mpdGqeqJWPAuipNl27ZBSfwa+Ykjs4nlVZuwfRFusFYUWBa7gajBonIjdh+9 OQxBmtzdCbtvevtH4cGX10huf0Bva0yhN6e/OUkfnmMFn2NArffVekGvWfpe JVQk6itwE3Rkgzj33NPvEKvz+D74I6BXhHRJrX/hIr3L4zE+Poyqxym8XZdD UBfYOVi+FEthJuKNCkGS69ObbRAvRmTsvUKTGhq2LLVEW+xIaWWhC2oCU8z9 g/1w/+gFFHPN4Wo0rDPKzU+p2jIYeFGQWgAH9mnO8a1vs6wsypzjn9muRN5u MsjIa7QNH0WXvTH/BGzd23/TexPufunWyNNOuLOvg5r+H0Hhy3//n0ytb7Ki WE+q3ynghOk4C/4Y5zo+2sORkzGQ2pEcvSWiYXD2482n/s2fr29pS69AlF53 5w0jym64u/taLHGB+nZwEV5/rtscPztWpGDk4/WkAn5BFoGkaAdAq3KUtcag VSbZnKzJpMDkisPpx+yNX2OKHBZxZwiDAgnfHoBgqsan2ajYPs0e0ySLxsX2 2dU2LHP72nXuv82z0RRgte0avDz/bAcDg36fpj8ARzp4Xjgjyg7T1PkgIhq5 dK4/L4ekXbveWPh6lY0+7yzmnTLbnrO7Zf4z2laBOLzZ2esevc4YeRqlMQgr f+iAvJ+DVKOeEeCvIsDJ4FyldN3W64Po3f+YVWsf+ljdq+CPUYIIUCOSb8ja jaRncB0e7uyE+wd1xLrxsIIoCoZtnwLuPuiYbYzxI+yngG7Qx+DYiynpQesJ y+oQ3cFcoZjhYRBF1A6uO7LQvPe6czhLIhSi3kb5/TNg/RgnwBymz7Cgmxio YD6G832IPZOtjWRabT6iAOLB9XFgNlMnATaI2N0ycolFZZzENtAsjsqQoxKD n0AIC06GWV5isOJ8biCILhxhAXTjJWI4vdMyi3Elbujhm6JStEAdsTC5HRX4 EdxjcqfuH3V7O/tHB+YXe0r1Y3Lh6vrX4QLMcJvDqJiqh+JeWyN8TxX+84j2 4OJE0+YdwekuAm73sF8H12UMJIewF0CyOkJFf3ijYEmpKlAbVAVF8JxiqpUJ YQG6+scsAd0y6B/rtxzjhDeoE0RzAUvPM6Aw0RA0YJChKQ5W5RSiB9xDAqvW nUY6GmXKXqACJO9iG0RroAzlNjsHyTLa7W1jMthMbzykuJJirkE0Cuc5qDuz OI3yRUiJZK8+uJ/Q2xfNgiv1OM0qc0irHr+s8uoujqagglbzebSIXjg83eBn niWlKQCe85g+8+R1lGZF8CGazZ3EptWP/wFQ832WjU081eonKzRqoM2ufObJ G1AHUTjLgUxUz42aTUFSz62FbhVwl7OK1kArUYB5OQpEAIRnHj6v0FoFog9c VFhKZi0VK174gEfx4REo1H32WNw/8/RJCqiWLmCa56GG63hb5elzhyYqNCz3 OkI/6nMwRtfh+zhxrXIrHn0P9wVlPcNbVz55VqX3iwoox4d49hwBzBJgUQC3 CjivR/tAITWKq85WWpnWhOxFE8AGenlt7ztTM3jmw9nZ9cXV+x+v/UjpD0qR avHjPHhE5oIqBvoo0NOaZyimWDMAiMLEa0hSQD8G0jSgH6A7luS0sjFi8LUY 0ediyyuaY7AbTDm7292j3fXZWM75RxjFDIKI0SGanrIq62n0dc1zV/F9AgNe UuKFl7xhTuW1VhizGzy4dxdXJx9rwfV4njcKYwpBz3gX5yBf7MJPAGb8Czoh XBbm6nWaPzXDlRiIkb3UYxGSq6mg3xHKe9s7nP8W5jJ5OMHJQS+Z6Mn94EQn /kCHWxZrT2lNzhzHHJxcDQYXtaQe/CjAOOhCR1KsZuKgGKcFh8ttIqgBMzH0 LajmWysi/tHXDSCpHjqTvJGjGjsyD/Wlmn/B3Bqc4wtpDF/wF1jRFwHLF0/P 0Xx1LUhojzXcCrsStHCuFUAToPO5v7wZDDEDnj/9ebQqaeHtxYczfyD8pBks Q+AoBVr2Vg12/fnHi+vwp/f13DXnYH4sFAg9xnRfBJuUEC4HsRYelKnetC7M 3IIzHgHJ7GDqOy2P0s23aXAnaKph0SaiQ693KY4jkLisZqhgDIccMiq0KxNR bj73OWren+0jXJFiBCiD9HApTrx5yiKahX8DPqaKTjSfF/OMco21Xv0l0UN+ MbkUz1PIAchVf6AxGxZP67I+U732M3KvmDCDelIhXMlHZAyOxX4FGfJDf3q7 O3udnd3d7v5LqTu6S36Ogz9Vax56p/JpVAZnsN5ozWN/iO6rYTD4RU2WCDsZ sI6WyDsHDNlFUxz8yXgMytSai+BSKLQ3cUJNlDSluboq9PpgQhNBiNd+HN9h itB2U9T7a4ixoRXX9avyNslG96AEg2pUY0F1TfIFrvDD7YP9wxee+AcQMFCx ilF0xxjn+zhax9n/EGGouasNND1FIvO5ivJ1D91ms9kCLQSJmkZ3at2jF3cZ Wr/LMls3HhvV4ZDzDI2dv0Z8MLC77tcY5XW0IDNMHw0VF+m4KkqU9uAOWIHN T6Neixkw/vJ7cALkI0qaqXM2KkC1fOjMR3EhrxrBgM4eBv2vvZ3TwWBbj4gf hfBB+LD3ZedL1/DLuv7flD6JS4RXj4MHuI8d5JUwVGeYIfnBQhKzeYHhHTMQ Z0BEwUINkjA8jot5EsFlPLvqh9cnFzdh/+zmdiADwDygsyeLcDTJ78Kvj2g0 uVez2qt/Cn8C6VleAbRU4SyB6bIZ6Hcqrz18/Tm8/KjHp5ot0/m9Cuc/Lz93 fv3hzH2QtzH/GYcmwUPhTa9vhOsNhH/q7BPZMm9zaZjpYpjH49BEtofFHEgH qBz1Yc7//Pbm4jQcXLwPB9dn/dvloUjIKGYhFosBTozkoDZG/9PV4Pbm5OIq PD37Y3jd/+wOUgKMZDVjSiapvXz7cRDCIsIPZ38Oz/7UP9fv5vAuHcdwWNh9 1Jf/9u2A194/P7s8W3pXJoazrL8IcAcFRV4w9S74LXjcHGv9PdRq+p8u315c nd20WmEYBtEQwTIqW/Dv+/8CH2DYb0UqEIxNltMcGY4inwPcEnLrtFr/9izq /qXFJX/WPhTuvGldnA3ec7TxMc4ZnH0FngG6GS2i293uHWz39mXGFbiu51rx NfLG18yydD30+EtfoNvoRgFwRxwD51Q5ch+Tcd2bpId0Pwt3dl+1znUXzht/ xTOoxNB8Bc/nmLRBo0OJi9TilVM/d1u9NTz3sEEFWczNu35wNgbRTVXq2TU0 XPOGyRueCnd6rwd5UUxnIaaOz7G6Bf7pTbb8NXp7CbjFlAGKmzs62uu6oy7R Gm/QpW/D7sFr4bWCKpl5Vnz/2uvTSMGWJ3G+fC0ZWEfy9ETrnsHyYe58oC7E +TKqh+HvhCr+Wz6BG/6X4N2fL4Iw+EkFjyBlBeOM9HvWtNEI9Yh5bo8qAAR7 QAMgfQtqOZry4Xz+dPkRSGe0BVJJngPai0RDxZZ8UhsoLHrE1T9egMWdVqvP vlMi+C+6HYH3T4p8tYPbTjv4iWKOT+G3QTt4Cz8oiLTjGErjdu39DU7bAhj0 7STBqXqIkW9QJRhHCK+97GocGzB9lt8jNEBluAP0K9rsjEhVGZIxsC0wqY3y 7EVvB91Dk8qOYT31TXy/Vm8HcXEb3cDbSydSG6Z59t/BIQ23dJINYoZW/hE7 4nSUVGMVfF9U898FisPk0QYBSz3ZOwywvtUWjDAyI6zmSDjeCkYE6wiKGBEM n3sEfM8199rEJC2WzgMOY4T57A0A3KVjtCjKOTzB5ksQdAvw/nv7apSOAO9/ 2HgeTzdEav9h41eeTfNhbJBM/v0kBxldi+ff095/9ypE9lD3+20eQY8nt5sS YkEx+GHjtrOBadZ43X/YoBu3YdQt+Lah6N7G7yxufe9WjvsdVbT7ftv7TE+8 zTOvXsipuxC87e46TqOUKMDquftYFO/rr538rTv5IEqwyJMz/VsgofLpygX8 +MEG+fXRJGpVvz5STvVr1/bBXZtD7twF1nxG8eplXn8eTGOVjF+4GrpOM8DI 6Q8bQqY2QLFc/LDRPdwIFqD9/7CBZGsj2Gb03bb4+z27Wi7SSRbwMn2auRE8 REkFH7/0guAc32+bK/u7VsjEoHULlCsaoy0eeWXkRvRg5myyCNAe/4C+ZR3M MtJmt020NW4Fj5QADuOiQ6Nw8wyjHKg7rMLYnLgIR3CvFjZvrwjGQLSyBdzL MgP4BNmwyBJVqjYycKSsswj+i5VkqJhWUVSzOXt+KpxyHnNGFzwT54HW/GVV aRYk7DaaZsm4E9xmsNsxsiF4PgZeZPxBxBXjdJJHALeKg61mGF3hWPWBEntF Fuwe2iAsxKNpgHlRLNDRdgAq6JkPhhn6shxA4GRmFA70hMXBiiwbwZhyDE6G kReBKa0awH9p5CGcG6Vh4bHBaAQLsnf4a/RCtDav4cBYAIgxMKuMMAMGYRxz bSDKxPvcJ2eH+hpzBIKUxzK1REY61x+lnIcseVBjqhhgAEXHsRJWneDHNEEL 2DwHOox1fzykE04EIMUTCoppPCkBBRARAcMxMR6gS7H7WPNCji/AsE4qDzGu SD7DdVZpDFoPPjPHcH+uq7lqUaxAz+LxOFGt1ncopOTZuCINudX67OE+7g+W ZpHrb4goEU6a5YrxFC7gSM1LBAy/pClcwfF6BM051dopfounQQM+YrQl1rN4 UIhLEa4YcIiDLMkjOjflLjD/TgfcdIi/YYR3NASOb15RkwlG59BkCmtnEriz fI7mdF7DHdYvSgnlMH4P94Z8kUQaG7lHoDNT/7wEDoMjcEAS+Ae0Y6gIVOkD 6Z6d4ISFaKy3w6drsB1+n2uVqv0aKlQwGSq2YMCoDAArAkpTBmiNFbxYFaQJ LGYzhbV8XbqzCUwiC+4B6imSmkbitEU7AmEKKDYc8QNcGIRwB2tfAHRyxFKF yZB4Ze4y3K4BPkLXBaFU1ZggE0F4LkGxbZ3edxlnUAyrOKEzmQFmAfI+qhx4 F2dkAmTotJdAAsj8KVWUsgv3eLaAMeOC4bMMPtwfVi5UeOZRytpOqtnx9Y+M PO/xF9gAHAYhpiZXhLV8qqOoUL8Fmok7L/iFrCrnHGQU3GHaW5SE8wqQr1A8 cpbCCcES0WyAVzrAWtF8TfMMtoaEtWHFeGzTCK9IkGLtJaD6pfsSDsn0GNYF xPPrSCVIdfAuVCmW/GRlzEEzGLetKwxI9QG3wOVYF7hMTIHL9jJvMvN7jIkg AquT+m4+G3TJcxs2NUenIBVAAEAjNgjS8D5jva/mYwSWQaU8cADZ9IktTFba cLBIwo4d7MVJ5hmauDHpAqEzqYgJLk9VGui7pFhzkNQE/vpkXShEB8NBxvGo 1BHkXKVgEmDQxB1RRhJE8FLjuiLDbuiFqLhva0bkX7sqRRskcMwSqQVm4hsd nrCAdPwhBpkqS8kQEQCZY7xGT0/Wd/rtG9yhs68AjgJJsbnSU6QTxBcwExoJ AB7nCn7rUxu6ftlkovIarPGw0gJB7SLDbwoUXR/iB6T0jAPLVBemdylRnQFH /tJq0o1c3SggQfFuWsKhY9LjEpCJAgKZzol5WOYPMyDvQIh2gotSM2g6M9JQ jcdW2exnzZJI9NKcrihAIiMaSYwKhVvzrqG5FoFjxFyK9gGiA0ItEsQ5DTcl uYMZt0d7mRajnIl/wuFeM3oVsHhkRwWrwjlfHjjlDR1nAqNlk422/QC97/A3 3BDzUa4DMDcIEHKdauxzJWa4AqNk/o7c0py8eHSlIQEGyTYH/vFIR9NMBwyb AJZf3RFMmCe6Imjj7WwD0jH9xpIim1wQR8J9Qyk1ukXrOev3g82zJIlBFh8F fUBV5anPWx0sXeNuk2oGoBNtbCRYAzcCuiQ8DRfL29LyNXBz/WXoVNgF+p3C QaYRgRAl0hWEmS4hL8Tce+IEhja7TPSEz5GrBFrZGJSuRxTEYRy4dVY0h93M UQrTg/K5El+fIV3iqrSMuaynwHVoPAbWPEA+nhN3FnHMpbZs05EN4ZckrWvy yetkioezdGyXB6NAOArDlIvumIIOq4Rkwj8nzLut35Qby4YwRDJUASdwlKp8 VECAjVZGQq8NO2ZY6EGYCA4BCYgMUb3SMpaAZZKMNGfRYOJLgDtC6dIVSIBa IZcHATpVIUwXwk9tHdMX0m7st7gzWNGChBhh7ax5YNg24DHBUrQdo2zg+a1V IBGrRySGGTOhe4jjeGKccWQvLrIqR1tcCXt2pA8UFIr4F2UBWtcl/avWCU6t FoRycAicgfinRHpwam6h1T5sawECTkXtOrT4xXqVxjN9eTGoG/FnmiNlAfmu JsfneO1EkmTpH+TJSSzUDSWG9C5R2vXYQQOE+3oUzwoh4Q+wbi01BndVPKY4 dcITjcrY7gOnQJnDu0ZJPMyjnNhEChBDC7RGwXbTOTmUui1IhZpdCHRgZpEX kIcluhhV1grTRhDpHNPviOqCwyLnoNUZUlpQhTWqxolcap7HiAx16ujp8EY4 cjBEnz2+KFUGmhoagF6D0bBMpV08OYWxYhWeqyQBVA82T8/5GaD0YVEu4FTu WVjmIzdmAjkLRNECxQT8hQRMETZrWAyDYPKXyaRuuzXtEIl54DlWFC+oZBPz X3d79aW7qG1DmBI4TDRjMOqqugwrZBs5gtH+PGsI0Z6omKLeO5JY4jybMfUE 1GRODlcE5BXhURjaS2HRzEj+QbUyQWO41lGRyjdxfwsZ1+xYoPwBrHQOsm8p bACNJEj7SDjXxhUYHu8tCryoWRdZTWyPZtiSg+STLEOZOZLSjQ1z8smJVoK/ 6qdAqjYCBFLjQvh7Gd3Dt4QuSAdhok4wwFthRVUmLSiG6YIBM2A+RPwTydcX 8RfFP/hdQot4JUlizUJldAcPm7yTwmpL1fwOeRLIi3fkh9EscJQR16SxLMwV 85qUCpv5L0YkLoOYgEwHa2cP1QT1crq4tNkOm1QbktZRt1kEm1eDky29U7/p iwQ+j8kExLWRkLKJGuaRC71pdish5vw4CFJjYdJzajYJmg0n3X/7FnAYvMQy a0AguScPppRDsJJyYcUJbb6g9TDhe6+QjwfvMKcaJpZKvrieC139G2PD9Xo2 3w4utkiHoitiN0y7MyfXlCRqaezTkySmwmYI7fUtihJA64IPz4esOQ1TVpmq VZmwMpzPSZbaxLhEpo0ANst7hpVm2SwJUbCDQ+a1EcM/KoAtxXKjV5fgSOaP yCFPZB12SEnqGaxqAiLHaPr2J2es5hcXpOrYWw/QusM3AIPFXrpUTe/pidqD fPumRe9my5pD3WRpAdl2UX0QNQGu/Mvpb4SW0SChgF4s4s0U2RRZd9cnXThw hVFSTlnTsaZs2DF1diEtnU2duIVyMRfFH+jTTIqHcLRPhnsBfkSkmow+wAYB v0DgKKda2MQZaGEkCONJMJsQgcAI6wAp9If4gjbhK5kksITnBr43Y1ubJXMa 0Ym3zVSEFHLFoW7CXCtsSYy+pN+ni6CRTxlKgH2dopmwbKDgQ4y2tX/6R9QO pISrW1QlpvKnKCNsXp70iy3QispRx3WK0FE8VEkqFmqAy7LZsuYBGWeKhXkS q+pSFVt2GoUEJCXTUht7nFk3+XQiFEqUBbUd9OmJ66oDbUH4ZSjMFqDKtuqC am1tVQrEjCVjx0jBV0HvE48IZBU4BiAklCTy+cPpFvJx9wmWePH7Bp03mOoK iiyAJVlsTboKKBPSI4ee1wQJMvfz+ErkNNRZFVlhkgVr7LGDGZ4tGDVqiivA b+ptbkTe1MUBjfBIVANuQ5VSRcF0sWQI1se/pAsYEN9lLEKwTUXNHd2exCAC OSnvmgQb4xEl7PiCNlJx0VKMZAuLxGOkfgeehiF8UuudQmdN4oNxiRn3xAqz zlQlcxLJeBTcN4+FAi3wQibjNQsR8gE9HPxt+NAdnFbK5MKFV8GVuI3YFRUk w7BbOi6pE0cQT+hUQCcDqlEKtyTTq+4WoFDHxT/MfESCcX0XN7fvfqPbdATv spwylsU0+h4TYYLN/rub9xja8h1w1HwWM0utO9AwRPk4OLGuZCKMYhgoXIeZ LvG71uhjOHAFQ+j8KPF5Ad29Y6sG3WLT3YJKxB4HrWMSZADjAcJz/SXcmZKN bXUipS9lTHbglC4i1hxmVFB5npHlqPURCIA/DfaHqpIyLLME8J88WUM+CtZD UQVAQM/goXgOxGruLbUGCJ4KXXk5q9Lah0i2IKIEeNy0EQ70SeIGZ1EkWnhr dVYb+YxpB/2XGDCHSyXLjR0JObCxs2mvN0hFS86+G32bljJ9OORA4LkUkEDI XFQohVKVt8Q9hKLZDLpS0nI1OtW5A26GMg02TO1j0IMoQY5TFNXYCRb1R+uy LQboA5MEX9wllpyzU3uWU9kewWqt4dgoOAUaCjVRJ35rVErlFDsjG7j5E108 qHOKIQu/BRpoyCdy42Yjj8icCq/qqo1Sl4bm/dn1kWLK5gbAzQVe0Nu6W8ca poJoiEsBvs8mpow4o15KsOEaLR17PUliC/8Dba33rPiCtxsUcKeKEfBpteTA kYAOkuSND0K3riXVRvuKh6gYw9wgFY87nCeNX48yNoY1L5ttDBPeHj5Tn39O mmE814ox4jXivyoJoUOSOMTgBCATK8tvDbegNJavzhFqDk1nMUcfJ11jFDyD jdL6VusLqUe6gBTJDjaHF07wUi67KEjp3rACKgcNsf1vyNjmhvJ0bF8be3KN B4doM9RWD9eLzsZO19471eoTWR64PwIbTvIo5m5Z6E9MC61jDhXpBpG9lq7x rmjCrsY1johJg+IrFoh0UhFyA2NGdgKvkKefFp15ixaTEcJ0klWpprZAY5ne ZjkzI4OkDc6hwvjnS27MN2dnLKKoA2W8MARNOMGU76qLmBH6WFiGDUM0nsZk ykeFiK36SFZ0meiCyknDcwTIKQWp0qVAMU5itZBus8+Wo2fZzmxluAJNFY8r CSGSKhi7iOIxIzbLPAUZEYC6/aKMn4SJCym/wUOUx7oeCtwPckPQXEzaNJmq qyWVmBrNgzUy5oGKRRM3zOgiXU1NN0TQRGpVj6TbYHKzIYRxw86B9u228VG3 Jd4GFVtW2BxrDh2NV5DLXGZx7KCMEDlhOugMsIkkKCp8p7tyucFiLoFvtahD zEgikrQt25ilUH1GXCyyUUx0zES96NOgCIAl9m58hKv8mGwPrttsxxzGVsWg xhr/iRPyljarx2Sktso1XE70q+QdaTSK1hHufQoffcwexEahgYs35jFbopqM JUz+HyMmUuzPRXHinuiKgRMZDtiojYfrhUZ0lkVqwtg2WjKYfrLNHfR3yswo /BAUNwDRj09DkRF2+g5lB2790V62DtHZFmwdXPL2Nwt8tSi4Us3p3laFw4sM tcSQ1LyIciBDjlpDNh7mRo6DXqVTpDpj56U28S9BvIVEq4xGFPYp9raXgIIV S8p/b7VOtI2J7I0hW4GXSew4MxIAG5fFVYLJQ2hnT7XFzoYK+gGKDUuh+wl7 A0qpkkQblLIMSBPTJmqxVDh6K1tQmSBIyA4GbRkhisIj55iOgJVZSndiC09v BcxvJMhyfZALrtb37KNjFflp/BCJc3zmbRWH0/VaUHf8zjEZeqLj03fmrn4D UoRIWqXGjydREkYdNGOIEKwf8EO/4Hs0cZFjSp8x0zUUjQpb4NIYeDX3AziP 8qwg+KNZl13/cQpQc++EUSCWzZhb2CLIXhi3YSQ7kKzOMhU3Q7KgeEvjlPSQ h9kS4baqCSmOGTZcjjwTrZbzVgqkeFQsB5EDY0AMTD3boN7XydmAzT+mG5Vv Gpw5vkl+4/zypB8Ozk96+wdbbVJOFbER2BbcClZjCir46JHsgoPMxT8A6GT+ mFGotEhCSuwjtfgnIrSrrdGomRkA1OzSsmxYcYhLtnhed91pCLDtmCLQ4pJU KLLD8pYQ/FikKCcPMrYehw/XmFWDTYTXFofDGSw0lgMKTccFcdwAB2At4bfZ jWgtFtQvhbQJrUIT/YqjHsFy4QY3GOxp8X6TVOdbVm6MPc6jj/DSGMXBEe5d jau5ANz0WU2XiQCaMNscQiIxXa7MUJ8eiA7RUZROE3l8agNoQQXlaG4DaUta EH7aQ+DE5pMzQVDDUwFIoSH5aJFVRkaSWFKuqwvXlg6McjwKWUwsxh4MMaLw AHqEaM2yyzlXYTyD0yHrMvJ9W9ecLnBhd+gOSQkH7lNRsQa4eO5Nnhnn6BIT tV9Y9wrOayNaxEjbKIKZW2Yjyk2uyGoZlfWqKi0FrMvoQ6RKIrI8+66hqglK cTaiaKhGERobGnYLMKlGEntgfelUatGUwmQK3u0dhmjxW+HMged6//3pYO+b wRc7iKbP7NcoSPvzRBUnjtVxDS4PxNHetkwvQlTCN0o2P1q5CCVeysGRZTnf 2PHEeqC0zQ0GRFNUkiiuF4bW9pXb4jC3odKWX4qpRaKIkR0zbm2Gln43Wo+M Gs15CBy010x6pgC5ZEEGcbs+VnbI5q2MBs4YhrseNUnGyFf0CHy2MDFGmBFV RLxmO+3yMkg5oZAFCm7AaHJEv3jGKSqgsIjUSYiwiegy2trufUOdrR2gTFFg hB6ARjqd7R80yJ80AcXVM2ai64XmGGI0nPTVw7Tog3bQ3ent/QND7PYkljFD MofOIXSqPT2hrUscaE9PtrXrt29bTmAaXqx0yohHMqj4vMhsI1FfJDeXjn1N ZzGAwBECfOp8Pza4oWpxcyKVpwp1AFD7ERWWiDWH/DxqdYP0Jz6PqLg3dkeJ x3CycjB3nLU+ZKvog4hRN/R5G9t9nISIJjxNve1jLKJzm/2G3sSrQDd6FI7U MFwE7FE9CG0aoivbyKiMgV+R1LFLFCG74OJg2oygVSgQUP3QAckWMVKrDr2O CxsUpt3z0jSd4umpiiAFbaXC0ZxI7xGsGe8+J+V+7rfZZBoXEh2+ZEUgEq2D FdGTOF4ZtjpciCRgCIr2TZC3BBjUA1WtXpmiZyaF2QT32vzLkdwB/AMupGYZ wE9HFHpCZ6N3QqGQYycViCpYq1XCPIzZNrJs3QzwspTCE5Sl4K0qKduGATmQ EfKtxRBlhuD67jqYAYOc4G6z8ibxPwYvKX6awrXIWyh+3UJMq7UAssKaH7EX Qwp/megcCZHSkw4coHvhRBLVtEmFC7cA1egXoTjl89FXmxgNhV1DttzIqLYN OWJlq1D6uPFgSStd4dFotTbqFpINjyVSSLokWjbmGEmAOghy1qEccXBlPfFI P7tl4gMk2UhOqjIhUyJaPcB1BW76t0wDc0XIiLGRikWK7ZyYkquxekYRLxJA EbtZOsbq1eY3frMi7tFxpbVrAaltHS9EMgcZOiIJ4WE5XIcckdnWDdo4S95H Mzjtp6ebd/2DnaMdQQXsegPyrY0/LfiRw97uPjAjHYYq4duSMGy5Qu5UAqrb Bc1bJumQM3usJQPlTW0EGVlnKMeWUhsHfnfZtBalZMOvUkQbxQlyUUOGAnl8 nZwbMQt6hruirMZ4ZAUbt/1z45SBcZsjAojrkaCKAcHUeZeM4thmF4d84Dh+ UBUoY1uxyoBrczKy2bpU900j2LmfK5wM/Y6df/Xv2NgW+AMoRVhbhQ51hqwr lbBzICiK/TlGI6wJ/48AOcqsYLEiSTBEVMgvWwPKCt7SgUDGxowOXThrHe+L kFtlS7LYzBhgcartGIuwrIDc9rrBhir42wTBwuRMNxqyWZSq48YWdnZgTSRC pjBCm54yzAT9HHLn8dbNI+CwOg3eKNes+VMwtvbhbAJ25KUGCG3RaF6UFHEX 30XDhTQeoWmenqjnBdyiNtt/WZ6tJVh4DkzKzDCZGsBrkKm0fZ69ijKRnpDL XVhO5qmpMDgtKi+NUF41xWbcUZ328ySaH5lgkQnsiY2pvKtptMmiC5RkSoUj ypRaQ9aZ09j6lsttyGohE03tWwsTHWaiSPx2rUCJDSvG2tx3bc4aI1FArjM5 i8iVDFCN7lK8fOi5vCfLApmUOfrNsdpJ/LPJcR49v1ITsY9XB8MkSWdGegmo NcwwGhx/pacxaIuWifaYGrW11nqjlWpLNjmYmgzrzjtPT6b6rKVGEV1pNwjB MVt7u3FGIoPBIpOTL0bZXO6l5/Uz50FxZnVImUA/6/7gcg/McMRewUK9qDyF hHM4i3IYkE4OwPgcGyGzFKMjLpSYXB7fBbfOzfGR7trahsn52qdlvqVOEoZt ghzfap0ABXk+ysYGHTZev7ZcuWDVlSsEW5+5ZjorTtWCUTUysmq9xJSJBROD rTmDJ/BLoUygIFabxeiMxLEdk7uq0eZz3Gph4Ex0lytlslSRMlF6BFoEMEzO f0SirNtOIHMtc7UpzwfDlvxczfpTZ314zhO9vIW48zGMkFfY4KK2tYajw0u3 5kFuw8Zl/9hx7FUJL8QeOEqIIiIkK8T6EGyhB19II62RdQt+3aCUKWWyivqT SZyju5kx1dCjjhCgWbEMhctQM7QYLSMNAsJRAgCBxxpJZkrQWzyo5FN0V7ep LZMRqyEAbS3ws/5c5QBzTeeY1itx0eWxiB9zap1E0kAnuPAHPD1vazlwGi2l TlGM2ghzy6S42TK/knNh4SFEDDMpc1swurMZvjPOsnXFoAdFaVpKMxARZuvb WPLjIR3GcVstXcTaLcp6HCx9anITXCR1PBc8D6nmJvyAPSAYPUGh1FUqgbRo 1ZxlYxMnR9wKZcW2zeEjbSyvhHNJHk4HmPkshpPGF+7dS912VRQy5bOAzWSH ARk6h8minZfJU0Qz5cVFR8wO7tfTFytQCoNCpGAtIH7BtSFaSguOKOTUk7TG S2fTDqZkvpDoCwrRYGuG6I80lysQLo8Bh/4WyMI0fJstVIqp6ViENth8+3aw VUMD+MgDLAa58J0YLUKypeQU6FxHk8CWaiiCX1SehehZSdT4jiy12SSU8kXG WEMaolSNlOA74T5JVkjCrfUec8wccBzKBFCFcRHyjdCWLkTG3MTfyVuIaJx7 5dqkaju1/lQcB0UJbCmlb+w6cdU1ur+CAloXNSlN5mZRElrNuGUWjK4BXTuG XjPmMSBBlC729DQQBfKgcyRFjFfWPUXzMkjGXKbboRSICcuf1tmn8Yg5j2h4 4dqY5/luP7f8lxamyWbnVPTwt8Qn92xiKgoYktRK+svTk416+EZyGVkUMbHB 9MIFreBkhVZsYk9tgX5O4Vb15AgpQEQRiG4xmaHy3/VSAV2zP3WUIUP/bS3k 0tRRcm3wY0CJkDLfjd7IZOuVEdocrhSnLOtypDbZFsQShMUqXOuQ8E2pDcW2 1AjraWvfeI0iSFI480kOIbQuyXRVpTMrqGibP01kJEPxA3OSqVdLoDGOTYDE WKopsybdzXlQnN0Rk9+Ckyxxj5n+w25zRq0V275hRwIimwencqNOkjEn+3O8 pJ+ijdnoJJfpoGrBafwcza5s1cY4YKvHn1xfBFRDQBbvszHha4aLOYEqNZM3 iYJu8TgN4pDcBwQKW9BCPtQ1D2KMkZckPgq0NYXTxqyk08XqY7o+VawLBkT6 xes/qHXD8EsPX1BaLMsP+51up9umH+JNOMC/cdmPpjArHkRCIXdl1hqqEj0w 2s1gA+j4FMaKKi78HksbF9UdZTEi7mjOQo9yDlSLoEyCobjgdE4zhwckKI8P lAhiPBZluX1l2QaE0qFUFBxtwbqACQJsflJOkS5yA0S28QhVIqeN2zJNms4T DEAtCtG9oHXfjXdXGzgZ/MQ+Axsi8mIHLdjjNfZbmXMM9rsI7uG7DPgNQOcW 0QOvXYuMFFe3Nz+Gfl/i5RYohpxu/B7WgMSa55QKziY8iNLuhWuYczzsdAkQ 3R08R2Rv3BgBP2wNPp7z77nAppb4ibHewOqZLgx44yyUL8/UcmciBKbwAYxC w3UC78fV/6S02xPpswHeUsLpjzcfCbMEb/+NH/xLJ7im9OwW3nH1qPPUCr20 uHCqBw9JRnh3cT0IejsHHABu90DODFz4NJ63dJSRflgahAKKysFtvwPVIzOK DZfs9dNqf49Jt7Ar4HpEY81YmOZccqkWLppMsYYdKtPt4li31fqUw+mn3N3+ vwXBv8FZAUX6y3FwmY2rRBlUYTGbGs42F9yQgq/6vgebuJqwt7OL8ogMfv65 DyOfRzM0taFxr4jD/mKUUBgX3QCHsOoEM1fAl0nqslyxwG6KM4xakHG0J0kC j2CeEc0jA2AgE1CMlJxLN0qNw8sqSSTSi/4ewJ3HqKfNm8sbEKlHGZf+cBah t8FMuRN448Br+iUWuE2+BMUUyRDkIQi1h4CqxOAbvqMH05tizCYpCsldUvOw mAMPNJtx01tJPU5UfRcDdzlu6rrpliMaHleB4FLuOgmP/KWS1UfN0EiOGnJN IyH2piEQ5ubogyHWsLoQ65z7JxGRcJKGZCAe3xG4MKOMyRxVhGdUPQ7qqPpW o+qq2jBEymUSuTO7hPl04QlbseFb0IipzAcIlVmOXcLc/0TY/0RYg7BYHt9j 65bkch8bIbqIektEdxV/rhFZXaq7t7MnxJZGFV77l2MuAELngVG2K4fVJHvf HUX44LEWASiANZGu1ks2Az3EwZZe1KbevebW+m/k2lvLVxrmWHWl1wgqfCtx 8paBRe1KCzheDI11Y+9b6PLgDBxYeLPsFTwje2nmuW5y4uxGLOFZdZ5c7ASG mNQGjE4l/2mTZIaoObKoeeDKAseaX7/Ls3HG4sAyOTWmaN8E55A62VWCLd50 DLjcSi6ie6eGeaTN6W54reBXYUWHPjv+L0dnSQyqM6zo7YpZG4irWcr7bD6P mK50vL/qRK+Z0MkoRqHVZAde5KKrWCAU62LpEXifrKKBagZkR4aQuHHKXGng AlJir9C+Ra2yZI60Zkex/l4JUh9TMv6CFv0IypsFI6KgnKZ6yWluXIVwZmOF SqdMeptXKVekmmfJIs1maCq/oXbFGBm6EWziJFv2DIPgjxKrIiPoviADqriS kGSL75A3DQ0p1GfozUF3y6kzkFCZ2TsWgmWgit3+g8F5sLaRUY3KaLQ+DsgQ sAp9VyGuTP4S9GVZwVwjPgdB5UDj8nPL+E98XsJnhmudJjB4EZOaQOqi8mok lpU8i8rPILEM8wJU9pD45l0fO2j9RTZIt1Ua1nz33XcvrXnYamnRuLVCpFij x3kMZzd4euKxyOJKUnGrWYPj956ezj9TGNOzkvE/IBP/Y9Lwkhz8CjH4HxWA /2HR98VC7yqZ958g7TbKuRo9bSdawkISilZh4YtkLpLkCAtP0ZANV7DVMqJc 6x+R5kiOe3qSwWRoLcjByL9OlFs959MTD/7t22+D1EQ+GrcEdrgRi5K9McZe xeXwxP21oeXBDbobmI/h1Xxis1stPNALvDGRqfJ83HDCujChxAS+QtB8ekpc s9G3b0/HAb/3w4bkJG18a8NjmL21/hlOnyiwtzJpGM3PkTfoYvDpxWboVU4i HGNqitV6/iHyi3jFLkZ2Mori8Of4LYOG4wfr1kbbXq+ohrYM8GtovJViWse/ So55uQQDmCuTERuo8d3nF9Akwfiyy6tFl39IaLHiyq+SVl4pp2D2jwcwAiKL KU2Qe5mgslJEeaGE8lrZ5Onp9yKdIKXkfeFo4oq9hSFxCnrt1jaLevqulG++ cUyk/pM5Yx4/cFuXEsM68AXxe+r32RkWFAnm/JGDje3mza5yDqu3zust2zSg lqErjxoDxhbtleqeC71rmqFNsVicw4J1cdyqHUUWSkWrDcB9rD2CnYzautYU 16yB8zq/Ov24pUt4cDXNKJjB8CPqAsV5ZTRqNFY/Uz15XRKdQzqTqEqpr46p A5IB7ckoSILA9qDqqf7cUkxnNiyCKQZjkjTBa6M4UqfbiG3w05DyoKgGAwzY Xj0heiCqgpKFJXKCoqB5vUOOwTShn25lO0q44bh1aXBRcGC+ztA1gUY6jWth 3H2c31t3zMtx+uevXctc2sdEhHFWsw0hkQYvtGEOD0/iieIsQF3Uv144jOLc TVjxmPsbRNhVG4aD9U+je7XFHJp9gj5iGjREt5X212JMmZnaibPQk0/ifMZt 0JySQ1xmVeI8pccIN2QYAWYVbfN2ou4wUEmXAWW/lXyHNJXlCk1z9YhYAXw8 JmhTKxyJ1B1LV0mzxBkKnCNqPx+cYfrEhN1ieRkmRDOtEdHsXUege+Xp+axs VA8F2vEQeZaVUsrTKdPLIfHxCORjqpPGLmQqA8gxBBRmq8PXed2ALf8D/gVR VDzctVr/Eq74t/IL+rL192DFv5Vf0Jfee4vV732tv/eSdS4/s2ad3tTf1977 3dJ7vzS+F9jUs7tovnqR3pII/i2Q8r67zIpRxN1bf9jgP0CPUMkGs5LC68FH rRlMzssYW0Wh3sR1gBzizOPMcJx6eBEXdApvFEZTIJe7wE/pBYzQ2Pi6AViC knthhUepg2BbAxJp0vlTnJkr8b0wwmKD3rQCCjbAJIrGOTNc/JtDsbkMrXcF pPbVLxt2fsxJTjTprvV+a+hAtVgi70pgQflLsDMJNaGhakTdrZGHpB0VSkwC Qt4zdgMmbA3zuDBpMQRkhADtmYhMndwSaXEr6MXwVjUXqQDhz/Diknoll4PA M5N4aVRwcKE6IdqJ3dOec5OkY0djZTjODYFFyV0XZAKgwKP/Asu+oyj/impB YOjGTDp2MadJnMqXvC9vJbo8nQtxECJNxkeEtcAw0kjkC256gwT44tagl/AS jpIwkKQgaSrRjBmLY2lHg+Pgec3iNJ5x6TfvLcpccb5UrtA1nxIzbEZCLlhO 8Q7e+1zPDKNYcePMk9VXTkleYsg6B5rXrYPAnRRxrFOVcIlmSUYyfSidzmgS XSEZHRR0rI9mzCm5JgeQ07VDDPQJTVCf7gCHC1zuK0YFMigI0GSKYF6ITmdY inRnbk38WD1SaviQiohdpGn2oOuClVQTTnqjP4J8QSnCumxtJrvl9g6/QftN qiZx6RCTB1BCkkjCmHVzJGC0cKqESCa9XceqDOEb6uwT29rr1L/dmSmg7tOF BQipNhLwbJL8Y2kcQBDQDL5KY4IKhQBLD4k56KpaXpCGlnLHOCTNbbnHgdNS jHCsuFQlVxcbVuM7ZdNyzDpMS50xVwyWoHAm95gYi4K0aQRB9ArQovAy7hjl K8VlN5dLjqE1kYGhO3NiuDMmZ0m/OyFFU6xhKWSA4YWnYLq12TaYJsR3XdNP 7Fnp9TcRDJeCudTlLZGeAZjchyqRqZ7zKPI9gNlSYKNv4dWHe1YRvYkRLSdU fIfsllR3T2/Dk29ZtWUZdh6VWAQMUQPezN1eiiDYjaUUYJ4lEr1NlVrxlawq pVIOrkLqtyisQFCIXI01dvDaBDDpvd/YgUKsJDxSWiHHqUnjtjslyfG3unAo 3LP2UksNr38VFjRVGHHFYripWmNEWScet1YJ0GneFVodyG0KxlORHEA9Pkmh uyajrIxuKFzMwYUsKD0/HA5ye43BpLeYWwGfnH2Fl2l/Z+lDnGcpRxBv3p6d YRMCXQ4sHSVMbkxN/1ok8SgLpVIumZAHRnJvWIrWTBpyXUemmwiHqfG903+I zWamTLMxsqoKCzgOymhOnco41HCcCVJhygxKBmacdnB9cQXoNTZp0m2gGrCb uQAbe8aWGFZtNRD7Ltc+gsm5twEVJCVriZFSpIOa3A5dEIf2yfcDLax4K0su SUGlp/WFO3artwIOcxE0mLYai6FRlxTT2pXwNf9AlHOcTM3tZa/m0rDCNDxg 5plKPgVyjA2sAclmINbzsNwutZlC1shXVndKoBI3gFsh1b3V3SNtzaVogXZm lUyMXUlvhom+txMQbyJUxghSXHj9jkyZ8PQwo1x8lC7G2bwkfJ5naP5Q7hs0 uixPWlhMolmcxFFubS5YDtdtAsQdNzRlm8HtrkQkJQnNp4p0zETMHqUQmYXJ UN1hWWnXQoHr1EHrbG7CorO6hFkBa6IGtxMeKInI/pNiix5QPebEDHSNYEMJ RaKGDZSs5Lc1l5G1Ezoyp5no8gPUGQpFyJx5XkHJCF6FERGGyWyA3c1dQQmV Hlgh2i9FZNDWZ5/z1Ps4SjcNQiSreVtypWtKSmErauoYS49uX4C0tIzO9m6p a3o8m6lxTLtrS61vwJ6cmngFxUilyOJ1Kxptb/ITddDKZgvAXHuZCbW2apvX n7dvtyiZHws2UeEdrwlcQBwoibg/CPoGJiFeNIrJ9VNQtQCog+eZfEiVuYbm fMZm+Wmu0sHg4xYpnXSLAWBtjbENneRpmdu3Dblh1n49zDNqv2MakwWmq52l CtJonrIdHWNP2/0r0O0z8OZu9k+QrfSdry+jFPCJiOO1zd44H1wKqeUsQGCX U2oMMSjxTFE/oEOl68z1eX24uw24pLir3/1NZ8ibYmq6XBY1l9fuVcp2wFMS WmU6GE40EPnMl0Dp1eDG5iWFZEdOFhamIXpodQtJ3pFcP1KjxrYylC6SZ5sq WoIk1aCpWUch6WuYDoMelIn2vkm9Kn1kZHhHstRHa2mGEe9sY1/TilmngHqJ TCA1kxtS10GS4X7Rxj12gpH2cYf9TYBNew4+7o6kf2cdYCzfdYJPnHgjUHDN l3GR3al0oV8kRzbVtSmVO9jldR/4OFUAPwegSCy6X7nVJBQYxTPJhHx6nehr Tjrdh5munc7OMEW3ikpxd+WEO1o56RvLuML1t6KkkFrHuuaF7srunolzWbm8 tVMC7OnpZDwexHfsWPku8L3MqzpNPH3nu1xbLT9yf1Xuqvb3sGBNpfWUX1OV tDF2LunyIJHwc6yTkegmC7THmB1P8MRZNUrgYmDt4Dnna0mZEuRhSEXx0zGZ IciEA+wYaN4cBb4NU9xEJ9CZYieRp41TiUtS1rCeD7Jh1H2pvrVNp3Zd1ii0 eY3U7QAkCD7GWGvujMV8dl0iqprptehDw6Pegl6eB4WiK9DLBAt+2b9ZsdF1 HHSdmXajO7aNDL1K1IovEZf8b3KscOU4LUk+dLo8mCVPlATolnnGj2cTJimP MDQ24gkjRgF2gRCR4oWaBjrE2kR8awrd8QbQDXdxdC7etxoX61WEbD9QaZ7L ViuvZruhYE6Lbu5Hw04Vp7Xdggtn0UiRTmNDnTG6S+MSD3Li9Y7DErIU1HAQ dne+svMQBqH+L1R1h3f3mPFQxfJYzlZkqO4OjIWDeT2BrRmhYSQ/ARmBSRVO rFGhFnhQ7yVWUUCGgIcVNH1ylamjgLf0+sPFnzymD0flIj/3Smno9KHvAceG tSX8uS3x24yvOmTAtJBFy/kjVsgUT6RHsNyMY33CWseMLLZjwXxtB7VNfLSS Qj01SerGfHW6A06dqw0zCuEnXYfHaLGhb9dYKELktgeaAMzJ8m5L6VPPDKBt zpILaQSjzeWUJIlRCSgLeD0qUU2cKV3txiQwOydKlX6NpWeEFwBroBnvbX1b fNB6odyEsd5KKlV3CTCsIRtCc+ksaZIeayOCLD7GwAYOmOCCPxJJQf3svBJK cOfumH06PaCwjUdbKFHugMaBqClPVBL1F16J1nPsCEEll7HGJvJYm+FKqzgO 3lKrUKqRzcVgTWoxwAGGnnKCrxYK26adIFmxqIeKLQVNFIirszDH4O4kXjX+ NpOPaET2B50or0taCG9zqjPh1n6u0GsMjxHhNoVTHUjAyY2oFBg1oQKwoLR0 oU/UTEhZzrwEOwGpc35BUilTW9aqIvjXTN8taUND7m1Ht8ECwQaVUL+sVbgk 3dONHiTtXUs+7Zp3y1QykZ0gSET316WClxGDbMLDjJo3a4Ti9gztwBR7JX8d cpV38BJFpFxmOcfhpCW1ghHnPaAHVmAVNxLH6pAFemkIYtiP5oqzs4h3a4us 16RAXDKpewadtHPK7WLEYE7YsEKhddy5SC5AMaflYaYmVS2hG2uX1sPdXeER wJKQn7W9yL7VtmQ+jRp10aJ+lHv1TsVGaHqtFDpYo9DyfMp9LGagoWM9KrxJ hX9JHD+BaVzGIqwTmblafnViAVutc/PHyjc2rz/0t2yMa0TUHa6ELq3SPXqz Q+YrrBxbUqK+7UoDYPgYUVkB1jBUfo8OE2ZUOtZW5NJlUd8tFcEdPgt75Wop q95dJBZsqyGuaU/QQZ16Yat8SjV8fYsdMeP87aDYYhwjQNhNLsHCKv06aA1O 9E+Xg4FUBN09ontwPhhsf7zUH+7v732j6tvB2+vP+CH++PbN9mD+MaVCMNac 2gAxWxeuzTSkaTNefSJyywAPNAZI6gFsPMZUkplqaMSlqXEpER6EsMxB2a8l EYd0GqXjtrUV+zpotwDyScFouvWkq6XZysvIotyuEaVEaGmikmSF38CIbc2L AIedsclOpVzx2Owc6ModsgtdgM1WZo5KKfI0EICswAPSCsjgRwV9RsrGC1lB ylIu12LilMF2W0XwWTpnuJirekskY46Ogt5OiIZKE4vzW8fFl0odFTG+4qZ6 O2LXFDulK48Y/6yJtpIDs41/BS6c6k6aPvJ5McfjFzUjow6toD9RArB+GHEA kfLaCU7jgj3FEvy5WDI4ssQER5ljHBsK/kClbfmiR1HTNHXnaldoBszj0b22 DZmKtRpR3QPRXlSpJa2BbPo6SFkdAgLWXXFqYjE6mrJwXNuF2/P4kRkYCCZb DcxWqUhsJ/iUKmu1Ipb3kMWabmBIKFpGCnFY67wHc2MDpEhOlBdZumxYGwdH 6BZ9jJhUUQwtqqjeUe2nmvfeRNkBbWU7u415ox4fha4xivaeMrbt1uRFvkNo HDMlKGxHAqYwj/XaQMIr2zUjyfmnG2Cgm8iicP+fhhR0fMNC8wDDuUu+jbe5 UhhooWmf16SHAopTXexTT0k8oJksMuAI3yXjoU1xKt7h2LtM3vhaczlGjpkx 1nYMMPiSug5vLDF+fX5x1R8E0vLTdvhwlkZ9BWL7LBO7e0VRm8ZoCXIcSwLY x+dZScAaD79JN2w45qjmHiPA5aUNLiEex/mtR4fyGx5pjRnPKIIbJUQcUIdk 09NXMQjjoLbFTofjWmVLrCS9sCvRkTm2xGJjsDrAmSnMnIxmKyLatVLtxsJv 6oQis1Bv4i0KdpY0K+5ry3+YiHseRo9yjrUh69lU2pWEwW0FlSiLiG8B1o3u g83P/fDy9LovOUmuhcA4ApNEJJthnmHPbZIwb0ge28OCjxGV7DleynxsU5rS pkm20MJpQzaFVNd5C1j1Lom5Q9BymsTm24sPZ+jKwZ8SmY7pEoBUVGep1TpZ l1xBuRXSYMqXzewdrrW6Soy7Yrkymm5uZVtKPWbszkKE4q5dtnGpVKvVQuhS Spk4SBrsJDqIvNaA0KkYtmltXNKhvqmYJHaumHFjIXbZ+ynChkNxABaq2I7Y A5p3/FWNQ+4CVYOEW6uU9sPx7U39jlx/WuQ1WqPSmboW6mPm1Ml6jBbFcav1 34JbUzEzYr+gXyoz2Dw9+7DFHJQD3yUkJ6q9e8/50d6rH/BVrRo8Al7AczCc DkV1Kh9HTrCyV5OWuAcfo0P9zuxEm+fXjL//BXMtuodYpc1kZgv/4haR3tFQ tIJYimKq8Sdlx7iPrCmPBYdQy2IaKlIcDCgR6AwVrD3GhcBMlktj+TGV8uk0 V9ZcKlgbcYMa6lnNTRUaC/sGbNahV6hcnL42ToDD6pqguoih+BG1H/AFy22Y nsh+8722UB+ydRhXyQL/homd5QbIiDBz/EMHorJ0TS90pDic8Bj+BnMF2vp8 ohFwC22fLL38MTwnp0MherH78Nm3b3QhxmoCS54BjN+rdHMrCH8HtOAe5Kn7 LfstU0P4nL9HwWJUOt+fKvp+VNJ7+ExRtFpMdf46v/8rNyRyC/e2g78W9nOr LcHno9J87hjhTIAXczKH8qgxv4hA/WtR2EE9kx2RKwuUSXxXefHg1DKQ2FYw STA8ViiY6FGu1/nYywBoDom3kez/4v6+4um/A+MjfxX89vdgAOoZnG/w91eP vSJ+/l+85AAc9u8Bn3Hwg3f4fw/rD754xJX/XvHg/P5lDzp5Bi+fetVWVh7K 8hAAHUZ9Bpu9Ff9LV/GSB0flcw86GRvrkkNqUyMAePO1K1/HnBeP+OJdm6SP MhqGsAD4n878wGvq1PSSa4pJINSMyKlf7T8Bwt7K74LNE2S0JIaQgMjUbDWr Qb7p+NCFDGfkw8NOmuwlEYsERRxLxtVyxU9dc+eos4d0iNIq93uHaOY1tnYs vpreJSpExX8ckJNNe/TIokncRhGfKGR5NHkqebAmcEeiEITd4BuPZFB0hCDO IQ82I9bkti8vLs+QaWFM0vX76wA11mTL1FmXhmpjMYqhu83dMIowbDpkAeYF tBkXeHrOVWn+v0qFG8nwRxPpM+K54YyOaf76k/pfcd9tA6XsyncvpdivuXiv etIs5bkn7VLWU+0XEsz1FHOJcFtAF3ywBOjXwME7gx6eQU9/9apBiIICJp99 BdbRRfLZ23rlIP8MmLzsSdjkM0++jJGs4iQaDj2EQ3eL564/KWRIqpOD+Lkl 372U6bwS+W1W2/NQGknJ9P+4yA//Jz7UOgD/SSvxOPN4GkaWM5+eC2MGZor8 +MJ0YTCCNnlyGwt52xIoS+K8EfRZIdecxtO9SCvl9o+oSjB5tTF3+YO14XHs 0CRmoyR3c4YVSzoQ2z6FPzrF+SNPK2gHkj96BezuwmF3vlRxhfanNm/LiRTQ zn9eGzlZJQ2CYs9WAICjQZlHa0S0TRJ0qLGsw7BgNCOQw0XWBFtJVUkGT6lb UWzZCPocs+ZjsgU/PdkTRv/eFONtI2TMPiBMrQgGo7gZPdGJG4yYUHEizLaj Gm6d1FrTIEfpEOFNz+r/EHvCTCFp87EOJ4LVIcAdR6fgAfp9GPBRXBqVW4PB BRX371K6yYru8u53bgQlt/dXneAaly89Ow5tHy11XfDkvBp4jZDFsOVC/LRJ fVEowRR9YvFkzZIBQNwIXSRVwbrYGPl1vwJ75mEa48FvOdkxhOgANqfVo+4/ R3EH7n0BYrCsTNfy6ZtJ0f8f5bhVIsu6Ma1IwnBYfrKZ6TY92cx0/0PIm+2X Pfm/Fxv/302G/X9BKiH6pUWTQYxhHFGqMBXYlVPY03fBAsut9pjqxDVrENBN 1lm3/qtYg7b+yqwnDbEQX44J8EUZj6gJrS0bRa5gCpC25mGHCFMwQ1R6Vah0 WrLbbcMENRIvaLsMjlqBesxNcAYzYjjYUQnPowBDZ0mUASMjO9tye4FbIqe5 vduuxmm2qzkqxV6FZR7Pvc24JlbNQbhXHBeZsHyOmrHgqRgOLw2AhyJZ1Llf B7sZFbASclq0Te2vBo4lkSAmVogiHscKndjklxmRq81JzKamMjoGXla6MCUI OL2kzGu7x/COOfUIHi5M/HYejVWYTSbcMna5v/lLuONr+eNrOeSv4ZErbM5E Krq/1ur8OqbyqketFePZR1/MA15Kq55jAw1G6C5aobs1M3R3vR16mQCLBNCr ncfrAPvP2tcLHoUtt581SLzYItFokujWrNuMsFvLNomi6OEZ9Gpn0NuqY7Mw yz653lW+SYcHbzeIXa9Y6/PAeuGjuIUXPvofAfF7tfNhBH4t4q8+kX/avpbc FVGTv8I3i4jhWywif11e4F/bzWEDLIKM5Pl2U3yKl7HHRhUOwuKgE09B1bUZ qKSC8TTo8evJENxlkXI+MJ9LFqFrIHIVZpz0r3i7/k6H+Fdm4vpZzvR4iKhz lBts6rVZW86QdjpL6kSCWvSpaMBu3IskuktfSxVcXJ2G/f5JT6u78Df+CWou 1Qdl7h6n84oLG6Z6TLYHWQe/KdCIwgaFGUZ+Tq45gSB213siliU/hhOFNgNK EUW0X9uWkRzGJsVPALFhpBBl2sedXV9cvf/xGmO0bakGHVjpu9n1yYvJx8t8 M93dTBUMC1qVdzwUdGObJfafSzQUDkzE62YjlwpVonvfDaNF3CRp2/j/nage N8reMwvx+1Ipi1PQan4u+Bw7OTO6yEFhAjsm8tXamLv7KriOcQ2qgDThaQdk vIKy17jrJt5589o3U6jYb83JG8dnC53NawriXVvs5lVI7naDlOg7EElGlZLB wabBbzI4McJsmS6TZAecRqAsoIELo/A4kS8xRaJo/2ZOD0sLaUH9qKi0qI7R k065pW4vPQHhN6J0MOqYrDOZMT4Ph65A5pbUsji1WoAgve44baLdvJJ8uoAd 5rCgpC11xs2en77T1xmIrLno8Bu3haxiIGUyN2e2RONoTqDo060O+zYC5YQi 77f8SNixBQ2AU9/c5RA8CtrTift8b/zKtLpAFPZxM1lnTl96rX0xtQnd9DRd w+Ik5ZjsOeXHc3fDWIfjmd2b9eJC6WqJQZFTjohm9Ac7XWkJ+vT09vzDzhEl UPFFsgX/6YF6yCae4AMWPFiaEQ7nRwQyBW5S5bqlNWGAoS56x15neBJGqzBr XtRnWiNjB3GG3K/CUqtm4BRetAqfq0MLOoqdtsw5OlHnLdugw4jzximTx0FZ CvTULYud8qS2UENgi/3VD50CLfXe3TI1UhO8xNyZZyEm2b3Jwusbu5BSrpzr AzzWqxTCtnc4+Iuz23fhg6Ki13i6aN+gGAGsZuhcR0xAxKaVdgkkZEjzASxV RZa2ptvgGJ2di2Hj/kw2Myj1DFopKBNxfRK0TbCbwq0yJV1hZQt+eXvp7FlI LicFR3gpWD4Z0zIBJ9RqWiq28wQQxC+R6Ukebs6UBo1QobdMbFstumW20Scl bgKzuaNUDl39wRLz0iniRKEcFtktCks2GyaAH2uy7vMlySOR273hUAx5fKMd bDhn43xK1lDvQSqypbO3jFFfJxzU3XaU1lINuRYgsQQOb0YEw1tsjhAEX8Fe sQWJ2KizDlHmiMnDoc03eFvJs2HGj3ULak67hm+xzbiTCuuYd7R9CoOSORTG ShO+j0aXjCb3InfLTT25sp7Na8U7P/TYFa5seeSxMuGLxgFDeWPuItq1gSM3 IPKVY+nMTW9tjnhHR4zT2XMD5MuE/xtvDXtVUbLSEU1U/0XcoyL4Cn+z+oY4 45ZRsB0sIyCvxMfANhWb0rUmOsFA50y16wIDUTrsCBxz8g2hj3mG81vcgh86 ZkrK/4vT7+IUF5FS1XOdWQ+nrWZzDoyimgkL72wbAINY7KOYfKUrZFPwOuZf lQ3aDcdWO9KUtuAyUhZrkJdSTgtO/sF01VQXvdLl3OWE0O4uQeO6+oiGGdFj l7eYoC5bZMAT1Gi5x5KbgPlisxkas1lFxQQkJ0WSku+rcl7VFz6OuSaC8WKb +krMHgTZPDlHLwQZQiz46gSwa3GEct9wltFC+l1LilmcTnVkuzBsrqVv665T XX+pbmYEMUEBkwSNZTaqCHCoVIprDKAxXdenaRLahesMKe0yVyTTkhlZ9892 wcU7t1CX9Hyd24xa1i8670Qq0pRK90+nquoI0LspJ/OkLPlp5BfJThf5Qz5I 5RWz+aJmGdCBGlyDGYTguDDsWqMNNoCX2lvzqGgIxoZPWNHiCArCZ1F7Jbk5 2Pxw+o4TUYhvuolEROOFlmJFH/em/5aTiZAu8FdJomsY1FcgqXLYTYDkIbWE 2ITRHQ4i5ZjF76bze2xTcckw9JLN8Cwou5YzQKZKi0BYWGQpNWdD5+SkbhaO rRTsJJmbGAgBl0ljbMyOMW/SiVTJfWN4wS2XpKSm9FpVLJw20pahNyGuqKM2 4HRZLHWUTZGFZ1jsjFIYdUgPFyHSg5LDiuSGOc7Nd4G/r9Mazj8V0ZNLwJnC FUKrmVgVrAvD/78sqcaGpLZa9ShVqRkheUm1TCoGB+CsSP5+XLEzFb1+YrMu T1Et2Dw5OzndsqoiTW16qHNttcgbUWf9u9InFR+izTuPFrrglcnKgmMP5S4Y bMJ6RXOd953qy+WOszQM0wuTViOLFmETGKKh/XKe2sbjVTljddI0ZsTbFc5/ dnTNcaZYdNCj6Az9eBSqOYILKyR54TG8dK4FSGvSV92kYJo4FJbLpTyDAYAP 6Rl3HCrqrQBMk9rOPqnXsAe4aGkGtIdNO18xlhktO5JlWO99dpIuGsoguEgs nItsua40xYo95fHLbRPbRa2EHFvTggkAozCFO0gjoOp9ZHPAVdkaAWstUPUN oIpz9uO7sH95wm17+fdWS3+4SXVpRJmvUqpg4FtbtOlUuiVFYmF5enp/eXN4 CHeOdMwmnXIV5NjQYhixxmSy14BoCGqxWHH5Ho9GVP6LKvUYewJWomlr9zKt Gju8UEEnrx4DDZsP45LKdBpfvd6+OT5bWE04spEhakUd2iyAaLbPso+mpq40 QkX0l8t6EsGkDH0q25lKTc5fGI2Ndkw+6EkeVVhPLnX7K3RMfS5dr4sOVlLA tSSlN+jYdQb6yGWvrzltLMM8Lrj8jh566JZKXTpCfTZaXnEF4cZzMnMaqckr tiNN83QMhocIneAjBo3Iwtoay+3p5tmQSpcWcHJSGX8dfrZBxslJi1YpECxd dy12TOZ4i6kTxLrD4KL4zObMolZa2hru6Rqj22uNa545LTUVlfUEbWrUIbgg ha0JaLpC4JrLzNIzX3wp8Sp2QVThFCW0x8SV2IbUNlV+48R1P7Tdchm61AGl jwvHtnvWu3Jp8MvvMHsUVpndagY3j/pq2v+MBa5NNbHUnC+VOWEA49pDRp1Y LDPGQtjWKcc6qVWWBReBbGrRmP0wmUhrAASYSrlSoYFix9J9d/56FSkGo3l9 CELpdBahYFWzFDbXUnLLHnqmQioZ5JsHT4j6EYItWwiN9uVqFq55EJu3mYaw G4Yl9j3D4YZxs2Q61FbMhSA2St04U1ab++eIOKIvFWIIlSzFmsScJ1+rKzBV wKqZMZ+qkgrJwGRN9RQ1aXj6zumGqZusOh1SmauuKVq1plEkl4qzxUOpSIGu TForAosvc1vX4KNXmvSMSwVuXn78CcRuGWtL91oka0Ld/r5UNGvjHQjQ4WAa zWIp934yxDq9G1gYbVGhxyKgXjs6oFs7RbGw16KCsabqobjXlSZN/ZZc/U2O lJIU5N7mHJfnV8pzV7D5bmAEeF3QxJr3DS0PqFRIlcZIvdiZJRmEOgJPF8cz sxOEi1mUJLpSbOFWpR1lptotYQ+VDpEKs05t/nvl3vQANPSY6bXBRK+yE6OX 05BWj8QbeB+hezRKQ3f9vHCY00bSaUlGV1lCLRtoGH0RUjmlIKLjVQBWXbXT IqQuyki15wWA2YRSJijkz4uwZL5CMCSJx227RxmXVJ7OqXXDepUpt4nysrYW kenXsdrJ5SeDQGFbcdR0YlkhVbNsVhaO8DGq3HB42CW9YAnQS4j+/vqPXNAL NhKypc2v12hFnRXo/p46ZbSDawWSTF4ysfhjFN9XKZbmw6Jabs6GM47U9THR nNoIbyq+mivPaQi6PrMk+OS25oVYGalCuFxx0B6x1EKiLD3T3cDg8qRUvogJ iSnOJ4IaccdH3a/S6PrUbIp8zCW1YJ2hjjOElT3GYyyIbP1rwSbdBSySPzEy n61XFMyTql6wgL7Y0u0ubQ8lwFpjdXeWTrVbsZWqbbsqWyTBTbCYS2qZatVL nSK1O4uaroxZQjdgnGdatxpnjykXO7WQpAghvTAMRy6xk6rxNcdl4RpJdXAE XdQJSxorbqnWxF2hT3/WSBdW0DUb48FOJc1aNBHVRm8q0GxhhHFDlnrpiV9D UbF6q8t+LcycYnCRLSInX+rDgbPHGqhYl8vvX4onEEqNHlOmr0pp/bo6Zkh5 OQd71Im9BmNTPUdnR3GRHRsspOt3Ymwx/IFFbQFouO+QA6XgexLpMHGObgnW SvoNxc4gkJ6e8G8iO2T/sy2KsLQQ5jsBziEp9agZFmpmCKAIKd12/ZJZ2v1d q/tLPah0ET291A6SI3YpaOnFpiLpXuVOvdkJ9V9qYAm6ZossDi1PWlivtWSz b7uXim8S6KSIdLQ1giFuyk3Gc2RKSwlpgknOweWNq9MdUpfn1XFmHy/efsIy mVusMWitEEgr1wIV2FL5NC9OgLlQGyCquBy7c9FJIOYkfdtq/UaNNMdqbo4u gR59EgBitN2vbKJuZMwn+Q04VlWCrvWLjWvBS0H1LXUZuuaClDpMS2ENQaej BslHuhhelRIuiBspXThWa/PG5rJ1zm0br4m28VorLBacmroChuYhVUX2xmXE 647CcbVUMlB6YdkieR6XIpIAfK6a46+9/36wZ9IrjcGOVTxdlkjXitXsgSWU JfGDLq+tEk4BR9HIxKzUnufoLLG9cCcnuiTd3mEwjEuvEmk76B71Gj7FZfX2 D5a+sTuXFZOcqvI636TOW1Szv1YYsB0UXGm8+YYT3vMD3hWiqAhXXl0iVnZl xoRshCKJCjF6DSlmbJ4fqkVGrDCjvubsGNSXy6nL61XiZZuja8Zy01YprEro uq/dLdzAl0iMJIlyDCSrDcRs1vLsvSCxJdge0Ovy4PD4zTXmpC3buOIxc2Yj 6/cxHKf83nbYNgofuXEjkzONEV87cdsSdaVCApf7PqmfylYKXxpkSeGlIsQ4 3sfLAfMv9SdxMnBtZmubDgYMo018Z8utXEwDnIPsQNW6sW748kvn+M42aKzY gxDkpkt8LnYe3IQV6FGp9LFXjXht3WIXfEsVgk1HKMrSogymi5QVHfM61mvl KqfLr2dYyHwWo35WM9OZFsvGLA7gdQHqVd7TXSp4HiNlAi+mO0wSGFXyc+q4 a8LWtpKk+c7YEq18w6y2sCXXSerWzSWB6HW88zY0y99XgwXcJr/zPc1MMApq 9dQuzTVnzLDjhpRUNzaNNumK2AlPrAKa7Pva3prS3GhHx1rOIW7F34mYRvCz 8PKW8XEw8MNbttgbHUwXc+xHC2MIPk1dzDXld8UjKbeApsTOzPgVh5Do0sjy 9qLjXQkd7iY6tVQV4mEwy9tuxC01jhvQEph7FexoOGX9En1KVXiLErB3m8JP t2g84U4JWL5IYWiBjHA50EAKrlh6dm4VW2ox009LLnVSEcSrPXc71OhEL12k You3tOckWiBfw06UDSeKq3K8dCabzwS81fRKXb8Po4QoNkjKCzpyo253Q0LI XFkpWxfbHhNdwMrzJpzGrlmWq0vx1sYm8GHH5dS2lXamo6+xEyw3/fM7HMT+ lLWN6bc6BBLxvlIOA3AxNMgYTzlLe9UQASnkEI5a3wfNrNsBRZMTb5TLKOYj G91mugUaAUiGhZM89ZVyU+/YxslLko2HKzoo3liWnd6lvB23K+ByVXqqcm+6 DZEUcuL2ReWW6VS6HLCFgkXc+uWRHZK7PNoK1lK33hSVhbuKQIq46DrRA1s/ W/MYlGGMSVJqjVfk8ZQewbg2YbXfEQA+SECAwxVRSuObgQ+I9EFZL1pjlELY E2xqqTNja2a147XyU7A5OD/phShgwgbh9w9n+MdWW/R/NyBbxIbN3h4+uwvC 6oLLfmhiQRd0SnTHWYRtfUqxs0D4v5KpyOdSwkScPjq2bKjol3ivLJNjw5Is 7SeqGpLG5S++UVb0PSE0ba2ZBXudLiYZLVW+Rbw1hMS7m17/KLp4neDaKgIy yAx5c9uxZB7uWGuVAYnpkKi1BjpZbRpg8X3z+sOWyHAMiM0BfKCFesPFhUA1 H9Tllk4Q8whG7V1+ul2Hoz3AzZ9WnPHm+ZY9j6Yl8PR8n4cK/YeGYuv4l3q1 cnJF1QBlC+LIzmgblz8ACtYh+Pfg+gOmVeN/fsKcwfMf9uHH+Q/AcegH/9Xj v3r7mCRKyar6P5JpufYHzAL3Bf7Tg/904X+HB4d7+ONwD38c7ezQj+4B/diF ++K/gv/b2zvANewd0FL23hzSj6M9/LHf3dmpvYIj9Xb3DvHH/g79ODigH4c9 +nF0eFh7BT/u9o5ojXu81IMu/Xjzhn7AyuAV0wIGQxxCpD6t1k/sBmUPlP6K DccRUuG7GSOEdu3HbGagaHMqw2MMdoACbxdGDyEnMXPhquAeRCbJhvoy2pgV du0i39DJa1MVPXAEObqSSytfJgl5oUNnMNORwiV1XNmYcXLFtig+gUxP4sNm Lw02KfKsUa79bijNnSx7ZnlaNDJjd+CGENbMKR28SjdI352D+kx4gq74+qSK /wpxAGA9jkel0Wa5oQD+yZH0ADDsAU8uaDkT0/Zghg7lMpNeE7ZLhN0E+RoK nJK8FdpwRg4x3SDDNZlmqYgCbEPAXEUyCFmvmAtK3UfHHozmoZK5mBaMIZzD 6qbcIGb4tkcMxBCFzccDp6W2rovOdNGoxTZoxaaN6RoXrrGMzCBshBZNgNrN mpyZxgwoVDjuQBFKnB6Nxoyr52UkysUOCFI2CFwsNeKhGMuuDTEg1CjadfiR x6OpE5mg+QztixQHgsGQBkWLBhyVTYxMsHQEdEPWYbxy4nMGTR6Zj/bYO11a bMy/FOhQKMpfgkRmMlLdkCJO3SJvgS11jim4dLDObSGbjNNMHgMCOSeSa/kH Pw7ecm2xCUiVpN6zlUZyxrhfO6OLF7GEyArnRbIOBZrH+g8SIpHx25wWwEi6 eLr4CJpPUwx6p5o01PhHk0bdhV03DsdYWmUK+JtukvZFdqoBVl95tfke0Eg/ i/6W6TZWDUVWTGMmMSPY6yyhWLrkDPXaod9QyxbDkKYSjTHa0tYHMx5IqJB+ PlkuYrWEc/D94MQBVVIcWT2pSydXedmCdOboQuMwEh3xIn3qO7ahNQvttx8H QbezS4OcXg0GZ32juKyg+IQJ+jWWFIE1gzbtdND+I9KuhWNocc1mGkmoSQ9W Q9Rd2rxO1SaeWO4UaEJzhqxOxti02vFeB+RTrSDTarZE3Zc90Tr3dnZR66eg gLh0zcuACljbzgmm1fzECWvUMXO6IxWLXjAB3TkvzQdX3feO61JuyGCRltHX YLPPZjmslrx/sN9DV7recuRwFX2xtBiH/UJ14b70IWtgacaG2jGVGqiPrXGS tSU1BXCMyKPN4DAuBp2TydB2PH0FlUTULlljdzNTatO2yYwpDddiEJOrm7bU Fo2uWOI2dm1GVk750DhoCUmHUcs4h85UjWpybhnHRw0cYk2uw0NuduGGZ+hj ILOlBJZr2ybI5WpcZ5haTZK5nchbkfr11VhalbZ342dGu6xDSLImnPPwd6+n Ld0GIp4NW++IMweNGfvWVrtaF89JDhSJCXXzaNkazFfWmB5WSY6SLNZeTiMa L1LgLPXuFFow8u9EW7IEJMRITsLIuFroNRwq4y5mJGmmme7VtogV+kMco4YO laxZRdxAX18UoyQSE78xBPybxE6nQwsAdN9yRpLxNjQyClRkMw570le9fiZo gdBYjPJdQ3qhk7dlowTGGZ06hooZRxNfr0cV3afSZbqswbKw95rgtQQsYjAD bQSYcm4W0PeQj8q5SLWsO/GzuIDG21NmCZd+i6nfljRi0u/Jg3j3B24mz7Vz KLe2ZNnTd65rWTpxuT5TCifCyh1xKkZE+50wClNIxG0Wi8Z6E66Ad1K7Btb3 M0XDtr44IXs/Q5KFyDCNURF8IhO8vnU3qVmP22MK12NdaNhllevB0AOpkEgS C1iZQA+1kaPzGli53TcHWvmzi3HTz4eu1aezgao6JJJjFwpEddORUjajc1Zh UDEMwcOZiajBKd0USiYDcR7MMyxiIzoWy71SGnkkLlnpVoivTLFNSn4XpcaW RA179FSyUdFE0SwqfRGMAlw/Au4DPaEMtMglDHXdjhM0RffJdXIrCsbUkFUa RZoMbaRYJ2eDYLPbOyQXt/Fos3kLzY/b8J9dL9aYPTVOdRRcvmmEiNiBY+L7 mDo0ozaZmkRKm9sJ2zN58E5ApqHP9mp9pINwi0rhkPjwZm97d8u6qtaUodL/ EFNPDGqsq2EFi1iqVxU0fLb+3+vf8F5u2T107dJw+yEGJmyuAPtWIyQ4WSzc 7/Y0HeffhZCH+giA88Pgk+3CQkL/6zlDwpMoIdChkaiwWT/YrYZFLP1jzhLu 7a07DW8Ru3VIHPV+HSTeHBxqaSM82G8GxFHPAMJbxJ4zJEJi93CPIQG//BpI XGUOySqZZxFzxraudAEaFrFfgwSdwoshIVDo7vT2DELwHwKTwzeNMIFZECZ/ p7ptzYzE6xAafg0X+MIG/GdD87H/u7prW24jSa7v+Io25mHFCIAUSYm67Hoc FCWNtJJmKJIz2oi9TDSBBtkrEI1FA6Q5tJ5tP/jFf+Bv8fpH/CXOk5eqrO4G qd2J1YY1DyMB6O7qumRlZZ48R5TJ5Qhum44BypyYpvi6/FzNegx3lHl+bZ6k /899tjd2OynF5h0tZ2r0Dc4QMVb8Xr2BeFdtBXP96z7gO2yzUru7Sfu/Qsjk 9PTk8TYOdROHShsbEGPWVketNWkQBVzk5RWf0y0IKjVSFmFp3dNqFEvZ3rAR 0LGkA4ztSAX6wkHXt9dWgF+8ke2g/YmIrK2FFoo+Wy2/MkhTI8SJn0xEHNdD k2hnmWqhvVQZrYc3bWbPkHBXa2MbkZ5O2nkaCxfGBGijS40pa2kHjsjVRodm nTGzCBPcXLcdxW3kX6xgOuR87pUzTbnhSy8r3Pr2OO0w/13XFvRZO8rtv/k5 37qf9SShYov8BhZiwEPzifcP+g5Zi4xTK9uP7mvW47Zr6uSaR4+RIaFLdtde QtYZGRfkT54gm7L7cG/vwZ3X1Mk123s7lvZZdw0sXngTTuI8eGKNu+2iOr1o 58mjJ5zH6bIDTR2nUopjwHnkw+6z9RUXPG0LBBCYKCmddPWgA23IeYtAzrLV WCprZn7DE2s4U7euhTsWAwiX17XmZy6Mn7Ui/pIlYX+2/U4b/kQXrPnl4/v3 O7wCd+n23u7OLV9nGXkzHXfgn93ZrugOttr15NEd7dp5vH3L11m2t7f3Ge1y 7+avbnmH9uX27narO5JLafm1ejRp186Dna4uz9Y5mx3j6Lo8tGv7cYcn69v1 oD3SSbu2YSn/ynZFb7bVricPb++vB/fvmF+7u/ef3N2uh+7j+FfnXTbb9eiJ e5WOS3d27z+85WuegJ8xjt3tci5ws10Pu5aTu3R3u/2DtF0PP2ccu9sVPfDm lzsPn9wxjo+ftNZb0q4HeztdS5rb1fvKQIK0L+GsDO6PrUhnwTvGiQuxNr+/ +cqXR2isy6p/A6IE6GmtwVAGX4dLjPtbIB7x1RAeAjoInpprEmelEoYPy2ha nXx49GgVBekdUPiv2y5DLiCNhlkmoUxhcVotgii61ApowKhZxqDOQrmApETj wNB4aRuvxA+I1Qn6Ph6otPbdbnUA/pb7v/05SJuS/OqviM182e3fL5D4Toe0 I/346s3zlz/aWcatzL2WjWus27Zxbm6znXfIsuzOdj3c2Y7tUhcgbrMd1tk/ uGtzT81g5x3ubtdvdh4+3H7S7DD7tqs7/rL+6r5D0i5uftfFf383Lu7/He36 O7olWcvxcO36G22z6zpMD1ozpgG923S2gcq32dHBOiP6eYeoL2FD10cWsv+v NlT+HB3v79x/8Dj0lvxRi7p+rnT9ID0RdN7BeuuOZjGSfXgY7hEse2dg+y+y 7GtD43dbqtbJ7kuf67KWieQ/zXPdlz7WddvP1vHpS5+eus1n6/j0pQ9Pa5rV PKR8oTPKPjNLjKZF7oCGLp8wiJ5wwyCrXddakOm1kJ6mmEutwGUtj9QprqPH X0vq9Ha33o4bWhPkmCTdfeToMFKSJSu9DcRBTuqhbtFrc1bdIISJfq5h7bIf NLcBOYc3Ly53NgTP9P3zQysdY4wbEx8EDIfxC0SoEIhE6dZTYIgUQOsph3Pr ccHK8JOC8B80VyeL/CwyHkRJOq2JD+gGVmKgbqRrfjze//H1t69PAmUldWdl FMCZEpbWqwK6IswVQwufwWwBVZJHtubT60gHKWXNTieWRWI4NcKdeVGMOdtv ndkP8scqAKHvUniq5vZLBuL+TWvg7iPwo3pQGb1D5yOZuShfgHtytQxnyoS/ M58sFfHk+ox6Pf5gFiD+2sAf978/eeW60yR1dD7JWjJg497m7uYuHJ+bm+PD 4Tb5tcPdxwdBzliglOsnts1rJuUOEyt5g4i2r7J6Tn3LSFSD485BGb8M1EwC vqsFcwxiEc7Eoax1WtWc9Tm1OgBmwuWrGSiC76/DbUfVTNYqQ0NLIUG39xDY h+CADUvjmywEpQgtvNfQQjMccu/w/dbJhtHoHqu9ufnq8P2J5kSV506w7RjV SORgZRxlvVTaUSWhtgrehEi5nBkGXLA2rTBIjEAYAieJivgIxaJQUQcWj5ay ByPyZniLhTZMjykU5CnPQveDI/PxkbIOQExoIEAd8K3iOdYefrnIQygg2tta DXA4dZ2SLQGCdWqrxaWGY+1ySm7ItoM+Ws2EU8XzIZbmywfwPs/tarLkf6T8 LQGwdilVkec5/XQVWFUusBxCaRo40gC654b6bSO8PFN0KSsOw4BTspjT1VnN hZsBCcj2W/RrZDN0t8UwdvfeQPKfPP1PGaRZ1KApYGy+rwrhIq8UnY4lLVqi EbBwPcdU0MT4oydS4yziItxIJiCrptXZtQLGtk6CnJWSWHJ5E3+hy+cglYGR 9XPLDyJ1SaNO8IL64wz2lVvdp1G9BCB1BpZIo/qnfwhq4NW3z9+GEUgEo25u MIao4QX18uuJGuYMmyeXvikLpDKpT6b51aC1LO+ReXByOYFPTAtWg3osIGK/ qIN2BuKRwlkLGRHbL7TxXBy6/rU2QmNPGkyBi+pjMTO7M1mx4aat8uDo/YFC 5+PrDYQARHk4rAxJmu0aN2VgmW+YAMTQrdSQfRv1htCe5eJDiLilAaRFHDkj HcDps+QCcSxpLtRuNInsEoLMmJeMhJWn8j51tihkbps/mFLRcfUjzcaDIMsH bO/6659mvaeZBGm53rlNoG86FgadzmeilOf3mC52/9IDzx0HiFMLjGQ2LEjo GVXYS+OC765WNxUAZ55hfDmtTXNN8LxgNuSHix5uwMSjGiMy0Z8tqtW8Flrz Wrc4ZiNelnVgrFdOlrYFiPWpKuDBMitc4C5bNd8emjJlIDr3bI1aLSjNFsix Nld4ofieXiUgyOmJks2171ozri3NR7dkbTi5Ccmo64riIkncyopWOGBDjUXh FWZYXo/y8c+YXVrXtlI2WsCYedPLuT6QfIRlqKC4Y6rpa8RC7+6VwqstOL23 NLsxvXRjEA9YaO9rdVgxR5ivGKuZKWoXrRQKvL6xmNBA4dXlcbiyg2XoMrjm IfpmmgJST7+/Iee86MePZEggKnZe8eg6tQdPi7GzSf+ho+KL0Yj+gDzTytNo us6vZT59nk3iTYRpt9GAijUwcQoz/Qc6HjCPDnM81YEGQiZnsq4SLLESXDl6 pHl3Wdbt1oCLb4OcRaSpxkO4xmqwRoPNqHXGsXJGmrLOvgerZ2beT4umpEah MiTeSdhPSqucE6Gd1Ci9Cj5EZC6nd4Yd8eqC5BODo5kLrE7p7PCR6w2Zzp2G uWi5k5g76ZweyKz3TNo2xeG4qbNYi4DeT4Ud5SJNtjrslbBO0T4tCh9MwrGp idfI5aa1sY2XtUqitjH+jP02rrrmzpss/fTuo1iq56fYlH5cD+d/GqqBWRao WKlpoplUxoXKl9ALk+OPbhUF+tuHUhWPXlVX4ChqNmbN7yMXmifkXfsev6T3 Bg4R5FLxU4vpeLqoqNLYPZ/Nfd7bhYP5QVZ2162N+JIryNSFD9wVvL+a28jm kjWVwQWeS9EWiOeW8omHPK5mQroC34HrXaNoSgFpLGG2p8cMQ08FNvcT3u4A WFuU9UeNbagUrbRX2UADBacl3uO9wGOoVb5cqppLFU9bIxc6aTQyMInP4PHO QbES6iKdOASY6fNSyEtbHcgyqbaHI5rFBUEtWmLejwTY2yCMPPju3eF3x69P XtxKF3n04vvjdb9g4+bKdCzbL5SZI4mpjFeL4Osp+9NqfobyokhIy/aCtwL2 3c3jBBtD0J4MdcqO2OAK7CDyL2OJLgJuWjHUM88gu2wcwfa7racc5uyYltSj xmTXQRQHqp82KONFHki5u0xGpfN+/i69nuiqcSl9WBC6gFW8OBclb7fs/BrI mz4pe9GXuq2LVxBAK6el1ZtdiNFLDtvuYE4mmr6K5ciJKFK+5oxuPAXdno6e DZjQH7BRsLxQs65QUJ+LOLUVucnqXEmVZyiBWhdW4adGDE7C/XbKxEkiDFJX 4p5E2YJNHYukMrdu0FAHclg+i8ss1HO6joLtVSKC4ESyLSjk+q+2qkI21ybW zbfmJVDnIwaduyKq05UShypVWKiXZPfnlMzZFZetG2FEGSRoJfxGTgB/xPRi ah7TQWKHDpunChsmPY0vRZwe3Whc3LF8U2C/SjZ1YLshovvck63IYjRCvd4H 5fvUMfio19CM79P9+0otqVsGKvFkTZCNrotETlW3BokMRVl7bQtewejGYMFo NeFRShcSpRDDUE+KK9a1EeJGuq+tp7ALinLSm9cZzVp1hwZyhKHPxac11jHa VAKf6bigvhPGIW0ENjfeYL1azwmODJULRA85zhWLPodMCIdqgppDLTm0XfV1 +77cgj8swmv3wwv0G34pF1lca67ByyPjKOoPwmOeQMmvEjlJZX3goyReBZV7 HNe0dezbIEmrOg6afw2Zlqyu6yR+WaB7KVwJFq116kiN/R7EmsEn73RnQt7M iUtJYJZuKrXE9Np0eJWSRQSBGxcHQ2A0LqjiwAY3yBj6J9wqpTsX8KyEQeSy xnHSA9UpV8lysBlVxmCwRrw3FHV38fYoPWyLY2UMD7is1TNnfgv45nzW5M1d znV0mLXgAb9RSFI2Nh4VbD/V06Xqa3GzOeoeufs4GO1uG7kIXCrRhMpvuW3M z8iPZWugfepK4y2n7PlLiRD+lkabtNOFSUDzBkxxytSCdcn+nboRUANefk45 8sBre2tFaAlc5lmlsQxT6+3Wk0iaqBSgcVrUKXaVOwiVTyslKqpxiKtNxs6x WciPrSMXKduJCe+yfRX7pESCpSg6uMvwkJVjOsIpforjVKKubRt6KIsOjqv3 VBwJno0wYqq02TO/CfRXkpSxTlZ2dSXKkmvhW4z09CUBclZVtEVw2PVstfC7 K+8UvEkMdOtiMnW1wQ2yZll8KqMNhkjkT91uEU69kZgi2c+5/N3ZFdecUMmt rboW8gwcOiCXgd1lgV0FhxeNdqwWIi5Nd4ZbUYekdDAsgR820hVIZY6e2eJ2 mhqKFsCXbpr0pIxfvCvCOFClA8Sg5CTbvb59Fudrf8N31h9ZMu3uHsNGCbOw ton3+ryl0IfuSSZpjG5oKL1zJFGcf4kRhO0mOUYJB6PCB3J+ZaGKEy56MX4W 5+FivBWb483sBc6KAGDAqKHl/rax04QRbZyoaIhKMtMf6UY0L5ei3sj6a9XM eEudAi95QYwZx3LMZZIhWYK0ENcYCv1YqyUfi2KuhP0ucLGsqqnYXjGTs3HT BRdSDAsDz8aabFav4KKCDkvAeGiGJPw7UCj6PBxPMHZskwb6rIKS48v89vzk tmJi6HBRchBZYguR7sYeweqA9M1GYId1by9jwo1itymQlQs0Q09EdZHIg+VG 1Y4NWC0YDhnliCYWtlsfY9IQVJBthr2vRC44ipbywOuEa05K9pYSN8C/AE9r oZ/hLPDYke+NeeCUBoYdjZqWqCpqe8Pkn8g3lIiE0ZgisnUKXrPpVINb5P5e FNOCtihcW0NwQZx8AHeO2K/q8u8lfAAd1C61YdRND5iKBx3JhMRu0dpRNmxq omCPN2RHkD0DcNsxCEQIxOQS7Hzy47LWKnIj3milrQNLf5jAGN9qRE3U4t5q qCCbfnf4qK9hBrMSRiTrY2fx3Gp72y8l2mNxRuOEQgCbThrj+lypRiJz8/HW u9fvXmSIVgJNJTroUh0ueCQXSxI5M4wKW7GrSLPJTbRWkE+6eUaLN2YQwhsk rdZHJ9MmsYygIBm4xsQjQBJsnlTxPOzimmGIAgVnrvxx3mnC6NibtJLvgQCQ Ov53N0dRNe93n3ymIjLzG1WJSGzO5+S51VGVUQnS3dkpvrpST7HGbs15vxCw 1KipkdyRJwGdovlcSO3wm35sgrB8yVYwLwthpRTPWWiWgiVtvhC1G5VEF5Vm ipQ9zBFLqyZDLbZXHXIECiemsxVChjaOTGkNTyt51RNhcMjHJqBbLD2eXHFp Rj0kywQsemKdDdMUPN5+RERNNL6LPZTJ4Jcpg4BYUaFarZMzdyD6Rn+Ry8LR xK1mT9c+Qj+nrWhuaaDwkCHXYi1WFzUi1ieRw0smsmdaags6KnBJ5q1slCyV 4fNimMhX59WUDyw2Kyb0TudN1nbxLZuHSYDBVsr6xjT9tXCR8sRhLKWmaA3B Jq0pdfeId+NAXWyZ2u6Xgpl4zuxUIW75nR5djvQ403sHBy3nvvKZv9RvZnWM kmmrxhyMTBwUeGpv998dHmcfqgUfo7/hdDgAliBWQtRTq+I0YxgMUvexyfbo 6ElKFykMJPI3ciCNxlUT8TRMl9X0UviGzK2ujKJTYFUMlHutBewzDu3CP8KS fF5cBiW8bwWUV/d6jXxvNH6cBnWQ3IHD43bWW2iE121Sro7Pc1TxujxXIjvZ PUPN/UzhKdLksTaZZ7CQEioGFgpJcHTZOHDpfmDVe12dANU4EpiueENyx6Um dwXnp17GeMESRw6KLHRJRqtdTCaVCp8ujUvrnmw9+tFbUKSgQw6qoxfpJKk3 BImRz5fJbDBQVxW4oob+vYvZZbmoZpZR3Hd44ZCKVyayM3h+Gt+ui+RKQ/sx n6rUOAYkMXXXWxlbT6YrDkQAZYbNPFK0UgP5KcXijFEbJkykqskaBk7xuNPq rBxtcsf48ILvUA7rrMZyKsGbmaNaaPKx7J4YzudztnL+p9HwvL7wXapOX4Qj pEkPTpoceBwkndA6UYJ1KcCECoFrY86TNHPccSVZP0hD+C2co9euVlDINDeE r2ru4jl5oE4WrjPcTE8u2K40vr0RMJNRtaIT4YnfaaMF5Hkl0QjJX2EkyMh4 tuUuDZoGjTSENQyZ2ykzKFBOifsbdW5n63gZSzjUNOdzHe7AGotgo+imKDVh 5DHmjT7cWBA6i0EIFDHm7o+8GaDT4ShxCK1ekXEpNcRsEcAiv9AzDQ9DxKSK Ii+/V4fe9p9cP2TaD7Vy6cyF4g4v0A6utTR7ErK3kPKQcNdKk6S0WFjdCy6d 0F9LeJ7lvYVyZ1wBjlhcrQ9SGNBiGVGQApqJLVXZdCRXhogzOnCJghhz8QI5 rD0KYZsw64LSKizakYTNbHYEkSU3c5pYX/HzWVh8qmLNGnKUGeymN4INTOl9 jqCQbB6zIoknj3KUJyBkJUcRryGfwK3beCibBoJzNG5VZAM1GMg7ayBzwpMj y5/UY5LJenN9WiyO6YVV9Cv92XGOEOHNDf9ffoWqgegA6CKYwkKP8jmWMe9v Oqcm+Whp09Rr8aY4djRyjJQ0L2azT7eIhbLvjWbRlwfnnyzR/laeYe2EaRXl ScQ3+IygOGDeusI8ULmQjudECJYFIAD1gKV/p4DibeAi4z938E9pjH20y7Aw M+sxCS45RDp1pYtBPm66zmihpEsbZavdljVnkmmGbHBWIKWeVD8Ai+mC9s84 jLBxvEhD4tWvfD42XOuB3nxDPSbR+HMb716W0XVMAO9uNAzRANyouN28I0BT k2XGplKr65C7EdjQkm1gGr1fpvPNJOTzBRQHJSkESUC+13wl/Ol2pJOQgAEJ rJzI6bcJMUN0liPeNxSUWEWSnVJ4LS+MANnSmVEyGeRNoDVjun+L+SjNLzPF wmMUPNEFEi2wYHJzfJYM90DJ16W9fOyaL1j6TjJYC5om4LEOgNdy0TTPMiMZ /C11V04qSiSSvdHigpZZ5EmVF2fwuqgRWJG05XgZ4GLbhCuO4TmV6lbLLaNK X5VPg6VJx0liWZuNoBnbN05fgA9xWlXQM2Bec3hN/JSOMH9ckV73NG/8DIe1 Gap2NiGrgJqdUC1SizFxZOetOp7Z6kIyFyyjVXu9S3OVeXyqTBDxE07mKMh0 pDU4dvLubr8wymsjfQhXwGG0hbAuAXtFEOHGtB4kqg06SqKbVs/huBraLLwr dxEZHuaqlyB+OJQ6rtfQcOGoXozJRx4XTQmVBialTCRXasXH2ZgPJB6kD1Xp 9OV5UC72eTRL5kqQdxBVmv3rJpkn1rKvEMbPx4BsME9bxUUZYALGOgDIZGE8 KrHMaMnumzaL+xohW8vZxI7QEHraBmjQtXUq0xRdLDK1W7WzJ2TfmWpRAy7e RAxZBeVqAd2QWVPowViOgVNYLasLTup0/OY6SAz2et/aXObta8GuYLCbDXvN 7JbFUqHLnzMRSiwsHFQz/DB0dgkHGnGMhRi7KI4Y5b062+0WgsqeseUJSEIz mJb8NTPeOBrT/v5rsko11Hxkd37pz54wRHLoiGL0iSDKpBGOpcFDMFXTWSzF xMIjSpkZo8Th7OHkn8kGP00SAGwlZ/ml1EBxznT4x7S5rRk2K0yis3UAdY6b oVNcSezpdebv7YRlZGtkR5f9VP+zOoBipELQlIV5CX8/4yDL8VKSLcpfP9Ga R+YYpz3hsqhD0aBe/E2xYAxR85JnOI3PK6Tx+TpqJJmXfJAdrcia5LKIZcDS RrJHKPsQfPpZ3tUvwRnQLb0ul6swzq6nzqbV6dprpSwUkLRpomzF/pectiYO 1dWePwz9dCCVGKbGmRwv00iWDuRgKhhvrka/gKZr0ZB3Zes5YqBN5pL8DggR c27JpApqHggDrabUsoLMBDYG+rSelBoISC9yGVDeLNgLJqdYzhkJyjSpf0/U GeunNOLlOAjUfpPPs2eq4sVYVueEk0t+uAYYKUUWpvwbelapcBeFrEHZ7BjP xQWkWhXKxwjNfocjN/I+42IuUnwSecrrNbW0m+JbNY6jPLMVixkeugzVdHyi ipMIJo5mfldNaWZ8BrQbLpdQthUKasU8dpa86juXKr6KikWOm1gdwyDT2lxf msC4DfPRFwV/vaZsebzSLNzZaiqiNC6Gaom3l68Pj6VGHSXqD/dQoo4C05wf lx0AD/t6Nga16nV27/Dg9Ybfnm9u6BOcFl/FnEMoUG8mMCrTHXHouRio8IWj dEoOtRw4fTYTsUFGQRalVQYXCmXRQqSAbwBdAgqdL0IigpyxHHrWMVkTmsKg yZkTQDDYLKahKpoCbloJdrll3eNW3tUnQaNGCoBdLJCDPG2sa+xNEWAhb3bK oaJQX+PQX2NowDPuXV8m7pdpkLOzlqbW0kJks5Cjd5Fq1ilG7qfrWvh14EZS 6O/QScWJI4nJpqdpuzeflEvVuwS6kauATIQh4oalCNOSTEGJ+aXzgvnhWnY1 SJJMnqTCgL2FKtfBcIbCSzcKcdQNzSlEagODk68BmzP6WeJCum9pn06Ls5xG REopazMj5WxV+LK5dgN01oXKEa1ZGPs78anQ8rQd783mhB2zHMcRnNvOyeEY 1nP4HQ7ioOMUKR0TmcfD9+HSZnFSqDCQDhDXoVH1jbg+HcOK4cW0HhqwD2Gn C1RG/8T3h/5zDedHS/F4Fwj1mPQDkSbmyZsuKHcwbhaE4ZySTxsWBwd5DXiP rs3FYN7oM1fn1WDAlOJyC3DJyADbZD1k3eMkKP0pNAGYBNlngcetzRcJvIID b11TWtZP7UhvXP1bqmSSChxZW6WYItJkNyH4kQnF4eBk0zDitA3GAwY2IEZG krUupnM9b6OPQgfJmVuzUuUsJM0kwey6TqAfXJlhC57msRZAreuxAbJOguaQ WdjVaTFpp1Vf8AsZsEIvPQ5q3uSfKkdKaGPiSSkP3jiUDyazpSHgnfZlWDAO fbJ2jG1ZQu+aFtRqWeh6PHCjGPVRLxSS+1kTzMpZ9XS//vFNEeWQUtJiqqRn WkVovP86DaCAF8UAXOYLLXU64Ej+7KknLj0g16FcCt55xpCqS2r281cCu3Rk q4piMKlO5lGqW5Kp4axH5vSjCmC3K8+XpoBAjxI0OMN+EzCSo7QSr2aUz2v4 WF42wd/WUle2C04Q/tMdTg2aO0nblligHHYk4TKMP2fWybOshnLIWEgcacyl tSar69vGkcKk+j7dmhQMhfcW2EbO+DJXvUQ9Vs5LWV61yOdJyjOcRnKH5baG oxNmVqMMr9roFTgogMFn9ThGc5aTa4OPhFleqjZG2IRScxb3omR3S08+dpLj bek5kJLF8FUxnV5wavycX0/ngiRQI8pBJ4YUwo+bI3lR5BLCnF1n0TVr3CKh W3KCA/5WAvLY/3a/lcU+SbD+wFjMKvllrlEFXPpSRVOOdCtHjx2ZZlWvt884 avIzK85FKRVSMwLRPy4E1uTPcINsB1xDYsH6WFS/ppceHtKGVM7nRba/uiB3 pZJyfr58yJdzrgZr8zsyGCGTfJxPiuzed++PN0Crpppr9E+QjTGXB82l2VDN rKmyyQGplE3cF0+m8Ak1uUEPe5m8oLYG2IRf1GQ1v3992ED/0PkFnw4/fEOt sQA1g/9KUVwkUzu02FCAXTITlkM04gH0LPBvwgnu9X71D/TX3y4mo2L8e5G9 wRqte/lG9j37Mdnw/nbQzaH3GN7f2exlvUOa2GRKnvayLPvt4fvhu7fHv++l /H0ndPAaZL8BI0wOJ+MZ/e0dPIvRT9cf6a+bEn35NR2hplcF/bS/r27WuHEn cqro/lpzWCz6A8V2zDBMDEgZBHa84fNFPlkOGncY48MhQza8a0cvQzPofvbd aFkhAbpzf+dh89JfnS+X9KJbW0jT05gCu8jgj81qcbZFc3/rfHkx3Vr/hK83 qb+/xjrYH6FsYFqMxXzWvZunUpxRjP+xP6HDfdH/1FxTGpNBzAQbCBcYAc1G DlpJLU5fGwvghmZKvprSnj2ZkAn5JHC9fPaxFkGjm+d0+QeaWJ8kpXnzEpwT MMzP7ZOTc3rIh/LsjIbdPjsGKjWnyUgHN7zXwWpa0O1n9v1hPqvq7A1527Q9 fCzDdc9ofR3Hm0zoHgfFtLRP3hXT0TkkKPcLGLxw2ct8+rHKjlHn8tPHwj59 Tv7OmPwGMkOzivw4+/wVGbrsxU8/0amjCC16hlB3zpMvPH9ULZfZEflc4UrA lEqyAwvpq/D+ZMpe0g5Dhs4+Papgkan3rqflVWg/jPazsj6v5uGjfFr+z3/l 2Q+rP/9HOSv//K/2xX//O8oyfriejfwbndLbVNMivMvzkqb2D7TYXq3Oqk8x z4xxK8ml/yFHuLOoyYZ9CpE+rWPnUMyiuCw1PiQhDfbRX8+cby8ONUgRKiB5 OQgop6KKDHeYpJoDnIW9TrNwfn7KjHuzoM/eXJHf9JG264/os82GcfnAT7mu VuFJXG2kVYa/Isv5tWzzgMaoFHMp4OGePe2fDHP36uTdW6Fzfv6SIaiGSs5r f4OA0eO1I5rOg548y1wxuuYPp+b2AO1rSBc+DJiicKjbz+5Fpe9y0sP7pP2H F+In0D0LCdtdKC2DHg2zajYy2hpgQeoe9TG4k8TVO3p58Jt3bzc3MGaW6UFk TVtAJnfnDzd7Dz7h/yP+B2Qc//ff/nO0sbXDn+49EIuT9P/hlE8zOjvw9D6X NdeolXlL3sGKrEw/UJxpQKqagQWtd7y8ppZ+s0IgKxjEq6urTbr5sKDtt1qw OazxuzP8bAuzbWfrq9Ke8eNUn/F1DwM3LUAulWGuAWkdfRRJHRnrg+5CdSBQ UARoOMr1os77hdCKkSNYA0EoT3MsTjjtgUhnwmWpZCsWdRok6M2lj0J1tPEj 9MMpqe+SbjKaWjwGMwKg/gdjM+xxuuKqOEUJVi92WnG6ifQo9Qj3GP17C9vO /Z3tB/ef7Dx4+HjL9y8ykJtn1eUW/jK0qsnhtDxFeZh8KpgK6o1hzfq4Q3Hv xEcbyioflpGErf6KD13bX/dQ5qKlNOcmQcioDlRtWkCOfM/TMjcOEuNcyGl/ O1uRQ7XZ65/E3mHYgka/mZyJ7jZQnIqedMLBg31sCBbSIYFGmqds7/8A5eFa G5zOAQA= --> </rfc>