rfc9958.original.xml   rfc9958.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2. 3) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.35 (Ruby 2.5. 9) -->
<?rfc strict="yes"?> <?rfc strict="yes"?>
<?rfc comments="yes"?> <?rfc comments="yes"?>
<?rfc docmapping="yes"?> <?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-pquip-pqc-engineers-14" category="info" consensus="true" submissionType="I -ietf-pquip-pqc-engineers-14" category="info" consensus="true" submissionType="I
ETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> ETF" xml:lang="en" number="9958" tocInclude="true" sortRefs="true" symRefs="true
<!-- xml2rfc v2v3 conversion 3.30.1 --> " version="3">
<!-- xml2rfc v2v3 conversion 3.33.0 -->
<link href="https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers-14
" rel="prev"/>
<front> <front>
<title abbrev="PQC for Engineers">Post-Quantum Cryptography for Engineers</t itle> <title abbrev="PQC for Engineers">Post-Quantum Cryptography for Engineers</t itle>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-engineers-14"/ > <seriesInfo name="RFC" value="9958"/>
<author fullname="Aritra Banerjee"> <author fullname="Aritra Banerjee">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<city>London</city> <city>London</city>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>aritra.banerjee@nokia.com</email> <email>aritra.banerjee@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Tirumaleswar Reddy"> <author fullname="Tirumaleswar Reddy.K">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<country>India</country> <country>India</country>
</postal> </postal>
<email>k.tirumaleswar_reddy@nokia.com</email> <email>k.tirumaleswar_reddy@nokia.com</email>
</address> </address>
</author> </author>
skipping to change at line 54 skipping to change at line 55
<country>Greece</country> <country>Greece</country>
</postal> </postal>
<email>dimitrios.schoinianakis@nokia-bell-labs.com</email> <email>dimitrios.schoinianakis@nokia-bell-labs.com</email>
</address> </address>
</author> </author>
<author fullname="Timothy Hollebeek"> <author fullname="Timothy Hollebeek">
<organization>DigiCert</organization> <organization>DigiCert</organization>
<address> <address>
<postal> <postal>
<city>Pittsburgh</city> <city>Pittsburgh</city>
<country>USA</country> <region>PA</region>
<country>United States of America</country>
</postal> </postal>
<email>tim.hollebeek@digicert.com</email> <email>tim.hollebeek@digicert.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Ounsworth" fullname="Mike Ounsworth"> <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
<organization abbrev="Entrust">Entrust Limited</organization> <organization abbrev="Entrust">Entrust Limited</organization>
<address> <address>
<postal> <postal>
<street>2500 Solandt Road – Suite 100</street> <street>2500 Solandt Road, Suite 100</street>
<city>Ottawa, Ontario</city> <city>Ottawa, Ontario</city>
<code>K2K 3G5</code> <code>K2K 3G5</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>mike.ounsworth@entrust.com</email> <email>mike.ounsworth@entrust.com</email>
</address> </address>
</author> </author>
<date year="2025" month="August" day="26"/> <date year="2026" month="April"/>
<area>Security</area> <area>SEC</area>
<workgroup>PQUIP</workgroup> <workgroup>pquip</workgroup>
<keyword>PQC</keyword> <keyword>PQC</keyword>
<abstract> <abstract>
<?line 263?> <?line 638?>
<t>The advent of a cryptographically relevant quantum computer (CRQC) would rend <!-- Status of I-Ds in references section:
er state-of-the-art, traditional public key algorithms deployed today obsolete,
as the mathematical assumptions underpinning their security would no longer hold [I-D.bonnell-lamps-chameleon-certs]
. To address this, protocols and infrastructure must transition to post-quantum draft-bonnell-lamps-chameleon-certs-07
algorithms, which are designed to resist both traditional and quantum attacks. T IESG State: I-D Exists as of 11/26/25
his document explains why engineers need to be aware of and understand post-quan
tum cryptography (PQC), detailing the impact of CRQCs on existing systems and th [I-D.connolly-cfrg-xwing-kem]
e challenges involved in transitioning to post-quantum algorithms. Unlike previo draft-connolly-cfrg-xwing-kem-09
us cryptographic updates, this shift may require significant protocol redesign d IESG State: I-D Exists as of 11/26/25
ue to the unique properties of post-quantum algorithms.</t>
[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-constrai
ned.
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>.
-->
<!-- XML for reference update (draft-ietf-pquip-pqc-hsm-constrained):
<reference anchor="I-D.ietf-pquip-pqc-hsm-constrained" target="https://datatrack
er.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 rend
er 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. T
his document explains why engineers need to be aware of and understand post-quan
tum cryptography (PQC), and it details the impact of CRQCs on existing systems a
nd the challenges involved in transitioning to post-quantum algorithms. Unlike p
revious cryptographic updates, this shift may require significant protocol redes
ign due to the unique properties of post-quantum algorithms.</t>
</abstract> </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/bro
wse/pqc/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/pqc/"/>
.
</t>
</note>
</front> </front>
<middle> <middle>
<?line 267?> <?line 734?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Quantum computing is no longer just a theoretical concept in computatio nal science and physics; it is now an active area of research with practical imp lications. Considerable research efforts and enormous corporate and government f unding for the development of practical quantum computing systems are currently being invested. At the time this document is published, cryptographically releva nt quantum computers (CRQCs) that can break widely used asymmetric algorithms (a lso known as public key algorithms) are not yet available. However, there is ong oing research and development in the field of quantum computing, with the goal o f building more powerful and scalable quantum computers.</t> <t>Quantum computing is no longer just a theoretical concept in computatio nal science and physics; it is now an active area of research with practical imp lications. Considerable research efforts and enormous corporate and government f unding for the development of practical quantum computing systems are currently being invested. At the time this document is published, cryptographically releva nt quantum computers (CRQCs) that can break widely used asymmetric algorithms (a lso known as public key algorithms) are not yet available. However, there is ong oing research and development in the field of quantum computing, with the goal o f 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 genera l-purpose CPUs only on specific types of problems, so will quantum computers, to o, have a niche set of problems on which they excel. Unfortunately for cryptogra phers, integer factorization and discrete logarithms, the mathematical problems underpinning much of classical public key cryptography, happen to fall within th e niche that quantum computers are expected to excel at. As quantum technology a dvances, there is the potential for future quantum computers to have a significa nt impact on current cryptographic systems. Predicting the date of emergence of a CRQC is a challenging task, and there is ongoing uncertainty regarding when th ey will become practically feasible <xref target="CRQCThreat"/>.</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 genera l-purpose CPUs only on specific types of problems, quantum computers also have a niche set of problems on which they excel. Unfortunately for cryptographers, in teger factorization and discrete logarithms, the mathematical problems underpinn ing much of classical public key cryptography, happen to fall within the niche i n which quantum computers are expected to excel. As quantum technology advances, there is the potential for future quantum computers to have a significant impac t on current cryptographic systems. Predicting the date of emergence of a CRQC i s 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 algo rithms 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 require s a combination of engineering efforts, proactive assessment and evaluation of a vailable technologies, and a careful approach to product development and deploym ent.</t> <t>Extensive research has produced several post-quantum cryptographic algo rithms 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 require s a combination of engineering efforts, proactive assessment and evaluation of a vailable technologies, and a careful approach to product development and deploym ent.</t>
<t>PQC is sometimes referred to as "quantum-proof", "quantum-safe", or "qu antum-resistant". It is the development of cryptographic algorithms designed to secure communication and data in a world where quantum computers are powerful en ough to break traditional cryptographic systems, such as RSA (Rivest–Shamir–Adle man) and ECC (Elliptic Curve Cryptography). PQC algorithms are intended to be re sistant to attacks by quantum computers, which use quantum-mechanical phenomena to solve mathematical problems that are infeasible for classical computers.</t> <t>PQC is sometimes referred to as "quantum-proof", "quantum-safe", or "qu antum-resistant". It is the development of cryptographic algorithms designed to secure communication and data in a world where quantum computers are powerful en ough to break traditional cryptographic systems, such as RSA (Rivest-Shamir-Adle man) and ECC (Elliptic Curve Cryptography). PQC algorithms are intended to be re sistant 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 designin g, maintaining, and securing cryptographic systems must prepare for the signific ant changes that the existence of CRQCs will bring. Engineers need to understand how to implement post-quantum algorithms in applications, how to evaluate the t rade-offs between security and performance, and how to ensure backward compatibi lity with current systems where needed. This is not merely a one-for-one replace ment of algorithms; in many cases, the shift to PQC will involve redesigning pro tocols and infrastructure to accommodate the significant differences in resource utilization and key sizes between traditional and PQC algorithms. Due to the wi de-ranging nature of these impacts, discussions of protocol changes are integrat ed throughout this document rather than being confined to a single section.</t> <t>As the threat of CRQCs draws nearer, engineers responsible for designin g, maintaining, and securing cryptographic systems must prepare for the signific ant changes that the existence of CRQCs will bring. Engineers need to understand how to implement post-quantum algorithms in applications, how to evaluate the t rade-offs between security and performance, and how to ensure backward compatibi lity with current systems where needed. This is not merely a one-for-one replace ment of algorithms; in many cases, the shift to PQC will involve redesigning pro tocols and infrastructure to accommodate the significant differences in resource utilization and key sizes between traditional and PQC algorithms. Due to the wi de-ranging nature of these impacts, discussions of protocol changes are integrat ed throughout this document rather than being confined to a single section.</t>
<t>This document aims to provide general guidance to engineers working on <t>This document aims to provide general guidance to engineers working on
cryptographic libraries, network security, and infrastructure development, where cryptographic libraries, network security, and infrastructure development, where
long-term security planning is crucial. The document covers topics such as sele long-term security planning is crucial. The document covers topics such as sele
cting appropriate PQC algorithms, understanding the differences between PQC key cting appropriate PQC algorithms and understanding the differences between PQC K
encapsulation mechanisms (KEMs) and traditional Diffie-Hellman and RSA style key ey Encapsulation Mechanisms (KEMs) and traditional Diffie-Hellman (DH) and RSA-s
exchanges, and provides insights into expected key, ciphertext, and signature s tyle key exchanges, and it provides insights into expected differences in keys,
izes and processing time differences between PQC and traditional algorithms. Add ciphertext, signature sizes, and processing times between PQC and traditional al
itionally, it discusses the potential threat to symmetric cryptography and hash gorithms. Additionally, it discusses the potential threat to symmetric cryptogra
functions from CRQCs.</t> phy and hash functions from CRQCs.</t>
<t>It is important to remember that asymmetric algorithms (also known as p <t>It is important to remember that asymmetric algorithms (also known as p
ublic key algorithms) are largely used for secure communications between organiz ublic key algorithms) are largely used for secure communications between organiz
ations or endpoints that may not have previously interacted, so a significant am ations or endpoints that may not have previously interacted, so a significant am
ount of coordination between organizations, and within and between ecosystems ne ount of coordination between organizations, and within and between ecosystems, n
eds to be taken into account. Such transitions are some of the most complicated eeds 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 in the tech industry and will require staged migrations in which upgraded agent
need to co-exist and communicate with non-upgraded agents at a scale never befo s need to coexist and communicate with non-upgraded agents at a scale never befo
re undertaken.</t> re undertaken.</t>
<t>The National Security Agency (NSA) of the United States released an art <t>The National Security Agency (NSA) of the United States released an art
icle on future PQC algorithm requirements for US national security systems <xref icle 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 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 r the future. The German Federal Office for Information Security (BSI) has also r
eleased a PQC migration and recommendations document <xref target="BSI-PQC"/> wh eleased a PQC migration and recommendations document <xref target="BSI-PQC"/> th
ich largely aligns with United States National Institute of Standards and Techno at largely aligns with United States National Institute of Standards and Technol
logy (NIST) and NSA guidance, but differs in aspects such as specific PQC algori ogy (NIST) and NSA guidance but differs in aspects such as specific PQC algorith
thm profiles.</t> m profiles.</t>
<t>CRQCs pose a threat to both symmetric and asymmetric cryptographic sche <t>CRQCs pose a threat to both symmetric and asymmetric cryptographic sche
mes. However, the threat to asymmetric cryptography is significantly greater due mes. However, the threat to asymmetric cryptography is significantly greater due
to Shor's <xref target="Shors"/> algorithm, which can break widely-used public to Shor's algorithm <xref target="Shors"/>, which can break widely used public
key schemes like RSA and ECC. Symmetric cryptography and hash functions face a l key schemes like RSA and ECC. Symmetric cryptography and hash functions face a l
ower risk from Grover's <xref target="Grovers"/> algorithm, although the impact ower risk from Grover's algorithm <xref target="Grovers"/>, although the impact
is less severe and can typically be mitigated by doubling key and digest lengths 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 when th where the risk applies. It is crucial for the reader to understand that when "P
e word "PQC" is mentioned in the document, it means asymmetric cryptography (or QC" is mentioned in the document, it means asymmetric cryptography (or public ke
public key cryptography), and not any symmetric algorithms based on stream ciphe y cryptography) and not any symmetric algorithms based on stream ciphers, block
rs, block ciphers, hash functions, MACs, etc., which are less vulnerable to quan ciphers, hash functions, MACs, etc., which are less vulnerable to quantum comput
tum computers. This document does not cover such topics as when traditional algo ers. This document does not cover topics such as when traditional algorithms mig
rithms might become vulnerable (for that, see documents such as <xref target="QC ht become vulnerable (for that, see documents such as <xref target="QC-DNS"/> an
-DNS"/> and others).</t> d others).</t>
<t>This document does not cover unrelated technologies like quantum key di <t>This document does not cover unrelated technologies like quantum key di
stribution (QKD) or quantum key generation, which use quantum hardware to exploi stribution (QKD) or quantum key generation, which use quantum hardware to exploi
t quantum effects to protect communications and generate keys, respectively. PQC t quantum effects to protect communications and generate keys, respectively. PQC
is based on conventional math (not on quantum mechanics) and software and can b is based on conventional math (not on quantum mechanics) and software, and it c
e run on any general purpose computer.</t> an be run on any general-purpose computer.</t>
<t>This document does not go into the deep mathematics or technical specif <t>This document does not go into the deep mathematics or technical specif
ication of the PQC algorithms, but rather provides an overview to engineers on t ication of the PQC algorithms but rather provides an overview to engineers on th
he current threat landscape and the relevant algorithms designed to help prevent e current threat landscape and the relevant algorithms designed to help prevent
those threats. Also, the cryptographic and algorithmic guidance given in this d those threats. Also, the cryptographic and algorithmic guidance given in this do
ocument should be taken as non-authoritative if it conflicts with emerging and e cument should be taken as non-authoritative if it conflicts with emerging and ev
volving guidance from the IRTF's Crypto Forum Research Group (CFRG).</t> olving guidance from the IRTF's Crypto Forum Research Group (CFRG).</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>Quantum computer: A computer that performs computations using quantum-m <dl>
echanical phenomena such as superposition and entanglement.</t> <dt>Quantum computer:</dt>
<t>Physical qubit: The basic physical unit in a quantum computer, which is <dd>
prone to noise and errors.</t> <t>A computer that performs computations using quantum-mechanical phen
<t>Logical qubit: A fault-tolerant qubit constructed from multiple physica omena such as superposition and entanglement.</t>
l qubits using quantum error correction; it is the effective unit for reliable q </dd>
uantum computation.</t> <dt>Physical qubit:</dt>
<t>Post-Quantum Cryptography (PQC): Cryptographic algorithms designed to b <dd>
e secure against quantum and classical attacks.</t> <t>The basic physical unit in a quantum computer, which is prone to no
<t>Cryptographically Relevant Quantum Computer (CRQC): A quantum computer ise and errors.</t>
with sufficient logical qubits to break traditional asymmetric cryptographic alg </dd>
orithms (e.g., RSA or ECC) within a practical timeframe.</t> <dt>Logical qubit:</dt>
<t>Public Key Cryptography (also called Asymmetric Cryptography): A class <dd>
of cryptographic algorithms in which separate keys are used for encryption and d <t>A fault-tolerant qubit constructed from multiple physical qubits us
ecryption, or for signing and verification. Throughout this document, the terms ing quantum error correction; it is the effective unit for reliable quantum comp
Public Key Cryptography and Asymmetric Cryptography are used interchangeably.</t utation.</t>
> </dd>
<t>There is ongoing discussion about whether to use the term "post-quantum <dt>Post-Quantum Cryptography (PQC):</dt>
", "quantum ready", "quantum resistant", or "quantum secure", to describe algori <dd>
thms that resist CRQCs, and a consensus has not yet been reached. NIST has coine <t>Cryptographic algorithms designed to be secure against quantum and
d the term "post-quantum" to refer to the algorithms that participated in its co classical attacks.</t>
mpetition-like selection process; in this context, the term can be interpreted t </dd>
o mean "the set of algorithms that are designed to still be relevant after quan <dt>Cryptographically Relevant Quantum Computer (CRQC):</dt>
tum computers exist", and not a statement about their security. "Quantum resista <dd>
nt" or "quantum secure" is obviously the goal of these algorithms, however some <t>A quantum computer with sufficient logical qubits to break traditio
people have raised concerns that labelling a class of algorithms as "quantum res nal asymmetric cryptographic algorithms (e.g., RSA or ECC) within a practical ti
istant" or "quantum secure" could lead to confusion if one or more of those algo meframe.</t>
rithms are later found to be insecure or to not resist quantum computers as much </dd>
as theory predicted. "Quantum ready" is often used to refer to a solution -- de <dt>Public Key Cryptography (also called Asymmetric Cryptography):</dt>
vice, appliance, or software stack -- that has reached maturity with regards to <dd>
integration of these new cryptographic algorithms. That said, the authors recogn <t>A class of cryptographic algorithms in which separate keys are used
ize that there is great variability in how these terms are used. This document u for encryption and decryption or for signing and verification. Throughout this
ses any of these terms interchangeably to refer to such algorithms.</t> document, the terms Public Key Cryptography and Asymmetric Cryptography are used
<t>The terms "current," "state-of-the-art," and "ongoing," as used in this interchangeably.</t>
document, refer to work, research, investigations, deployments, or developments </dd>
that are applicable at the time of publication.</t> </dl>
<t>There is ongoing discussion about whether to use the term "post-quantum
", "quantum ready", "quantum resistant", or "quantum secure" to describe algorit
hms 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 com
petition-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 quant
um computers exist" and not a statement about their security. "Quantum resistant
" or "quantum secure" is obviously the goal of these algorithms; however, some p
eople have raised concerns that labeling a class of algorithms as "quantum resis
tant" or "quantum secure" could lead to confusion if one or more of those algori
thms are later found to be insecure or to not resist quantum computers as much a
s theory predicted. "Quantum ready" is often used to refer to a solution -- devi
ce, appliance, or software stack -- that has reached maturity with regard to int
egration of these new cryptographic algorithms. That said, the authors recognize
that there is great variability in how these terms are used. This document uses
these terms interchangeably to refer to such algorithms.</t>
<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>
<section anchor="threat-of-crqcs-on-cryptography"> <section anchor="threat-of-crqcs-on-cryptography">
<name>Threat of CRQCs on Cryptography</name> <name>Threat of CRQCs on Cryptography</name>
<t>When considering the security risks associated with the ability of a qu antum computer to attack traditional cryptography, it is important to distinguis h 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 thin ks of security under the presence of a CRQC.</t> <t>When considering the security risks associated with the ability of a qu antum computer to attack traditional cryptography, it is important to distinguis h 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 thin ks of security under the presence of a CRQC.</t>
<t>Quantum computers are, by their nature, hybrids of classical and quantu m computational units. For example, Shor's algorithm consists of a combination o f quantum and classical computational steps. Thus, the term "quantum adversary" should be thought of as "quantum-enhanced adversary", meaning they have access t o both classical and quantum computational techniques.</t> <t>Quantum computers are, by their nature, hybrids of classical and quantu m computational units. For example, Shor's algorithm consists of a combination o f quantum and classical computational steps. Thus, the term "quantum adversary" should be thought of as "quantum-enhanced adversary", meaning they have access t o both classical and quantum computational techniques.</t>
<t>Despite that large-scale quantum computers do not yet exist to experime nt on, the theoretical properties of quantum computation are very well understoo d. This allows engineers and researchers to reason about the upper limits of qu antum-enhanced computation, and indeed to design cryptographic algorithms that a re resistant to any conceivable form of quantum cryptanalysis.</t> <t>Although large-scale quantum computers do not yet exist to experiment o n, the theoretical properties of quantum computation are very well understood. This allows engineers and researchers to reason about the upper limits of quantu m-enhanced computation and to design cryptographic algorithms that are resistant to any conceivable form of quantum cryptanalysis.</t>
<section anchor="symmetric"> <section anchor="symmetric">
<name>Symmetric Cryptography</name> <name>Symmetric Cryptography</name>
<t>For unstructured data such as symmetric encrypted data or cryptograph ic 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. Symmetr ic-key cryptography, which includes keyed primitives such as block ciphers (e.g. , AES) and message authentication mechanisms (e.g., HMAC-SHA256), relies on secr et 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-2 56) that are used for secure message digesting without any shared key material. 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 authent ication code.</t> <t>For unstructured data such as symmetric encrypted data or cryptograph ic 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. Symmetr ic-key cryptography, which includes keyed primitives such as block ciphers (e.g. , AES) and message authentication mechanisms (e.g., HMAC-SHA256), relies on secr et 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-2 56) that are used for secure message digesting without any shared key material. Hashed Message Authentication Code (HMAC) is a specific construction that utiliz es 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 theo retical quadratic speedup for searching an unstructured database, compared to tr aditional search algorithms. <t>Grover's algorithm is a quantum search algorithm that provides a theo retical quadratic speedup for searching an unstructured database, compared to tr aditional search algorithms.
This has led to the common misconception that symmetric key lengths need to be d This has led to the common misconception that symmetric key lengths need to be d
oubled for quantum security. When you consider the mapping of hash values to the oubled for quantum security. When you consider the mapping of hash values to the
ir corresponding hash inputs (also known as pre-image), or of ciphertext blocks ir corresponding hash inputs (also known as pre-image) or of ciphertext blocks t
to the corresponding plaintext blocks, as an unstructured database, then Grover’ o the corresponding plaintext blocks as an unstructured database, then Grover's
s algorithm theoretically requires doubling the key sizes of the symmetric algor algorithm theoretically requires doubling the key sizes of the symmetric algorit
ithms that are currently deployed at the time of publication to counter the quad hms that are currently deployed at the time of publication to counter the quadra
ratic speedup and maintain current security level. This is because Grover’s algo tic speedup and maintain the current security level. This is because Grover's al
rithm reduces the amount of operations to break 128-bit symmetric cryptography t gorithm reduces the amount of operations to break 128-bit symmetric cryptography
o 2^{64} quantum operations, which might sound computationally feasible. However to 2^{64} quantum operations, which might sound computationally feasible. Howev
, quantum operations are fundamentally different from classical ones as 2^{64} c er, quantum operations are fundamentally different from classical ones, as 2^{64
lassical operations can be efficiently parallelized, 2^{64} quantum operations m } classical operations can be efficiently parallelized but 2^{64} quantum operat
ust be performed serially, making them infeasible on practical quantum computers ions must be performed serially, making them infeasible on practical quantum com
.</t> puters.</t>
<t>Grover's algorithm is highly non-parallelizable and even if one deplo <t>Grover's algorithm is highly non-parallelizable and even if one deplo
ys 2^c computational units in parallel to brute-force a key using Grover's algor ys 2^c computational units in parallel to brute-force a key using Grover's algor
ithm, it will complete in time proportional to 2^{(128−c)/2}, or, put simply, us ithm, it will complete in time proportional to 2^{(128-c)/2}, or, put simply, us
ing 256 quantum computers will only reduce runtime by a factor of 16, 1024 quant ing 256 quantum computers will only reduce runtime by a factor of 16, 1024 quant
um computers will only reduce runtime by a factor of 32 and so forth (see <xref um computers will only reduce runtime by a factor of 32, and so forth (see <xref
target="NIST"/> and <xref target="Cloudflare"/>). Due to this inherent limitatio target="NIST"/> and <xref target="Cloudflare"/>). Due to this inherent limitati
n, the general expert consensus is that AES-128 (Advanced Encryption Standard) r on, the general expert consensus is that AES-128 remains secure in practice and
emains secure in practice, and key sizes do not necessarily need to be doubled.< key sizes do not necessarily need to be doubled.</t>
/t> <t>It would be natural to ask whether future research will develop a sup
<t>It would be natural to ask whether future research will develop a sup erior algorithm that could outperform Grover's algorithm in the general case. Ho
erior algorithm that could outperform Grover's algorithm in the general case. Ho wever, Christof Zalka has shown that Grover's algorithm achieves the best possib
wever, Christof Zalka has shown that Grover's algorithm achieves the best possib le complexity for this type of search, meaning no significantly faster quantum a
le complexity for this type of search, meaning no significantly faster quantum a pproach is expected <xref target="Grover-Search"/>.</t>
pproach is expected <xref target="Grover-search"/></t> <!-- [rfced] "CNSA 2.0" is a suite of algorithms from the NSA, not an
<t>Finally, in their evaluation criteria for PQC, NIST is assessing the organization. The organization is the National Security Agency (NSA). May we
security levels of proposed post-quantum algorithms by comparing them against th update the sentence as follows to clarify?
e 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, Current:
even in the presence of both traditional and quantum attacks. As a result, 128-b However, for compliance purposes, some organizations, such as the French
it algorithms can be considered quantum-safe for the foreseeable future. However National Agency for the Security of Information Systems (ANSSI) {{ANSSI}} and
, for compliance purposes, some organizations, such as the French National Agenc CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) {{CNSA2-0}},
y for the Security of Information Systems (ANSSI) <xref target="ANSSI"/> and CNS recommend the use of AES-256.
A 2.0 (Commercial National Security Algorithm Suite 2.0) <xref target="CNSA2-0"/
>, recommend the use of AES-256.</t> Perhaps:
However, for compliance purposes, some organizations, such as the French
National Agency for the Security of Information Systems (ANSSI) {{ANSSI}} and t
he
National Security Agency (NSA) {{CNSA2-0}}, recommend the use of AES-256.
-->
<t>Finally, in their evaluation criteria for PQC, NIST is assessing the security
levels of proposed post-quantum algorithms by comparing them against the equiva
lent traditional and quantum security of AES-128, AES-192, and AES-256. This ind
icates 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 algor
ithms can be considered quantum-safe for the foreseeable future. However, for co
mpliance purposes, some organizations, such as the French National Agency for th
e Security of Information Systems (ANSSI) <xref target="ANSSI"/> and Commercial
National Security Algorithm Suite 2.0 (CNSA 2.0) <xref target="CNSA2-0"/>, recom
mend the use of AES-256.</t>
</section> </section>
<section anchor="asymmetric-cryptography"> <section anchor="asymmetric-cryptography">
<name>Asymmetric Cryptography</name> <name>Asymmetric Cryptography</name>
<t>“Shor’s algorithm” efficiently solves the integer factorization probl <t>"Shor's algorithm" efficiently solves the integer factorization probl
em (and the related discrete logarithm problem), which underpin the foundations em (and the related discrete logarithm problem), which underpin the foundations
of the vast majority of public key cryptography that the world uses today. This of the vast majority of public key cryptography that the world uses today. This
implies that, if a CRQC is developed, today’s public key algorithms (e.g., RSA, implies that, if a CRQC is developed, today's public key algorithms (e.g., RSA,
Diffie-Hellman and elliptic curve cryptography, as well as less commonly-used va Diffie-Hellman, and ECC, as well as less commonly used variants such as ElGamal
riants such as ElGamal <xref target="RFC6090"/> and Schnorr signatures <xref tar <xref target="RFC6090"/> and Schnorr signatures <xref target="RFC8235"/>) and pr
get="RFC8235"/>) and protocols would need to be replaced by algorithms and proto otocols would need to be replaced by algorithms and protocols that can offer cry
cols that can offer cryptanalytic resistance against CRQCs. Note that Shor’s alg ptanalytic resistance against CRQCs. Note that Shor's algorithm cannot run solel
orithm cannot run solely on a classical computer, it requires a CRQC.</t> y on a classical computer; it requires a CRQC.</t>
<t>For example, studies show that, if a CRQC existed, it could break RSA <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 < -2048 in hours or even seconds depending on assumptions about error correction <
xref target="RSAShor"/><xref target="RSA8HRS"/><xref target="RSA10SC"/>. While s xref target="RSAShor"/> <xref target="RSA8HRS"/> <xref target="RSA10SC"/>. While
uch machines are purely theoretical at the time of writing, this illustrates the such machines are purely theoretical at the time of writing, this illustrates t
eventual vulnerability of RSA to CRQCs.</t> he eventual vulnerability of RSA to CRQCs.</t>
<t>For structured data such as public keys and signatures, CRQCs can ful <t>For structured data such as public keys and signatures, CRQCs can ful
ly solve the underlying hard problems used in traditional cryptography (see Shor ly solve the underlying hard problems used in traditional cryptography (see Shor
's algorithm). Because an increase in the size of the key-pair would not provide 's algorithm). Because an increase in the size of the key pair would not provide
a secure solution (short of RSA keys that are many gigabytes in size <xref targ a secure solution (short of RSA keys that are many gigabytes in size <xref targ
et="PQRSA"/>), a complete replacement of the algorithm is needed. Therefore, pos et="PQRSA"/>), a complete replacement of the algorithm is needed. Therefore, pos
t-quantum public key cryptography must rely on problems that are different from t-quantum public key cryptography must rely on problems that are different from
the ones used in traditional public key cryptography (i.e., the integer factoriz the ones used in traditional public key cryptography (i.e., the integer factoriz
ation problem, the finite-field discrete logarithm problem, and the elliptic-cur ation problem, the finite-field discrete logarithm problem, and the elliptic-cur
ve discrete logarithm problem).</t> ve discrete logarithm problem).</t>
</section> </section>
<section anchor="quantum-side-channel-attacks"> <section anchor="quantum-side-channel-attacks">
<name>Quantum Side-channel Attacks</name> <name>Quantum Side-Channel Attacks</name>
<t>Cryptographic side-channel attacks exploit physical implementations, <t>Cryptographic side-channel attacks exploit physical implementations (
such as timing, power consumption, or electromagnetic leakage to recover secret such as timing, power consumption, or electromagnetic leakage) to recover secret
keys.</t> keys.</t>
<t>The field of cryptographic side-channel attacks potentially stands to <t>The field of cryptographic side-channel attacks potentially stands to
gain a boost in attacker power once cryptanalytic techniques can be enhanced wi gain a boost in attacker power once cryptanalytic techniques can be enhanced wi
th quantum computation techniques <xref target="QuantSide"/>. While a full discu th quantum computation techniques <xref target="QuantSide"/>. While a full discu
ssion of quantum side-channel techniques is beyond the scope of this document, i ssion of quantum side-channel techniques is beyond the scope of this document, i
mplementers of cryptographic hardware should be aware that current best-practice mplementers of cryptographic hardware should be aware that current best practice
s for side-channel resistance may not be sufficient against quantum adversaries. s for side-channel resistance may not be sufficient against quantum adversaries.
</t> </t>
</section> <!-- [rfced] We slightly rephrased the following to avoid repetition of
"hence"
(i.e., made new sentence and replaced the first "hence" with "Because of
this"). Please review and let us know any concerns.
Original:
Similar to key agreement, signatures also depend on a public-private
key pair based on the same mathematics as for key agreement and key transport,
and hence a break in existing public key cryptography will also affect
traditional digital signatures, hence the importance of developing
post-quantum digital signatures.
Updated:
Similar to key agreement, signatures also depend on a public-private
key pair based on the same mathematics as for key agreement and key transport.
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.
-->
</section>
</section> </section>
<section anchor="traditional-cryptographic-primitives-that-could-be-replaced -by-pqc"> <section anchor="traditional-cryptographic-primitives-that-could-be-replaced -by-pqc">
<name>Traditional Cryptographic Primitives that Could Be Replaced by PQC</ <name>Traditional Cryptographic Primitives That Could Be Replaced by PQC</
name> name>
<t>Any asymmetric cryptographic algorithm based on integer factorization, <t>Any asymmetric cryptographic algorithm based on integer factorization,
finite field discrete logarithms, or elliptic curve discrete logarithms will be finite field discrete logarithms, or elliptic-curve discrete logarithms will be
vulnerable to attacks using Shor's algorithm on a CRQC. This document focuses on vulnerable to attacks using Shor's algorithm on a CRQC. This document focuses on
the principal functions of asymmetric cryptography:</t> the principal functions of asymmetric cryptography:</t>
<ul spacing="normal"> <dl>
<li> <dt>Key agreement and key transport:</dt>
<t>Key agreement and key transport: Key agreement schemes, typically r <dd>
eferred to as Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH), as we <t>Key agreement schemes, typically referred to as Diffie-Hellman (DH)
ll as key transport, typically using RSA encryption, are used to establish a sha or Elliptic Curve Diffie-Hellman (ECDH), as well as key transport, typically us
red cryptographic key for secure communication. They are one of the mechanisms t ing RSA encryption, are used to establish a shared cryptographic key for secure
hat can be replaced by PQC, as they are based on existing public key cryptograph communication. They are one of the mechanisms that can be replaced by PQC, as th
y and are therefore vulnerable to Shor's algorithm. A CRQC can employ Shor's alg ey are based on existing public key cryptography and are therefore vulnerable to
orithm to efficiently find the prime factors of a large public key (in the case Shor's algorithm. A CRQC can employ Shor's algorithm to efficiently find the pr
of RSA), which in turn can be exploited to derive the private key. In the case o ime factors of a large public key (in the case of RSA), which, in turn, can be e
f Diffie-Hellman, a CRQC has the potential to calculate the discrete logarithm o xploited to derive the private key. In the case of DH, a CRQC has the potential
f the (short or long-term) Diffie-Hellman public key. This, in turn, would revea to calculate the discrete logarithm of the (short- or long-term) DH public key.
l the secret required to derive the symmetric encryption key.</t> This, in turn, would reveal the secret required to derive the symmetric encrypti
</li> on key.</t>
<li> </dd>
<t>Digital signatures: Digital signature schemes are used to authentic <dt>Digital signatures:</dt>
ate the identity of a sender, detect unauthorized modifications to data, and und <dd>
erpin trust in a system. Similar to key agreement, signatures also depend on a p <t>Digital signature schemes are used to authenticate the identity of
ublic-private key pair based on the same mathematics as for key agreement and ke a sender, detect unauthorized modifications to data, and underpin trust in a sys
y transport, and hence a break in existing public key cryptography will also aff tem. Similar to key agreement, signatures also depend on a public-private key pa
ect traditional digital signatures, hence the importance of developing post-quan ir based on the same mathematics as for key agreement and key transport. Because
tum digital signatures.</t> of this, a break in existing public key cryptography will also affect tradition
</li> al digital signatures, hence the importance of developing post-quantum digital s
<li> ignatures.</t>
<t>BBS signatures: BBS (Boneh-Boyen-Shacham) signatures are a privacy- </dd>
preserving signature scheme that offers zero-knowledge proof-like properties by <dt>Boneh-Boyen-Shacham (BBS) signatures:</dt>
allowing selective disclosure of specific signed attributes without revealing th <dd>
e entire set of signed data. The security of BBS signatures relies on the hardne <t>BBS signatures are a privacy-preserving signature scheme that offer
ss of the discrete logarithm problem, making them vulnerable to Shor's algorithm s zero-knowledge proof-like properties by allowing selective disclosure of speci
. A CRQC can break the data authenticity security property of BBS but not the da fic signed attributes without revealing the entire set of signed data. The secur
ta confidentiality (Section 6.9 of <xref target="I-D.irtf-cfrg-bbs-signatures"/> ity of BBS signatures relies on the hardness of the discrete logarithm problem,
).</t> making them vulnerable to Shor's algorithm. A CRQC can break the data authentici
</li> ty security property of BBS but not the data confidentiality (<xref section="6.9
<li> " sectionFormat="of" target="I-D.irtf-cfrg-bbs-signatures"/>).</t>
<t>Content encryption: Content encryption typically refers to the encr </dd>
yption of the data using symmetric key algorithms, such as AES, to ensure confid <dt>Content encryption:</dt>
entiality. The threat to symmetric cryptography is discussed in <xref target="sy <dd>
mmetric"/>.</t> <t>Content encryption typically refers to the encryption of the data u
</li> sing symmetric key algorithms, such as AES, to ensure confidentiality. The threa
</ul> t to symmetric cryptography is discussed in <xref target="symmetric"/>.</t>
</dd>
</dl>
</section> </section>
<section anchor="nist-pqc-algorithms"> <section anchor="nist-pqc-algorithms">
<name>NIST PQC Algorithms</name> <name>NIST PQC Algorithms</name>
<t>At time of writing, NIST have standardized three PQC algorithms, with m ore expected to be standardised in the future (<xref target="NISTFINAL"/>). Thes e 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 a key encapsulation method (KEM) and as a signature scheme, whereas there is currently no post-quantum algorithm that can perform both functions. When upgrading protocols, it is important to replace th e existing use of traditional algorithms with either a PQC KEM or a PQC signatur e method, depending on how the traditional algorithm was previously being used. Additionally, KEMs, as described in <xref target="KEMs"/>, present a different A PI 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> <t>At the time of writing, NIST has standardized three PQC algorithms, wit h more expected to be standardized in the future (see <xref target="NISTFINAL"/> ). These algorithms are not necessarily drop-in replacements for traditional asy mmetric cryptographic algorithms. For instance, RSA <xref target="RSA"/> and ECC <xref target="RFC6090"/> can be used as both a key encapsulation method (KEM) a nd a signature scheme, whereas there is currently no post-quantum algorithm tha t can perform both functions. When upgrading protocols, it is important to repla ce the existing use of traditional algorithms with either a PQC KEM or a PQC sig nature method, depending on how the traditional algorithm was previously being u sed. Additionally, KEMs, as described in <xref target="KEMs"/>, present a differ ent 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 incorpor ated.</t>
<section anchor="nist-candidates-selected-for-standardization"> <section anchor="nist-candidates-selected-for-standardization">
<name>NIST Candidates Selected for Standardization</name> <name>NIST Candidates Selected for Standardization</name>
<section anchor="pqc-key-encapsulation-mechanisms-kems"> <!-- [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).
* [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
been 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).
* [SLH-DSA]: Stateless Hash-Based Digital Signature (FIPS-205).
* [FN-DSA]: FN-DSA is a lattice signature scheme (FIPS-206)
(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> <name>PQC Key Encapsulation Mechanisms (KEMs)</name>
<ul spacing="normal"> <dl>
<li> <dt><xref target="ML-KEM"/>:</dt>
<t><xref target="ML-KEM"/>: Module-Lattice-based Key-Encapsulation <dd>
Mechanism Standard (FIPS-203).</t> <t>Module-Lattice-Based Key-Encapsulation Mechanism Standard (FIPS
</li> 203).</t>
<li> </dd>
<t><xref target="HQC"/>: Hamming Quasi-Cyclic coding algorithm whi <dt><xref target="HQC"/>:</dt>
ch is based on the hardness of the syndrome decoding problem for quasi-cyclic co <dd>
ncatenated Reed-Muller and Reed-Solomon (RMRS) codes in the Hamming metric. Reed <t>Hamming Quasi-Cyclic coding algorithm, which is based on the ha
-Muller (RM) codes are a class of block error-correcting codes commonly used in rdness of the syndrome decoding problem for quasi-cyclic concatenated Reed-Mulle
wireless and deep-space communications, while Reed-Solomon (RS) codes are widely r and Reed-Solomon (RMRS) codes in the Hamming metric. Reed-Muller (RM) codes ar
used to detect and correct multiple-bit errors. HQC has been selected as part o e a class of block error-correcting codes commonly used in wireless and deep-spa
f the NIST post-quantum cryptography project but has not yet been standardized.< ce communications, while Reed-Solomon (RS) codes are widely used to detect and c
/t> orrect multiple-bit errors. HQC has been selected as part of the NIST post-quant
</li> um cryptography project but has not yet been standardized.</t>
</ul> </dd>
</dl>
</section> </section>
<section anchor="pqc-signatures"> <section anchor="pqc-signatures">
<name>PQC Signatures</name> <name>PQC Signatures</name>
<ul spacing="normal"> <dl>
<li> <dt><xref target="ML-DSA"/>:</dt>
<t><xref target="ML-DSA"/>: Module-Lattice-Based Digital Signature <dd>
Standard (FIPS-204).</t> <t>Module-Lattice-Based Digital Signature Standard (FIPS 204).</t>
</li> </dd>
<li> <dt><xref target="SLH-DSA"/>:</dt>
<t><xref target="SLH-DSA"/>: Stateless Hash-Based Digital Signatur <dd>
e (FIPS-205).</t> <t>Stateless Hash-Based Digital Signature (FIPS 205).</t>
</li> </dd>
<li> <dt><xref target="FN-DSA"/>:</dt>
<t><xref target="FN-DSA"/>: FN-DSA is a lattice signature scheme ( <dd>
FIPS-206) (<xref target="lattice-based"/> and <xref target="sig-scheme"/>).</t> <t>FN-DSA is a lattice signature scheme (FIPS 206) (see Sections <
</li> xref target="lattice-based" format="counter"/> and <xref target="sig-scheme" for
</ul> mat="counter"/>).</t>
</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="iso-candidates-selected-for-standardization"> <section anchor="iso-candidates-selected-for-standardization">
<name>ISO Candidates Selected for Standardization</name> <name>ISO Candidates Selected for Standardization</name>
<t>At the time of writing, ISO has selected three PQC KEM algorithms as ca ndidates for standardization, which are mentioned in the following subsection.</ t> <t>At the time of writing, ISO has selected three PQC KEM algorithms as ca ndidates for standardization; these are mentioned in the following subsection.</ t>
<section anchor="pqc-key-encapsulation-mechanisms-kems-1"> <section anchor="pqc-key-encapsulation-mechanisms-kems-1">
<name>PQC Key Encapsulation Mechanisms (KEMs)</name> <name>PQC Key Encapsulation Mechanisms (KEMs)</name>
<ul spacing="normal"> <dl>
<li> <dt><xref target="FrodoKEM"/>:</dt>
<t><xref target="FrodoKEM"/>: Key Encapsulation mechanism based on t <dd>
he hardness of learning with errors in algebraically unstructured lattices.</t> <t>KEM based on the hardness of learning with errors in algebraicall
</li> y unstructured lattices.</t>
<li> </dd>
<t><xref target="ClassicMcEliece"/>: Based on the hardness of syndro <dt><xref target="ClassicMcEliece"/>:</dt>
me decoding of Goppa codes. Goppa codes are a class of error-correcting codes th <dd>
at can correct a certain number of errors in a transmitted message. The decoding <t>KEM based on the hardness of syndrome decoding of Goppa codes. Go
problem involves recovering the original message from the received noisy codewo ppa codes are a class of error-correcting codes that can correct a certain numbe
rd.</t> r of errors in a transmitted message. The decoding problem involves recovering t
</li> he original message from the received noisy codeword.</t>
<li> </dd>
<t><xref target="NTRU"/>: Key encapsulation mechanism based on the " <dt><xref target="NTRU"/>:</dt>
N-th degree Truncated polynomial Ring Units" (NTRU) lattices. Variants include S <dd>
treamlined NTRU Prime (sntrup761), which is leveraged for use in SSH <xref targe <t>KEM based on the "N-th degree Truncated polynomial Ring Units" (N
t="I-D.ietf-sshm-ntruprime-ssh"/>.</t> TRU) lattices. Variants include Streamlined NTRU Prime (sntrup761), which is lev
</li> eraged for use in SSH <xref target="RFC9941"/>.</t>
</ul> </dd>
</dl>
</section> </section>
</section> </section>
<section anchor="timeline"> <section anchor="timeline">
<name>Timeline for Transition</name> <name>Timeline for Transition</name>
<t>The timeline, and driving motivation for transition differs slightly be tween data confidentiality (e.g., encryption) and data authentication (e.g., sig nature) use-cases.</t> <t>The timeline and driving motivation for transition differ slightly betw een data confidentiality (e.g., encryption) and data authentication (e.g., signa ture) 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 resource s 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 encry pted data is susceptible to the attack by not implementing quantum-safe strategi es, as it corresponds to data possibly being deciphered in the future.</t> <t>For data confidentiality, one is concerned with the so-called "harvest now, decrypt later" (HNDL) attack where a malicious actor with adequate resource s 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 encry pted data is susceptible to the attack by not implementing quantum-safe strategi es, 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 sh ort lifetime between signing and verifying (such as during a TLS handshake) but some authentication use-cases do require long lifetimes, such as signing firmwar e or software that will be active for decades, signing legal documents, or signi ng certificates that will be embedded into hardware devices such as smartcards. Even for short-lived signatures use cases, the infrastructure often relies on lo ng-lived root keys which can be difficult to update or replace on in-field devic es.</t> <t>For authentication, it is often the case that signatures have a very sh ort lifetime between signing and verifying (such as during a TLS handshake), but some authentication use cases do require long lifetimes, such as signing firmwa re or software that will be active for decades, signing legal documents, or sign ing certificates that will be embedded into hardware devices such as smart cards . Even for short-lived signature use cases, the infrastructure often relies on l ong-lived root keys, which can be difficult to update or replace on in-field dev ices.</t>
<figure anchor="Mosca"> <figure anchor="Mosca">
<name>Mosca model</name> <name>Mosca Model</name>
<artset> <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"> <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 8,32 L 8,128" fill="none" stroke="black"/>
<path d="M 208,32 L 208,80" 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 296,80 L 296,128" fill="none" stroke="black"/>
<path d="M 440,32 L 440,80" 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,32 L 440,32" fill="none" stroke="black"/>
<path d="M 8,80 L 440,80" 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 312,96 L 440,96" fill="none" stroke="black"/>
<path d="M 8,128 L 296,128" fill="none" stroke="black"/> <path d="M 8,128 L 296,128" fill="none" stroke="black"/>
skipping to change at line 255 skipping to change at line 503
| | | | | |
| y | x | | y | x |
+------------------------+----------+-----------------+ +------------------------+----------+-----------------+
| | <---------------> | | <--------------->
| z | Security gap | z | Security gap
+-----------------------------------+ +-----------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>These challenges are illustrated nicely by the so-called Mosca model di <t>These challenges are illustrated nicely by the so-called Mosca model di
scussed in <xref target="Threat-Report"/>. In <xref target="Mosca"/>, "x" denote scussed in <xref target="Threat-Report"/>. In <xref target="Mosca"/>, "x" denote
s the time that systems and data need to remain secure, "y" the number of years s 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 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 encrypte break current cryptography is available. The model assumes either that encrypte
d data can be intercepted and stored before the migration is completed in "y" ye d data can be intercepted and stored before the migration is completed in "y" ye
ars, or that signatures will still be relied upon for "x" years after their crea ars, or that signatures will still be relied upon for "x" years after their crea
tion. This data remains vulnerable for the complete "x" years of their lifetime, tion. This data remains vulnerable for the complete "x" years of their lifetime;
thus the sum "x+y" gives us an estimate of the full timeframe that data remain thus, the sum "x+y" gives us an estimate of the full timeframe that data remain
insecure. The model essentially asks how one is preparing IT systems during thos s insecure. The model essentially asks how one is preparing IT systems during th
e "y" years (in other words, how one can minimize those "y" years) to minimize t ose "y" years (in other words, how one can minimize those "y" years) to minimize
he transition phase to a PQC infrastructure and hence minimize the risks of data the transition phase to a PQC infrastructure and hence minimize the risks of da
being exposed in the future.</t> ta being exposed in the future.</t>
<t>Finally, other factors that could accelerate the introduction of a CRQC <t>Finally, other factors that could accelerate the introduction of a CRQC
should not be under-estimated, like for example faster-than-expected advances i should not be underestimated, for example, faster-than-expected advances in qua
n quantum computing and more efficient versions of Shor’s algorithm requiring fe ntum computing and more efficient versions of Shor's algorithm requiring fewer q
wer qubits. Innovation often comes in waves, so it is to the industry’s benefit ubits. Innovation often comes in waves, so it is to the industry's benefit to re
to remain vigilant and prepare as early as possible. Bear in mind also that whil main vigilant and prepare as early as possible. Also, bear in mind that while th
e the industry tracks advances from public research institutions such as univers e industry tracks advances from public research institutions such as universitie
ities and companies that publish their results, there is also a great deal of la s and companies that publish their results, there is also a great deal of large-
rge-budget quantum research being conducted privately by various national intere budget quantum research being conducted privately by various national interests.
sts. Therefore, the true state of quantum computer advancement is likely several Therefore, the true state of quantum computer advancement is likely several yea
years ahead of the publicly available research at the date this is published.</ rs ahead of the publicly available research at the date this document is publish
t> ed.</t>
<t>Organizations should also consider carefully and honestly what their mi <t>Organizations should also carefully and honestly consider what their mi
gration timeline "y" actually is. If you think only of the time between receivin gration timeline "y" actually is. If you only think of the time between receivin
g a patch from your technology vendor, and rolling that patch out, then "y" migh g a patch from your technology vendor and rolling that patch out, then "y" might
t seem as short as a few weeks. However, this represents the minority of migrati seem as short as a few weeks. However, this represents the minority of migratio
on cases; more often, a PQC migration will involve at least some amount of hardw n cases; more often, a PQC migration will involve at least some amount of hardwa
are replacement. For example, performance-sensitive applications will need CPUs re replacement. For example, performance-sensitive applications will need CPUs w
with PQC hardware acceleration. Security-sensitive applications will need PQC TP ith PQC hardware acceleration. Security-sensitive applications will need PQC TPM
Ms, TEEs, Secure Enclaves, and other cryptographic co-processors. Smartcard appl s, Trusted Execution Environments (TEEs), secure enclaves, and other cryptograph
ications will require replacement of the cards as well as of the readers which c ic co-processors. Smart card applications will require replacement of the cards
an come in many form-factors: tap-for-entry door and turnstile readers, PIN pad and readers. The readers can come in many form factors: tap-for-entry door and t
machines, laptops with built-in smartcard readers, and many others.</t> urnstile readers, PIN pad machines, laptops with built-in smart card readers, an
<t>Included in "y" is not only the deployment time, but also preparation t d many others.</t>
ime: integration, testing, auditing, and re-certification of cryptographic envir <t>Included in "y" is not only the deployment time but also the preparatio
onments. Consider also upstream effects that contribute to "y", including lead-t n time: integration, testing, auditing, and recertification of cryptographic env
imes for your vendors to produce PQC-ready products, which may itself include au ironments. Also consider upstream effects that contribute to "y", including lead
diting and certification delays, time for regulating bodies to adopt PQC policie times for vendors to produce PQC-ready products, which may itself include audit
s, time for auditors to become familiar with the new requirements, etc. If you m ing and certification delays, time for regulating bodies to adopt PQC policies,
easure the full migration time "y" from when your vendors begin implementing PQC time for auditors to become familiar with the new requirements, etc. If you meas
functionality, to when you switch off your last non-PQC-capable device, then "y ure the full migration time "y" from when your vendors begin implementing PQC fu
" can be quite long; likely measured in years for even most moderately-sized org nctionality to when you switch off your last non-PQC-capable device, then "y" ca
anizations, this long tail should not discourage early action.</t> n be quite long, likely measured in years for even most moderately sized organiz
<t>Organizations responsible for protecting long-lived sensitive data or o ations. This long tail should not discourage early action.</t>
perating critical infrastructure will need to begin transitioning immediately, p <t>Organizations responsible for protecting long-lived sensitive data or o
articularly in scenarios where data is vulnerable to HNDL attacks. PQ/T <xref ta perating critical infrastructure will need to begin transitioning immediately, p
rget="PQT"/> or PQ key exchange is relatively self-contained, typically requirin articularly in scenarios where data is vulnerable to HNDL attacks. Post-quantum
g changes only to the cryptographic library (e.g., OpenSSL). In contrast, migrat and traditional (PQ/T) <xref target="PQT"/> or PQ key exchange is relatively sel
ing to post-quantum or PQ/T digital signatures involves broader ecosystem change f-contained, typically requiring changes only to the cryptographic library (e.g.
s, including updates to certificates, CAs, Certificate Management Protocols, HSM , OpenSSL). In contrast, migrating to post-quantum or PQ/T digital signatures in
s, and trust anchors. volves broader ecosystem changes, including updates to certificates, 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 s ignature integration helps identify ecosystem-wide impacts early. This phased ap proach reduces long-term migration risks and ensures readiness for more complex updates.</t> Starting early with hybrid key exchange deployments allows organizations to gain operational experience, while prototyping and planning for PQ/T or PQ digital s ignature integration helps identify ecosystem-wide impacts early. This phased ap proach reduces long-term migration risks and ensures readiness for more complex updates.</t>
</section> </section>
<section anchor="pqc-categories"> <section anchor="pqc-categories">
<name>PQC Categories</name> <name>PQC Categories</name>
<t>The post-quantum cryptographic schemes standardized by NIST can be cate gorized into three main groups: lattice-based, hash-based, and code-based. Other approaches, such as isogeny-based, multivariate-based, and MPC-in-the-Head-base d cryptography, are also being explored in research and standardization efforts. In addition, NIST issued a call for additional digital signature proposals to e xpand the set of post-quantum signatures under evaluation <xref target="AddSig"/ >.</t> <t>The post-quantum cryptographic schemes standardized by NIST can be cate gorized into three main groups: lattice-based, hash-based, and code-based. Other approaches, such as isogeny-based, multivariate-based, and MPC-in-the-Head-base d cryptography, are also being explored in research and standardization efforts. In addition, NIST issued a call for additional digital signature proposals to e xpand the set of post-quantum signatures under evaluation <xref target="AddSig"/ >.</t>
<section anchor="lattice-based"> <section anchor="lattice-based">
<name>Lattice-Based Public Key Cryptography</name> <name>Lattice-Based Public Key Cryptography</name>
<t>Lattice-based public key cryptography leverages the simple constructi on of lattices (i.e., a regular collection of points in a Euclidean space that a re evenly spaced) to create "trapdoor" problems. These problems are efficient to compute if you possess the secret information but challenging to compute otherw ise. Examples of such problems include the shortest vector, closest vector, shor t integer solution, learning with errors, module learning with errors, and learn ing with rounding problems. All of these problems feature strong proofs for wors t-to-average case reduction, effectively relating the hardness of the average ca se to the worst case.</t> <t>Lattice-based public key cryptography leverages the simple constructi on of lattices (i.e., a regular collection of points in a Euclidean space that a re evenly spaced) to create "trapdoor" problems. These problems are efficient to compute if you possess the secret information but challenging to compute otherw ise. Examples of such problems include the shortest vector, closest vector, shor t integer solution, learning with errors, module learning with errors, and learn ing with rounding problems. All of these problems feature strong proofs for wors t-to-average case reduction, effectively relating the hardness of the average ca se to the worst case.</t>
<t>Lattice-based public keys and signatures are larger than those of cla <t>Lattice-based public keys and signatures are larger than those of cla
ssical schemes such as RSA or ECC, but typically by less than an order of magnit ssical schemes such as RSA or ECC, but typically by less than an order of magnit
ude for public keys (about 6–10×) and by roughly one to two orders of magnitude ude for public keys (about 6-10x) and by roughly one to two orders of magnitude
for signatures (about 10–100×), rather than by several orders of magnitude, maki for signatures (about 10-100x) rather than by several orders of magnitude, makin
ng them the best available candidates for general-purpose use such as replacing g them the best available candidates for general-purpose use, such as replacing
the use of RSA in PKIX certificates.</t> the use of RSA in PKIX certificates.</t>
<t>Examples of this class of algorithms include ML-KEM, FN-DSA, ML-DSA a <t>Examples of this class of algorithms include ML-KEM, FN-DSA, ML-DSA,
nd FrodoKEM.</t> and FrodoKEM.</t>
<t>It is noteworthy that lattice-based encryption schemes require a roun <t>It is noteworthy that lattice-based encryption schemes require a roun
ding step during decryption which has a non-zero probability of "rounding the wr ding step during decryption, which has a non-zero probability of "rounding the w
ong way" and leading to a decryption failure, meaning that valid encryptions are rong way" and leading to a decryption failure, meaning that valid encryptions ar
decrypted incorrectly. However, the parameters of NIST PQC candidates are caref e decrypted incorrectly. However, the parameters of NIST PQC candidates are care
ully chosen so that the probability of such a failure is cryptographically negli fully chosen so that the probability of such a failure is cryptographically negl
gible, far lower than the probability of random transmission errors and implemen igible, far lower than the probability of random transmission errors and impleme
tation bugs. In practical terms, these rare decryption failures can be treated t ntation bugs. In practical terms, these rare decryption failures can be treated
he same way as any fatal transport error: both sides simply perform a fresh KEM the same way as any fatal transport error: Both sides simply perform a fresh KEM
operation, generating a new ciphertext and shared secret.</t> operation, generating a new ciphertext and shared secret.</t>
<t>In cryptanalysis, an oracle refers to a system that an attacker can q <t>In cryptanalysis, an oracle refers to a system that an attacker can q
uery to learn whether decryption succeeded or failed. If such an oracle exists, uery to learn whether decryption succeeded or failed. If such an oracle exists,
an attacker could significantly reduce the security of lattice-based schemes tha an attacker could significantly reduce the security of lattice-based schemes tha
t have a relatively high failure rate. However, for most of the NIST PQC proposa t have a relatively high failure rate. However, for most of the NIST PQC proposa
ls, the number of required oracle queries to force a decryption failure is above ls, the number of required oracle queries to force a decryption failure is above
practical limits, as has been shown in <xref target="LattFail1"/>. More recent practical limits, as shown in <xref target="LattFail1"/>. More recent works hav
works have improved upon the results in <xref target="LattFail1"/>, showing that e improved upon the results in <xref target="LattFail1"/>, showing that the cost
the cost of searching for additional failing ciphertexts after one or more have of searching for additional failing ciphertexts after one or more have already
already been found, can be sped up dramatically <xref target="LattFail2"/>. Nev been found can be sped up dramatically <xref target="LattFail2"/>. Nevertheless,
ertheless, at the time this document is published, the PQC candidates by NIST ar at the time this document is published, the PQC candidates by NIST are consider
e considered secure under these attacks and constant monitoring as cryptanalysis ed secure under these attacks, and constant monitoring as cryptanalysis research
research is ongoing.</t> is ongoing.</t>
</section> </section>
<section anchor="hash-based"> <section anchor="hash-based">
<name>Hash-Based Public Key Cryptography</name> <name>Hash-Based Public Key Cryptography</name>
<t>Hash based PKC has been around since the 1970s, when it was developed <t>Hash-based Public Key Cryptography (PKC) has been around since the 19
by Lamport and Merkle. It is used to create digital signature algorithms and it 70s, when it was developed by Lamport and Merkle. It is used to create digital s
s security is based on the security of the underlying cryptographic hash functio ignature algorithms, and its security is based on the security of the underlying
n. Many variants of hash-based signatures (HBS) have been developed since the 70 cryptographic hash function. Many variants of hash-based signatures (HBSs) have
s including the recent XMSS <xref target="RFC8391"/>, HSS/LMS <xref target="RFC8 been developed since the 1970s, including the recent XMSS <xref target="RFC8391
554"/> or BPQS <xref target="BPQS"/> schemes. Unlike many other digital signatur "/>, HSS/LMS <xref target="RFC8554"/>, or BPQS <xref target="BPQS"/> schemes. Un
e techniques, most hash-based signature schemes are stateful, which means that s like many other digital signature techniques, most hash-based signature schemes
igning necessitates the update and careful tracking of the state of the secret k are stateful, which means that signing necessitates the update and careful track
ey. Producing multiple signatures using the same secret key state results in los ing of the state of the secret key. Producing multiple signatures using the same
s of security and may ultimately enable signature forgery attacks against that k secret key state results in loss of security and may ultimately enable signatur
ey.</t> e forgery attacks against that key.</t>
<t>Stateful hash-based signatures with long service lifetimes require ad <t>Stateful hash-based signatures with long service lifetimes require ad
ditional operational complexity compared with other signature types. For example ditional operational complexity compared to other signature types. For example,
, consider a 20-year root key; there is an expectation that 20 years is longer t consider a 20-year root key; there is an expectation that 20 years is longer tha
han the expected lifetime of the hardware that key is stored on, and therefore t n the expected lifetime of the hardware that key is stored on, so the key will n
he key will need to be migrated to new hardware at some point. Disaster-recovery eed to be migrated to new hardware at some point. Disaster-recovery scenarios wh
scenarios where the primary node fails without warning can be similarly tricky. ere the primary node fails without warning can be similarly tricky. This require
This requires careful operational and compliance consideration to ensure that n s careful operational and compliance consideration to ensure that no private key
o private key state can be reused across the migration or disaster recovery even state can be reused across the migration or disaster recovery event. One approa
t. One approach for avoiding these issues is to only use stateful HBS for short- ch for avoiding these issues is to only use stateful HBSs for short-term use cas
term use cases that do not require horizontal scaling, for example signing a bat es that do not require horizontal scaling, for example, signing a batch of firmw
ch of firmware images and then retiring the signing key.</t> are images and then retiring the signing key.</t>
<t>The SLH-DSA algorithm, which was standardized by NIST, leverages the <t>The SLH-DSA algorithm, which was standardized by NIST, leverages the
HORST (hash to obtain random subset with trees) technique and remains the only s HORST (Hash to Obtain Random Subset with Trees) technique and remains the only s
tandardized hash based signature scheme that is stateless, thus avoiding the com tandardized hash based signature scheme that is stateless, thus avoiding the com
plexities associated with state management. SLH-DSA is an advancement on SPHINCS plexities associated with state management. SLH-DSA is an advancement on SPHINCS
which reduces the signature sizes in SPHINCS and makes it more compact.</t> that reduces the signature sizes in SPHINCS and makes it more compact.</t>
</section> </section>
<section anchor="code-based"> <section anchor="code-based">
<name>Code-Based Public Key Cryptography</name> <name>Code-Based Public Key Cryptography</name>
<t>This area of cryptography started in the 1970s and 80s based on the s <t>This area of cryptography started in the 1970s and 1980s and was base
eminal work of McEliece and Niederreiter which focuses on the study of cryptosys d on the seminal work of McEliece and Niederreiter, which focuses on the study o
tems based on error-correcting codes. Some popular error correcting codes includ f cryptosystems based on error-correcting codes. Some popular error-correcting c
e Goppa codes (used in McEliece cryptosystems), encoding and decoding syndrome c odes include Goppa codes (used in McEliece cryptosystems), encoding and decoding
odes used in Hamming quasi-cyclic (HQC), or quasi-cyclic moderate density parity syndrome codes used in HQC, or quasi-cyclic moderate density parity check (QC-M
check (QC-MDPC) codes.</t> DPC) codes.</t>
<t>Examples include all the unbroken NIST Round 4 finalists: Classic McE <t>Examples include all the unbroken NIST Round 4 finalists: Classic McE
liece, HQC (selected by NIST for standardization), and <xref target="BIKE"/>.</t liece, HQC (selected by NIST for standardization), and BIKE <xref target="BIKE"/
> >.</t>
</section> <!-- [rfced] Please review the following sentence. The expansion of "KEM
encapsulation" would be "key encapsulation mechanism encapsulation" if it were
left as is. Is this correct? Or may we update as follows to avoid repetition?
Current:
The KEM encapsulation 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:
Perhaps:
The 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:
-->
</section>
</section> </section>
<section anchor="KEMs"> <section anchor="KEMs">
<name>KEMs</name> <name>KEMs</name>
<t>A Key Encapsulation Mechanism (KEM) is a cryptographic technique used f or securely exchanging symmetric key material between two parties over an insecu re channel. It is commonly used in hybrid encryption schemes, where a combinatio n of asymmetric (public key) and symmetric encryption is employed. The KEM encap sulation results in a fixed-length symmetric key that can be used with a symmetr ic algorithm, typically a block cipher, in one of two different ways:</t> <t>A Key Encapsulation Mechanism (KEM) is a cryptographic technique used f or securely exchanging symmetric key material between two parties over an insecu re channel. It is commonly used in hybrid encryption schemes where a combination of asymmetric (public key) and symmetric encryption is employed. The KEM encaps ulation results in a fixed-length symmetric key that can be used with a symmetri c algorithm, typically a block cipher, in one of two different ways:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Derive a data encryption key (DEK) to encrypt the data</t> <t>To derive a data encryption key (DEK) to encrypt the data</t>
</li> </li>
<li> <li>
<t>Derive a key encryption key (KEK) used to wrap a DEK</t> <t>To derive a key encryption key (KEK) used to wrap a DEK</t>
</li> </li>
</ul> </ul>
<t>These techniques are often referred to as "hybrid public key encryption <t>These techniques are often referred to as the Hybrid Public Key Encrypt
(HPKE)" <xref target="RFC9180"/> mechanism.</t> ion (HPKE) <xref target="RFC9180"/> mechanism.</t>
<t>The term "encapsulation" is chosen intentionally to indicate that KEM a <t>The term "encapsulation" is chosen intentionally to indicate that KEM a
lgorithms behave differently at the API level from the key agreement or key enci lgorithms behave differently at the API level from the key agreement or key enci
pherment / key transport mechanisms that are in use today. Key agreement schemes pherment and key transport mechanisms that are in use today. Key agreement schem
imply that both parties contribute a public / private key pair to the exchange, es imply that both parties contribute a public-private key pair to the exchange,
while key encipherment / key transport schemes imply that the symmetric key mat while key encipherment and key transport schemes imply that the symmetric key m
erial is chosen by one party and "encrypted" or "wrapped" for the other party. K aterial is chosen by one party and "encrypted" or "wrapped" for the other party.
EMs, on the other hand, behave according to the following API primitives <xref t KEMs, on the other hand, behave according to the following API primitives <xref
arget="PQCAPI"/>:</t> target="PQCAPI"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>def kemKeyGen() -&gt; (pk, sk)</t> <t>def kemKeyGen() -&gt; (pk, sk)</t>
</li> </li>
<li> <li>
<t>def kemEncaps(pk) -&gt; (ss, ct)</t> <t>def kemEncaps(pk) -&gt; (ss, ct)</t>
</li> </li>
<li> <li>
<t>def kemDecaps(ct, sk) -&gt; ss</t> <t>def kemDecaps(ct, sk) -&gt; ss</t>
</li> </li>
</ul> </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> <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"> <figure anchor="tab-kem-ke">
<name>KEM based key exchange</name> <name>KEM-Based Key Exchange</name>
<artset> <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"> <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 8,272 L 8,304" fill="none" stroke="black"/>
<path d="M 24,80 L 24,112" 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 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,80 L 208,112" fill="none" stroke="black"/>
<path d="M 208,272 L 208,304" 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 224,72 L 224,320" fill="none" stroke="black"/>
<path d="M 264,32 L 264,64" 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 280,32 L 280,64" fill="none" stroke="black"/>
skipping to change at line 388 skipping to change at line 650
|<----------| |<----------|
+------------------------+ | | +------------------------+ | |
| ss = kemDecaps(ct, sk) |-| | | ss = kemDecaps(ct, sk) |-| |
+------------------------+ | | +------------------------+ | |
| | | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<section anchor="authenticated-key-exchange"> <section anchor="authenticated-key-exchange">
<name>Authenticated Key Exchange</name> <name>Authenticated Key Exchange</name>
<t>Authenticated Key Exchange (AKE) with KEMs where both parties contrib <!-- [rfced] May we update the title of Figure 4 as follows?
ute a KEM public key to the overall session key is interactive as described in S
ection 9.4 of <xref target="RFC9528"/>. However, single-sided KEM, such as when Original:
one peer has a KEM key in a certificate and the other peer wants to encrypt for Figure 4: Diffie-Hellman based AKE and NIKE simultaneously
it (as in S/MIME or OpenPGP email), can be achieved using non-interactive HPKE <
xref target="RFC9180"/>. The following figure illustrates the Diffie-Hellman (DH Perhaps:
) Key exchange:</t> Figure 4: Simultaneous DH-Based AKE and NIKE
-->
<t>Authenticated Key Exchange (AKE) with KEMs where both parties contribute a KE
M public key to the overall session key is interactive as described in <xref sec
tion="9.4" sectionFormat="of" target="RFC9528"/>. However, a single-sided KEM, s
uch 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-intera
ctive HPKE <xref target="RFC9180"/>. The following figure illustrates the DH Key
exchange:</t>
<figure anchor="tab-dh-ake"> <figure anchor="tab-dh-ake">
<name>Diffie-Hellman based AKE</name> <name>DH-Based AKE</name>
<artset> <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"> <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 8,320 L 8,368" fill="none" stroke="black"/>
<path d="M 24,80 L 24,128" 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 136,336 L 136,344" fill="none" stroke="black"/>
<path d="M 184,32 L 184,64" 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,80 L 216,128" fill="none" stroke="black"/>
<path d="M 216,320 L 216,368" 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 232,72 L 232,464" fill="none" stroke="black"/>
<path d="M 264,32 L 264,64" fill="none" stroke="black"/> <path d="M 264,32 L 264,64" fill="none" stroke="black"/>
skipping to change at line 491 skipping to change at line 762
+-------------------------+ | | +-------------------------+ | |
| encrypted | | encrypted |
| content | | content |
|---------->| |---------->|
| | +------------------------+ | | +------------------------+
| | | decryptContent(ss) | | | | decryptContent(ss) |
| | +------------------------+ | | +------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>What's important to note about the sample flow above is that the shar <!-- [rfced] Figure 4 is not referred to in the text. May we update this
ed secret <tt>ss</tt> is derived using key material from both the Client and the sentence as shown below?
Server, which classifies it as an AKE. There is another property of a key excha
nge, called Non-Interactive Key Exchange (NIKE) which refers to whether the send Original:
er can compute the shared secret <tt>ss</tt> and encrypt content without requiri However, a DH key exchange can be an AKE and a NIKE at
ng active interaction (an exchange of network messages) with the recipient. <xre the same time if the receiver's public key is known to the sender in
f target="tab-dh-ake"/> shows a Diffie-Hellman key exchange which is an AKE, sin advance, and many Internet protocols rely on this property of DH-
ce both parties are using long-term keys which can have established trust (for e based key exchanges.
xample, via certificates), but it is not a NIKE, since the client needs to wait
for the network interaction to receive the receiver's public key <tt>pk2</tt> be Perhaps:
fore 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
However, a DH key exchange can be an AKE and a NIKE at the same time if the rece the same time if the receiver's public key is known to the sender in
iver's public key is known to the sender in advance, and many Internet protocols advance (see Figure 4), and many Internet protocols rely on this property of
rely on this property of DH-based key exchanges.</t> DH-
based key exchanges.
-->
<t>In the sample flow above, it is important to note that the shared secret <tt>
ss</tt> is derived using key material from both the client and the server, which
classifies it as an AKE. There is another property of a key exchange, called No
n-Interactive Key Exchange (NIKE), that refers to whether the sender can comput
e the shared secret <tt>ss</tt> and encrypt content without requiring active int
eraction (an exchange of network messages) with the recipient. <xref target="tab
-dh-ake"/> shows a DH key exchange, which is an AKE since both parties are using
long-term keys that can have established trust (for example, via certificates),
but it is not a 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 sha
red 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 in advance, and many Internet protocols rely on this property of D
H-based key exchanges.</t>
<figure anchor="tab-dh-ake-nike"> <figure anchor="tab-dh-ake-nike">
<name>Diffie-Hellman based AKE and NIKE simultaneously</name> <name>DH-Based AKE and NIKE Simultaneously</name>
<artset> <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"> <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 8,80 L 8,192" fill="none" stroke="black"/>
<path d="M 136,160 L 136,168" 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 168,32 L 168,64" fill="none" stroke="black"/>
<path d="M 200,80 L 200,192" 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 216,72 L 216,368" fill="none" stroke="black"/>
<path d="M 248,32 L 248,64" 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 264,32 L 264,64" fill="none" stroke="black"/>
<path d="M 312,72 L 312,368" fill="none" stroke="black"/> <path d="M 312,72 L 312,368" fill="none" stroke="black"/>
skipping to change at line 580 skipping to change at line 866
|---------->| |---------->|
| | +------------------------+ | | +------------------------+
| |-| Long-term server key: | | |-| Long-term server key: |
| | | sk2, pk2 | | | | sk2, pk2 |
| | | ss = KeyEx(pk1, sk2) | | | | ss = KeyEx(pk1, sk2) |
| | | decryptContent(ss) | | | | decryptContent(ss) |
| | +------------------------+ | | +------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The complication with KEMs is that a KEM <tt>Encaps()</tt> is non-det <t>The complication with KEMs is that a KEM <tt>Encaps()</tt> is non-det
erministic; it involves randomness chosen by the sender of that message. Therefo erministic; it involves randomness chosen by the sender of that message. Therefo
re, in order to perform an AKE, the client must wait for the server to generate re, 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, whic the needed randomness and perform <tt>Encaps()</tt> against the client key, whic
h necessarily requires a network round-trip. Therefore, a KEM-based protocol can h necessarily requires a network round-trip. Therefore, a KEM-based protocol can
either be an AKE or a NIKE, but cannot be both at the same time. Consequently, either be an AKE or a NIKE, but it cannot be both at the same time. Consequentl
certain Internet protocols will necessitate a redesign to accommodate this disti y, certain Internet protocols will necessitate a redesign to accommodate this di
nction, either by introducing extra network round-trips or by making trade-offs stinction, either by introducing extra network round trips or by making trade-of
in security properties.</t> fs in security properties.</t>
<figure anchor="tab-kem-ake"> <!-- [rfced] In Figure 5, please review the second box on the left side
<name>KEM based AKE</name> of the
diagram. There seems to be an extra "-|", and the box is not closed. Would you
like to make any updates here? Please check out the suggested update in these
test files and let us know your thoughts:
https://www.rfc-editor.org/authors/rfc9958-TEST.md
https://www.rfc-editor.org/authors/rfc9958-TEST.txt
https://www.rfc-editor.org/authors/rfc9958-TEST.html
-->
<figure anchor="tab-kem-ake">
<name>KEM-Based AKE</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="480" width="560" viewBox="0 0 560 480" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="480" width="560" viewBox="0 0 560 480" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,80 L 8,112" fill="none" stroke="black"/> <path d="M 8,80 L 8,112" fill="none" stroke="black"/>
<path d="M 8,288 L 8,352" fill="none" stroke="black"/> <path d="M 8,288 L 8,352" fill="none" stroke="black"/>
<path d="M 184,32 L 184,64" 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,80 L 208,112" fill="none" stroke="black"/>
<path d="M 208,336 L 208,352" fill="none" stroke="black"/> <path d="M 208,336 L 208,352" fill="none" stroke="black"/>
<path d="M 224,72 L 224,464" fill="none" stroke="black"/> <path d="M 224,72 L 224,464" fill="none" stroke="black"/>
<path d="M 264,32 L 264,64" 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 280,32 L 280,64" fill="none" stroke="black"/>
skipping to change at line 694 skipping to change at line 990
| | | |
|ct2 | |ct2 |
|---------->| |---------->|
| | +--------------------------+ | | +--------------------------+
| |-| ss2 = kemDecaps(ct2, sk2)| | |-| ss2 = kemDecaps(ct2, sk2)|
| | | ss = Combiner(ss1, ss2) | | | | ss = Combiner(ss1, ss2) |
| | +--------------------------+ | | +--------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Here, <tt>Combiner(ss1, ss2)</tt>, often referred to as a KEM Combine r, 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 < xref target="INDCCA2"/> of either input even if the other is chosen maliciously, then a more complex construct is required. Another consideration for combiner d esign is 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 o ne is ML-KEM and the other is ECDH. For a more thorough discussion of KEM combin ers, see <xref target="KEEPINGUP"/>, <xref target="I-D.draft-ounsworth-cfrg-kem- combiners"/>, and <xref target="I-D.irtf-cfrg-hybrid-kems"/>.</t> <t>In the figure above, <tt>Combiner(ss1, ss2)</tt>, often referred to a s a KEM combiner, is a cryptographic construction that takes in two shared secre ts and returns a single combined shared secret. The simplest combiner is concate nation <tt>ss1 || ss2</tt>, but combiners can vary in complexity depending on th e cryptographic properties required. For example, if the combination should pres erve IND-CCA2 (see <xref target="INDCCA2"/>) of either input, even if the other is chosen maliciously, then a more complex construct is required. Another consid eration for combiner design is the so-called "binding properties" introduced in <xref target="KEEPINGUP"/>, which may require the ciphertexts and recipient publ ic keys to be included in the combiner. KEM combiner security analysis becomes m ore complicated in hybrid settings where the two KEMs represent different algori thms, for example, where one is ML-KEM and the other is ECDH. For a more thoroug h discussion of KEM combiners, see <xref target="KEEPINGUP"/>, <xref target="I-D .ounsworth-cfrg-kem-combiners"/>, and <xref target="I-D.irtf-cfrg-hybrid-kems"/> .</t>
</section> </section>
<section anchor="security-properties-of-kems"> <section anchor="security-properties-of-kems">
<name>Security Properties of KEMs</name> <name>Security Properties of KEMs</name>
<t>The security properties described in this section (IND-CCA2 and bindi ng) are not an exhaustive list of all possible KEM security considerations. They were selected because they are fundamental to evaluating KEM suitability in pro tocol design and are commonly discussed in current PQC work.</t> <t>The security properties described in this section (IND-CCA2 and bindi ng) are not an exhaustive list of all possible KEM security considerations. They were selected because they are fundamental to evaluating KEM suitability in pro tocol design and are commonly discussed in current PQC work.</t>
<section anchor="INDCCA2"> <section anchor="INDCCA2">
<name>IND-CCA2</name> <name>IND-CCA2</name>
<t>IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Att ack) is an advanced security notion for encryption schemes. It ensures the confi dentiality of the plaintext and resistance against chosen-ciphertext attacks. An appropriate definition of IND-CCA2 security for KEMs can be found in <xref targ et="CS01"/> and <xref target="BHK09"/>. ML-KEM <xref target="ML-KEM"/> and Class ic McEliece provide IND-CCA2 security.</t> <t>IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Att ack) is an advanced security notion for encryption schemes. It ensures the confi dentiality of the plaintext and resistance against chosen-ciphertext attacks. An appropriate definition of IND-CCA2 security for KEMs can be found in <xref targ et="CS01"/> and <xref target="BHK09"/>. ML-KEM <xref target="ML-KEM"/> and Class ic McEliece provide IND-CCA2 security.</t>
<t>Understanding IND-CCA2 security is essential for individuals involv ed 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. U nderstanding IND-CCA2 security is generally not necessary for developers migrati ng to using an IETF-vetted key establishment method (KEM) within a given protoco l or flow. IND-CCA2 is a widely accepted security notion for public key encrypti on mechanisms, making it suitable for a broad range of applications. When an IET F specification defines a new KEM, its security considerations should fully desc ribe the relevant cryptographic properties, including IND-CCA2.</t> <t>Understanding IND-CCA2 security is essential for individuals involv ed 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. U nderstanding IND-CCA2 security is generally not necessary for developers migrati ng to using an IETF-vetted key establishment method (KEM) within a given protoco l or flow. IND-CCA2 is a widely accepted security notion for public key encrypti on mechanisms, making it suitable for a broad range of applications. When an IET F specification defines a new KEM, its security considerations should fully desc ribe the relevant cryptographic properties, including IND-CCA2.</t>
</section> </section>
<section anchor="binding"> <section anchor="binding">
<name>Binding</name> <name>Binding</name>
<t>KEMs also have an orthogonal set of properties to consider when des <t>KEMs also have an orthogonal set of properties to consider when des
igning protocols around them: binding <xref target="KEEPINGUP"/>. This can be "c igning protocols around them: binding <xref target="KEEPINGUP"/>. This can be "c
iphertext binding", "public key binding", "context binding", or any other proper iphertext binding", "public key binding", "context binding", or any other proper
ty that is important to not be substituted between KEM invocations. In general, ty 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 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 attacker will necessarily result in a different shared secret being derived. As
an example, if an attacker can construct two different ciphertexts which will de an example, if an attacker can construct two different ciphertexts that will dec
capsulate to the same shared secret; or can construct a ciphertext which will de apsulate to the same shared secret, can construct a ciphertext that will decapsu
capsulate to the same shared secret under two different public keys, or can subs late to the same shared secret under two different public keys, or can substitut
titute whole KEM exchanges from one session into another, then the construction e whole KEM exchanges from one session into another, then the construction is no
is not ciphertext binding, public key binding, or context binding respectively. t ciphertext binding, public key binding, or context binding, respectively. Simi
Similarly, protocol designers may wish to bind protocol state information such a larly, protocol designers may wish to bind protocol state information such as a
s a transaction ID or nonce so that attempts to replay ciphertexts from one sess transaction ID or nonce so that attempts to replay ciphertexts from one session
ion inside a different session will be blocked at the cryptographic level becaus inside a different session will be blocked at the cryptographic level because th
e the server derives a different shared secret and is thus is unable to decrypt e server derives a different shared secret and is thus is unable to decrypt the
the content.</t> content.</t>
<t>The solution to binding is generally achieved at the protocol desig <!-- [rfced] Will readers understand what "it" in the phrase "pass it
n level: It is recommended to avoid using the KEM output shared secret directly through"
without integrating it into an appropriate protocol. While KEM algorithms provid refers to here? Does "it" refer to "KEMs", "secrets", or something else?
e key secrecy, they do not inherently ensure source authenticity, protect agains
t replay attacks, or guarantee freshness. These security properties should be ad Original:
dressed by incorporating the KEM into a protocol that has been analyzed for such Even though modern KEMs such as ML-KEM produce full-
protections. Even though modern KEMs such as ML-KEM produce full-entropy shared entropy shared secrets, it is still advisable for binding reasons to
secrets, it is still advisable for binding reasons to pass it through a key der pass it through a key derivation function (KDF) and also include all
ivation function (KDF) and also include all values that you wish to bind; then f values that you wish to bind; then finally you will have a shared
inally you will have a shared secret that is safe to use at the protocol level.< secret that is safe to use at the protocol level.
/t> -->
<t>The solution to binding is generally achieved at the protocol design level: I
t is recommended to avoid using the KEM output shared secret directly without in
tegrating it into an appropriate protocol. While KEM algorithms provide key secr
ecy, they do not inherently ensure source authenticity, protect against replay a
ttacks, or guarantee freshness. These security properties should be addressed by
incorporating the KEM into a protocol that has been analyzed for such protectio
ns. Even though modern KEMs such as ML-KEM produce full-entropy shared secrets,
it is still advisable for binding reasons to pass it through a key derivation fu
nction (KDF) and also include all values that you wish to bind; then, you will h
ave a shared secret that is safe to use at the protocol level.</t>
</section> </section>
</section> </section>
<section anchor="hpke"> <section anchor="hpke">
<name>HPKE</name> <name>HPKE</name>
<t>Modern cryptography has long used the notion of "hybrid encryption" w <t>Modern cryptography has long used the notion of "hybrid encryption" w
here an asymmetric algorithm is used to establish a key, and then a symmetric al here an asymmetric algorithm is used to establish a key and then a symmetric alg
gorithm is used for bulk content encryption. The previous sections explained imp orithm is used for bulk content encryption. The previous sections explained impo
ortant security properties of KEMs, such as IND-CCA2 security and binding, and e rtant security properties of KEMs, such as IND-CCA2 security and binding, and em
mphasized that these properties must be supported by proper protocol design. One phasized that these properties must be supported by proper protocol design. One
widely deployed scheme that achieves this is HPKE (Hybrid Public Key Encryption widely deployed scheme that achieves this is Hybrid Public Key Encryption (HPKE)
) <xref target="RFC9180"/>.</t> <xref target="RFC9180"/>.</t>
<t>HPKE (hybrid public key encryption) <xref target="RFC9180"/> works wi <t>HPKE <xref target="RFC9180"/> works with a combination of KEMs, KDFs,
th a combination of KEMs, KDFs and AEAD (authenticated encryption with additiona and Authenticated Encryption with Associated Data (AEAD) schemes. HPKE includes
l data) schemes. HPKE includes three authenticated variants, including one that three authenticated variants, including one that authenticates possession of a
authenticates possession of a pre-shared key and two optional ones that authenti pre-shared key and two optional ones that authenticate possession of a KEM priva
cate possession of a key encapsulation mechanism (KEM) private key. HPKE can be te key. HPKE can be extended to support hybrid post-quantum KEM <xref target="I-
extended to support hybrid post-quantum KEM <xref target="I-D.ietf-hpke-pq"/>. M D.ietf-hpke-pq"/>. ML-KEM does not support the static-ephemeral key exchange tha
L-KEM does not support the static-ephemeral key exchange that allows HPKE based t allows HPKE that is based on DH-based KEMs and its optional authenticated mode
on DH based KEMs and its optional authenticated modes as discussed in section 1. s as discussed in <xref section="1.5" sectionFormat="of" target="I-D.connolly-cf
5 of <xref target="I-D.draft-connolly-cfrg-xwing-kem"/>.</t> rg-xwing-kem"/>.</t>
</section> </section>
</section> </section>
<section anchor="pqc-signatures-1"> <section anchor="pqc-signatures-1">
<name>PQC Signatures</name> <name>PQC Signatures</name>
<t>Any digital signature scheme that provides a construction defining secu rity under a post-quantum setting falls under this category of PQC signatures.</ t> <t>Any digital signature scheme that provides a construction defining secu rity under a post-quantum setting falls under this category of PQC signatures.</ t>
<section anchor="security-properties-of-pqc-signatures"> <section anchor="security-properties-of-pqc-signatures">
<name>Security Properties of PQC Signatures</name> <name>Security Properties of PQC Signatures</name>
<section anchor="euf-cma-and-suf-cma"> <section anchor="euf-cma-and-suf-cma">
<name>EUF-CMA and SUF-CMA</name> <name>EUF-CMA and SUF-CMA</name>
<t>EUF-CMA (existential unforgeability under chosen message attack) <x ref target="GMR88"/> is a security notion for digital signature schemes. It guar antees that an adversary, even with access to a signing oracle, cannot forge a v alid signature for an arbitrary message. EUF-CMA provides strong protection agai nst forgery attacks, ensuring the integrity and authenticity of digital signatur es by preventing unauthorized modifications or fraudulent signatures. ML-DSA, FN -DSA, and SLH-DSA provide EUF-CMA security.</t> <t>EUF-CMA (existential unforgeability under chosen message attack) <x ref target="GMR88"/> is a security notion for digital signature schemes. It guar antees that an adversary, even with access to a signing oracle, cannot forge a v alid signature for an arbitrary message. EUF-CMA provides strong protection agai nst forgery attacks, ensuring the integrity and authenticity of digital signatur es 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 sig nature for a message that has already been signed by the signing oracle. Like EU F-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>SUF-CMA (strong unforgeability under chosen message attack) builds upon EUF-CMA by requiring that an adversary cannot produce a different valid sig nature for a message that has already been signed by the signing oracle. Like EU F-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 designi <t>Understanding EUF-CMA and SUF-CMA security is essential for designi
ng or implementing cryptographic systems in order to ensure the security, reliab ng or implementing cryptographic systems in order to ensure the security, reliab
ility, and robustness of digital signature schemes. These notions allow for info ility, and robustness of digital signature schemes. These notions allow for info
rmed decision-making, vulnerability analysis, compliance with standards, and des rmed decision making, vulnerability analysis, compliance with standards, and des
igning systems that provide strong protection against forgery attacks. For devel igning systems that provide strong protection against forgery attacks. For devel
opers migrating to using an IETF-vetted PQC signature scheme within a given prot opers migrating to an IETF-vetted PQC signature scheme within a given protocol o
ocol or flow, a deep understanding of EUF-CMA and SUF-CMA security may not be ne r flow, a deep understanding of EUF-CMA and SUF-CMA security may not be necessar
cessary, as the schemes vetted by IETF adhere to these stringent security standa y, as the schemes vetted by IETF adhere to these stringent security standards.</
rds.</t> t>
<t>EUF-CMA and SUF-CMA are considered strong security benchmarks for p <t>EUF-CMA and SUF-CMA are considered strong security benchmarks for p
ublic key signature algorithms, making them suitable for most applications. IETF ublic key signature algorithms, making them suitable for most applications. Auth
specification authors should include all security concerns in the "Security Con ors of IETF specifications should include all security concerns in the "Security
siderations" section of the relevant RFC and should not assume that implementers Considerations" section of the relevant RFC and should not assume that implemen
are experts in cryptographic theory.</t> ters are experts in cryptographic theory.</t>
</section> </section>
</section> </section>
<section anchor="sig-scheme"> <section anchor="sig-scheme">
<name>Details of FN-DSA, ML-DSA, and SLH-DSA</name> <name>Details of FN-DSA, ML-DSA, and SLH-DSA</name>
<t>ML-DSA <xref target="ML-DSA"/> is a digital signature algorithm based <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 Lear on the hardness of lattice problems over module lattices (i.e., the Module Lear
ning with Errors problem (MLWE)). The design of the algorithm is based on the "F ning with Errors (MLWE) problem). The design of the algorithm is based on the "F
iat-Shamir with Aborts" <xref target="Lyu09"/> framework introduced by Lyubashev iat-Shamir with Aborts" <xref target="Lyu09"/> framework introduced by Lyubashev
sky, that leverages rejection sampling to render lattice-based Fiat-Shamir (FS) sky that leverages rejection sampling to render lattice-based Fiat-Shamir (FS) s
schemes compact and secure. ML-DSA uses uniformly-distributed random number samp chemes compact and secure. ML-DSA uses uniformly distributed random number sampl
ling over small integers to compute coefficients in error vectors, which makes t ing over small integers to compute coefficients in error vectors, which makes th
he scheme easier to implement compared with FN-DSA <xref target="FN-DSA"/> which e scheme easier to implement compared to FN-DSA <xref target="FN-DSA"/>, which
uses Gaussian-distributed numbers, necessitating the need to use floating point uses Gaussian-distributed numbers, necessitating the need to use floating-point
arithmetic during signature generation.</t> arithmetic during signature generation.</t>
<t>ML-DSA offers both deterministic and randomized signing and is instan <t>ML-DSA offers both deterministic and randomized signing and is instan
tiated with 3 parameter sets providing different security levels. Security prope tiated with three parameter sets providing different security levels. Security p
rties of ML-DSA are discussed in Section 9 of <xref target="I-D.ietf-lamps-dilit roperties of ML-DSA are discussed in <xref section="9" sectionFormat="of" target
hium-certificates"/>.</t> ="RFC9881"/>.</t>
<t>FN-DSA <xref target="FN-DSA"/> is based on the GPV hash-and-sign latt ice-based signature framework introduced by Gentry, Peikert, and Vaikuntanathan, which is a framework that requires a certain class of lattices and a trapdoor s ampler technique.</t> <t>FN-DSA <xref target="FN-DSA"/> is based on the GPV hash-and-sign latt ice-based signature framework introduced by Gentry, Peikert, and Vaikuntanathan, which is a framework that requires a certain class of lattices and a trapdoor s ampler technique.</t>
<t>The main design principle of FN-DSA is compactness, i.e., it was desi <t>The main design principle of FN-DSA is compactness, i.e., it was desi
gned in a way that achieves minimal total memory bandwidth requirement (the sum gned 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 com of the signature size plus the public key size). This is possible due to the com
pactness of NTRU lattices. FN-DSA also offers very efficient signing and verific pactness of NTRU lattices. FN-DSA also offers very efficient signing and verific
ation procedures. The main potential downsides of FN-DSA refer to the non-trivia ation procedures. The main potential downsides of FN-DSA refer to the non-trivia
lity of its algorithms and the need for floating point arithmetic support in ord lity of its algorithms and the need for floating-point arithmetic support in ord
er to support Gaussian-distributed random number sampling where the other lattic er to support Gaussian-distributed random number sampling where the other lattic
e schemes use the less efficient but easier to support uniformly-distributed ran e schemes use the less efficient but easier to support uniformly distributed ran
dom number sampling.</t> dom number sampling.</t>
<t>Implementers of FN-DSA need to be aware that FN-DSA signing is highly <!-- [rfced] Will readers know what "NIST's report" is here? Would a cit
susceptible to side-channel attacks, unless constant-time 64-bit floating-point ation
operations are used. This requirement is extremely platform-dependent, as noted be helpful? If so, please provide the appropriate reference entry.
in NIST's report.</t>
<t>The performance characteristics of ML-DSA and FN-DSA may differ based Original:
on the specific implementation and hardware platform. Generally, ML-DSA is know This requirement is extremely
n for its relatively fast signature generation, while FN-DSA can provide more ef platform-dependent, as noted in NIST's report.
ficient signature verification. The choice may depend on whether the application -->
requires more frequent signature generation or signature verification (See <xre
f target="LIBOQS"/>). For further clarity on the sizes and security levels, plea <t>Implementers of FN-DSA need to be aware that FN-DSA signing is highly suscept
se refer to the tables in <xref target="RecSecurity"/> and <xref target="Compari ible to side-channel attacks unless constant-time 64-bit floating-point operatio
sons"/>.</t> ns are used. This requirement is extremely platform-dependent, as noted in NIST'
s report.</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 know
n for its relatively fast signature generation, while FN-DSA can provide more ef
ficient signature verification. The choice may depend on whether the application
requires more frequent signature generation or signature verification (see <xre
f target="LIBOQS"/>). For further clarity on the sizes and security levels, plea
se refer to the tables in Sections <xref target="RecSecurity" format="counter"/>
and <xref target="Comparisons" format="counter"/>.</t>
<t>SLH-DSA <xref target="SLH-DSA"/> utilizes the concept of stateless ha sh-based signatures, where each signature is unique and unrelated to any previou s signature (as discussed in <xref target="hash-based"/>). This property elimina tes the need for maintaining state information during the signing process. SLH-D SA was designed to sign up to 2^64 messages under a given key pair, and it offer s three security levels. The parameters for each of the security levels were cho sen to provide 128 bits of security, 192 bits of security, and 256 bits of secur ity. SLH-DSA offers smaller public key sizes, larger signature sizes, slower sig nature generation, and slower verification when compared to ML-DSA and FN-DSA. S LH-DSA does not introduce a new hardness assumption beyond those inherent to the underlying hash functions. It builds upon established foundations in cryptograp hy, making it a reliable and robust digital signature scheme for a post-quantum world.</t> <t>SLH-DSA <xref target="SLH-DSA"/> utilizes the concept of stateless ha sh-based signatures, where each signature is unique and unrelated to any previou s signature (as discussed in <xref target="hash-based"/>). This property elimina tes the need for maintaining state information during the signing process. SLH-D SA was designed to sign up to 2^64 messages under a given key pair, and it offer s three security levels. The parameters for each of the security levels were cho sen to provide 128 bits of security, 192 bits of security, and 256 bits of secur ity. SLH-DSA offers smaller public key sizes, larger signature sizes, slower sig nature generation, and slower verification when compared to ML-DSA and FN-DSA. S LH-DSA does not introduce a new hardness assumption beyond those inherent to the underlying hash functions. It builds upon established foundations in cryptograp hy, making it a reliable and robust digital signature scheme for a post-quantum world.</t>
<t>All of these algorithms, ML-DSA, FN-DSA, and SLH-DSA include two sign ature modes: pure mode, where the entire content is signed directly, and pre-has h mode, where a digest of the content is signed.</t> <t>All of these algorithms (ML-DSA, FN-DSA, and SLH-DSA) include two sig nature modes: pure mode, where the entire content is signed directly, and pre-ha sh mode, where a digest of the content is signed.</t>
</section> </section>
<section anchor="details-of-xmss-and-lms"> <section anchor="details-of-xmss-and-lms">
<name>Details of XMSS and LMS</name> <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 k ey state changes over time. In both schemes, reusing a secret key state compromi ses cryptographic security guarantees.</t> <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 k ey state changes over time. In both schemes, reusing a secret key state compromi ses cryptographic security guarantees.</t>
<t>XMSS and LMS can be used for signing a potentially large but fixed nu <t>XMSS and LMS can be used for signing a potentially large but fixed nu
mber of messages and the number of signing operations depends upon the size of t mber of messages, and the number of signing operations depends upon the size of
he tree. XMSS and LMS provide cryptographic digital signatures without relying o the tree. XMSS and LMS provide cryptographic digital signatures without relying
n the conjectured hardness of mathematical problems, instead leveraging the prop on the conjectured hardness of mathematical problems, instead leveraging the pro
erties of cryptographic hash functions. Multi-tree XMSS and LMS (i.e., XMSS-MT a perties of cryptographic hash functions. Multi-tree XMSS and LMS (i.e., XMSS-MT
nd HSS, respectively) use a hyper-tree based hierarchical approach with a Merkle and HSS, respectively) use a hyper-tree-based hierarchical approach with a Merkl
tree at each level of the hierarchy. <xref target="RFC8391"/> describes both si e tree at each level of the hierarchy. <xref target="RFC8391"/> describes both s
ngle-tree and multi-tree variants of XMSS, while <xref target="RFC8554"/> descri ingle-tree and multi-tree variants of XMSS, while <xref target="RFC8554"/> descr
bes the Leighton-Micali One-Time Signature (LM-OTS) system as well as the LMS an ibes the Leighton-Micali One-Time Signature (LM-OTS) system as well as the LMS a
d HSS N-time signature systems. Comparison of XMSS and LMS is discussed in Secti nd HSS N-time signature systems. Comparison of XMSS and LMS is discussed in <xre
on 10 of <xref target="RFC8554"/>.</t> f section="10" sectionFormat="of" target="RFC8554"/>.</t>
<t>The number of tree layers in multi-tree XMSS and HSS provides a trade <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 -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 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 exponentially and signing time linearly at the cost of increasing the signature
size linearly. HSS allows for customization of each subtree whereas XMSS-MT does size linearly. HSS allows for customization of each subtree, whereas XMSS-MT doe
not, electing instead to use the same structure for each subtree.</t> s not, electing instead to use the same structure for each subtree.</t>
<t>Due to the complexities described above, the XMSS and LMS are not a s <t>Due to the complexities described above, XMSS and LMS are not suitabl
uitable replacement for traditional signature schemes like RSA or ECDSA. Applica e replacements for traditional signature schemes like RSA or ECDSA. Applications
tions that expect a long lifetime of a signature, like firmware update or secure that expect a long lifetime of a signature, like firmware update or secure boot
boot, are typical use cases where those schemes can be successfully applied.</t , are typical use cases where those schemes can be successfully applied.</t>
>
<section anchor="lms-key-and-signature-sizes"> <section anchor="lms-key-and-signature-sizes">
<name>LMS Key and Signature Sizes</name> <name>LMS Key and Signature Sizes</name>
<t>The LMS scheme is characterized by four distinct parameter sets: th e 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 s ignatures that the private key can produce, and the width of the Winternitz coef ficients (see <xref target="RFC8554"/>, section 4.1) that can be used to trade-o ff signing time for signature size. Parameters can be mixed, providing 80 possib le parameterizations of the scheme.</t> <t>The LMS scheme is characterized by four distinct parameter sets: th e 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 s ignatures that the private key can produce, and the width of the Winternitz coef ficients (see <xref section="4.1" sectionFormat="comma" target="RFC8554"/>) that can be used to trade-off signing time for signature size. Parameters can be mix ed, 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 paramet er (W), the LMS tree height (H), and the length of the digest. The table below p rovides key and signature sizes for parameterization with the digest size M=32 o f 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 paramet er (W), the LMS tree height (H), and the length of the digest. The table below p rovides key and signature sizes for parameterization with the digest size M=32 o f the scheme.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">PK</th> <th align="left">PK</th>
<th align="left">SK</th> <th align="left">SK</th>
<th align="left">W</th> <th align="left">W</th>
<th align="left">H=5</th> <th align="left">H=5</th>
<th align="left">H=10</th> <th align="left">H=10</th>
<th align="left">H=15</th> <th align="left">H=15</th>
skipping to change at line 810 skipping to change at line 1125
<td align="left">1612</td> <td align="left">1612</td>
<td align="left">1772</td> <td align="left">1772</td>
<td align="left">1932</td> <td align="left">1932</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="hash-then-sign"> <section anchor="hash-then-sign">
<name>Hash-then-Sign</name> <name>Hash-then-Sign</name>
<t>Within the hash-then-sign paradigm, the message is hashed before sign ing 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 has h-then-sign paradigm has the ability to improve application performance by reduc ing the size of signed messages that need to be transmitted between application and cryptographic module, and making the signature size predictable and manageab le. As a corollary, hashing remains mandatory even for short messages and assign s a further computational requirement onto the verifier. This makes the performa nce of hash-then-sign schemes more consistent, but not necessarily more efficien t.</t> <t>Within the hash-then-sign paradigm, the message is hashed before sign ing 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 has h-then-sign paradigm has the ability to improve application performance by reduc ing the size of signed messages that need to be transmitted between application and cryptographic module and making the signature size predictable and manageabl e. As a corollary, hashing remains mandatory even for short messages and assigns a further computational requirement onto the verifier. This makes the performan ce 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 ens ures that the signature is compatible with a wide range of systems and protocols , regardless of the specific message size or format. Crucially for hardware secu rity modules, Hash-then-Sign also significantly reduces the amount of data that needs to be transmitted and processed by a Hardware Security Module (HSM). Consi der scenarios such as a networked HSM located in a different data center from th e calling application or a smart card connected over a USB interface. In these c ases, streaming a message that is megabytes or gigabytes long can result in nota ble network latency, on-device signing delays, or even depletion of available on -device memory.</t> <t>Using a hash function to produce a fixed-size digest of a message ens ures that the signature is compatible with a wide range of systems and protocols , regardless of the specific message size or format. Crucially for hardware secu rity modules, Hash-then-Sign also significantly reduces the amount of data that needs to be transmitted and processed by a Hardware Security Module (HSM). Consi der scenarios such as a networked HSM located in a different data center from th e calling application or a smart card connected over a USB interface. In these c ases, streaming a message that is megabytes or gigabytes long can result in nota ble 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 mes sages already perform some form of content hashing at the protocol level, so thi s tends to be more of a concern with proprietary cryptographic protocols, and pr otocols from non-IETF standards bodies. Protocols like TLS 1.3 and DNSSEC use th e Hash-then-Sign paradigm. In TLS 1.3 <xref target="RFC8446"/> CertificateVerify messages, the content that is covered under the signature includes the transcri pt hash output (Section 4.4.1 of <xref target="RFC8446"/>), while DNSSEC <xref t arget="RFC4034"/> uses it to provide origin authentication and integrity assuran ce services for DNS data. Similarly, the Cryptographic Message Syntax (CMS) <xre f target="RFC5652"/> includes a mandatory message digest step before invoking th e signature algorithm.</t> <t>Note that the vast majority of Internet protocols that sign large mes sages already perform some form of content hashing at the protocol level, so thi s tends to be more of a concern with proprietary cryptographic protocols and pro tocols from non-IETF standards bodies. Protocols like TLS 1.3 and DNSSEC use the Hash-then-Sign paradigm. In TLS 1.3 <xref target="RFC8446"/> CertificateVerify messages, the content that is covered under the signature includes the transcrip t hash output (<xref section="4.4.1" sectionFormat="of" target="RFC8446"/>) whil e DNSSEC <xref target="RFC4034"/> uses it to provide origin authentication and i ntegrity assurance services for DNS data. Similarly, the Cryptographic Message S yntax (CMS) <xref target="RFC5652"/> includes a mandatory message digest step be fore 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 va lue for the signature generation process. In the case of SLH-DSA, it internally performs randomized message compression using a keyed hash function that can pro cess arbitrary length messages. In the case of FN-DSA, the SHAKE-256 hash functi on is used as part of the signature process to derive a digest of the message be ing signed.</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 va lue for the signature generation process. In the case of SLH-DSA, it internally performs randomized message compression using a keyed hash function that can pro cess arbitrary length messages. In the case of FN-DSA, the SHAKE-256 hash functi on is used as part of the signature process to derive a digest of the message be ing signed.</t>
<t>Therefore, ML-DSA, FN-DSA, and SLH-DSA offer enhanced security over t he traditional Hash-then-Sign paradigm because by incorporating dynamic key mate rial into the message digest, a pre-computed hash collision on the message to be signed no longer yields a signature forgery. Applications requiring the perform ance and bandwidth benefits of Hash-then-Sign may still pre-hash at the protocol level prior to invoking ML-DSA, FN-DSA, or SLH-DSA, but protocol designers shou ld be aware that doing so re-introduces the weakness that hash collisions direct ly yield signature forgeries. Signing the full un-digested message is recommende d where applications can tolerate it.</t> <t>Therefore, ML-DSA, FN-DSA, and SLH-DSA offer enhanced security over t he traditional Hash-then-Sign paradigm because, by incorporating dynamic key mat erial into the message digest, a pre-computed hash collision on the message to b e signed no longer yields a signature forgery. Applications requiring the perfor mance and bandwidth benefits of Hash-then-Sign may still pre-hash at the protoco l level prior to invoking ML-DSA, FN-DSA, or SLH-DSA, but protocol designers sho uld be aware that doing so reintroduces the weakness that hash collisions direct ly yield signature forgeries. Signing the full un-digested message is recommende d where applications can tolerate it.</t>
</section> </section>
</section> </section>
<section anchor="RecSecurity"> <section anchor="RecSecurity">
<name>NIST Recommendations for Security / Performance Tradeoffs</name> <name>NIST Recommendations for Security and Performance Trade-offs</name>
<t>This information is a re-print of information provided in the NIST PQC <t>This information is a reprint of information provided in the NIST PQC p
project <xref target="NIST"/> as of the time this document is published. The Tab roject <xref target="NIST"/> as of the time this document is published. <xref ta
le 2 denotes the five security levels provided by NIST for PQC algorithms. Neith rget="security-levels-table"/> denotes the five security levels provided by NIST
er NIST nor the IETF make any specific recommendations about which security leve for PQC algorithms. Neither NIST nor the IETF makes any specific recommendation
l to use. In general, protocols will include algorithm choices at multiple level s about which security level to use. In general, protocols will include algorith
s so that users can choose the level appropriate to their policies and data clas m choices at multiple levels so that users can choose the level appropriate to t
sification, similar to how organizations today choose which size of RSA key to u heir policies and data classification, similar to how organizations today choose
se. The security levels are defined as requiring computational resources compara which size of RSA key to use. The security levels are defined as requiring comp
ble to or greater than an attack on AES (128, 192 and 256) and SHA2/SHA3 algorit utational resources comparable to or greater than an attack on AES (128, 192, an
hms, i.e., exhaustive key recovery for AES and optimal collision search for SHA2 d 256) and SHA2/SHA3 algorithms, i.e., exhaustive key recovery for AES and optim
/SHA3.</t> al collision search for SHA2/SHA3.</t>
<table> <table anchor="security-levels-table">
<thead> <thead>
<tr> <tr>
<th align="left">PQ Security Level</th> <th align="left">PQ Security Level</th>
<th align="left">AES/SHA(2/3) hardness</th> <th align="left">AES/SHA(2/3) hardness</th>
<th align="left">PQC Algorithm</th> <th align="left">PQC Algorithm</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
skipping to change at line 856 skipping to change at line 1171
<td align="left">SHA-384/SHA3-384 (collision search)</td> <td align="left">SHA-384/SHA3-384 (collision search)</td>
<td align="left">No algorithm tested at this level</td> <td align="left">No algorithm tested at this level</td>
</tr> </tr>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">AES-256 (exhaustive key recovery)</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/S HAKE-256f/s</td> <td align="left">ML-KEM-1024, FN-DSA-1024, ML-DSA-87, SLH-DSA-SHA2/S HAKE-256f/s</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The SLH-DSA-x-yf/s "f/s" in the above table denotes whether SLH-DSA is <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 fa using SHAKE or SHA-2 as an underlying hash function "x" and whether it is the fa
st (f) or small (s) version for "y" bit AES security level. Refer to <xref targe st (f) or small (s) version for "y" bit AES security level. Refer to <xref targe
t="I-D.ietf-lamps-cms-sphincs-plus"/> for further details on SLH-DSA algorithms. t="RFC9814"/> for further details on SLH-DSA algorithms.</t>
</t> <t>The following table compares the signature sizes for different SLH-DSA
<t>The following table compares the signature sizes for different SLH-DSA algorithm categories at equivalent security levels using the "simple" version. T
algorithm categories at equivalent security levels, using the "simple" version. he categories include "f" for fast signature generation and "s" for smaller sign
The categories include "(f)" for fast signature generation, and "(s)" for smalle ature size and faster verification, although with slower signature generation. B
r signature size and faster verification, although with slower signature generat oth SHA-256 and SHAKE-256 parameterizations produce the same signature sizes and
ion. Both SHA-256 and SHAKE-256 parameterizations produce the same signature siz are therefore included together in the table.</t>
es and are therefore included together in the table.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">PQ Security Level</th> <th align="left">PQ Security Level</th>
<th align="left">Algorithm</th> <th align="left">Algorithm</th>
<th align="left">Public key size (in bytes)</th> <th align="left">Public key size (in bytes)</th>
<th align="left">Private key size (in bytes)</th> <th align="left">Private key size (in bytes)</th>
<th align="left">Signature size (in bytes)</th> <th align="left">Signature size (in bytes)</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 983 skipping to change at line 1298
</tr> </tr>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">ML-DSA-87</td> <td align="left">ML-DSA-87</td>
<td align="left">2592</td> <td align="left">2592</td>
<td align="left">4896</td> <td align="left">4896</td>
<td align="left">4627</td> <td align="left">4627</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> <!-- [rfced] We note that the title of Section 12 contains the only
abbreviation of KEX in the document. May we rephrase the section title as
follows? Or should "(KEXs)" be left here as is?
Original:
Comparing PQC KEMs/Signatures vs. Traditional KEMs (KEXs)/Signatures
Perhaps:
Comparing PQC KEMs/Signatures and Traditional KEMs/Signatures
-->
</section>
<section anchor="Comparisons"> <section anchor="Comparisons">
<name>Comparing PQC KEMs/Signatures vs. Traditional KEMs (KEXs)/Signatures <name>Comparing PQC KEMs/Signatures and Traditional KEMs (KEXs)/Signatures
</name> </name>
<t>This section provides two tables for comparison of different KEMs and s <t>This section provides two tables for comparison of different KEMs and s
ignatures respectively, in the traditional and post-quantum scenarios. These tab ignatures, respectively, in the traditional and post-quantum scenarios. These ta
les focus on the secret key sizes, public key sizes, and ciphertext/signature si bles focus on the secret key sizes, public key sizes, and ciphertext/signature s
zes for the PQC algorithms and their traditional counterparts of similar securit izes for the PQC algorithms and their traditional counterparts of similar securi
y levels.</t> ty levels.</t>
<t>The first table compares traditional vs. PQC KEMs in terms of security, <t>The first table compares traditional and PQC KEMs in terms of security,
public and private key sizes, and ciphertext sizes.</t> public and private key sizes, and ciphertext sizes.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">PQ Security Level</th> <th align="left">PQ Security Level</th>
<th align="left">Algorithm</th> <th align="left">Algorithm</th>
<th align="left">Public key size (in bytes)</th> <th align="left">Public key size (in bytes)</th>
<th align="left">Private key size (in bytes)</th> <th align="left">Private key size (in bytes)</th>
<th align="left">Ciphertext size (in bytes)</th> <th align="left">Ciphertext size (in bytes)</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 1043 skipping to change at line 1369
</tr> </tr>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">ML-KEM-1024</td> <td align="left">ML-KEM-1024</td>
<td align="left">1568</td> <td align="left">1568</td>
<td align="left">3168</td> <td align="left">3168</td>
<td align="left">1568</td> <td align="left">1568</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The next table compares traditional vs. PQC signature schemes in terms of security, public, private key sizes, and signature sizes.</t> <t>The next table compares traditional and PQC signature schemes in terms of security, public, private key sizes, and signature sizes.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">PQ Security Level</th> <th align="left">PQ Security Level</th>
<th align="left">Algorithm</th> <th align="left">Algorithm</th>
<th align="left">Public key size (in bytes)</th> <th align="left">Public key size (in bytes)</th>
<th align="left">Private key size (in bytes)</th> <th align="left">Private key size (in bytes)</th>
<th align="left">Signature size (in bytes)</th> <th align="left">Signature size (in bytes)</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 1106 skipping to change at line 1432
</tr> </tr>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">ML-DSA-87</td> <td align="left">ML-DSA-87</td>
<td align="left">2592</td> <td align="left">2592</td>
<td align="left">4896</td> <td align="left">4896</td>
<td align="left">4627</td> <td align="left">4627</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>As is clear from the above table, PQC KEMs and signature schemes typica lly have significantly larger keys and ciphertexts/signatures than their traditi onal counterparts. These increased key and signatures sizes could introduce prob lems in protocols. As an example, IKEv2 uses UDP as the transport for its messag es. One challenge with integrating a PQC KEM into IKEv2 is that IKE fragmentatio n 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 calle d the "Intermediate Exchange" which can be fragmented using the IKE fragmentatio n mechanism. <xref target="RFC9370"/> then uses this Intermediate Exchange to ca rry out the PQC key exchange after the initial IKEv2 exchange and before the IKE _AUTH exchange. Another example from <xref target="SP-1800-38C"/> section 6.3.3 shows that increased key and signature sizes cause protocol key exchange message s to span more network packets, therefore it results in a higher total loss prob ability per packet. In lossy network conditions, this may increase the latency o f the key exchange.</t> <t>As is clear from the above table, PQC KEMs and signature schemes typica lly have significantly larger keys and ciphertexts/signatures than their traditi onal counterparts. These increased key and signatures sizes could introduce prob lems in protocols. As an example, the Internet Key Exchange Protocol Version 2 ( IKEv2) uses UDP as the transport protocol for its messages. One challenge with i ntegrating 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 "Intermediate Exch ange", which can be fragmented using the IKE fragmentation mechanism. <xref targ et="RFC9370"/> then uses this Intermediate Exchange to carry out the PQC key exc hange after the initial IKEv2 exchange and before the IKE_AUTH exchange. Another example from Section 6.3.3 of <xref target="SP-1800-38C"/> shows that increased key and signature sizes cause protocol key exchange messages to span more netwo rk packets, which results in a higher total loss probability per packet. In loss y network conditions, this may increase the latency of the key exchange.</t>
</section> </section>
<section anchor="PQT"> <section anchor="PQT">
<name>Post-Quantum and Traditional Hybrid Schemes</name> <name>Post-Quantum and Traditional (PQ/T) Hybrid Schemes</name>
<t>The migration to PQC is unique in the history of modern digital cryptog raphy in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required lifetimes. The traditional a lgorithms, such as RSA and ECDH, will fall to quantum cryptanalysis, while the p ost-quantum algorithms face uncertainty about the underlying mathematics, compli ance 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>The migration to PQC is unique in the history of modern digital cryptog raphy in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required lifetimes. The traditional a lgorithms, such as RSA and ECDH, will fall to quantum cryptanalysis, while the p ost-quantum algorithms face uncertainty about the underlying mathematics, compli ance 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, ther e may be a desire or a requirement for protocols that use both algorithm types. <xref target="I-D.ietf-pquip-pqt-hybrid-terminology"/> defines the terminology f or the post-quantum and traditional (PQ/T) hybrid schemes.</t> <t>During the transition from traditional to post-quantum algorithms, ther e may be a desire or a requirement for protocols that use both algorithm types. <xref target="RFC9794"/> defines the terminology for PQ/T hybrid schemes.</t>
<section anchor="pqt-hybrid-confidentiality"> <section anchor="pqt-hybrid-confidentiality">
<name>PQ/T Hybrid Confidentiality</name> <name>PQ/T Hybrid Confidentiality</name>
<t>The PQ/T Hybrid Confidentiality property can be used to mitigate both <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 "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 "/>. If the PQ portion were to have a flaw, the traditional (T) algorithm, which
is secure against today’s attackers, prevents immediate decryption ("harvest no is secure against today's attackers, prevents immediate decryption ("harvest no
w, decrypt now"). If the T algorithm is broken in the future by CRQCs, the PQ po w, decrypt now"). If the T algorithm is broken in the future by CRQCs, the PQ po
rtion, assuming it remains secure, prevents later decryption ("harvest now, decr rtion, assuming it remains secure, prevents later decryption (i.e., HNDL). A hyb
ypt later"). A hybrid construction therefore provides confidentiality as long as rid construction therefore provides confidentiality as long as at least one comp
at least one component remains secure. Two types of hybrid key agreement scheme onent remains secure. Two types of hybrid key agreement schemes are discussed be
s are discussed below.</t> low.</t>
<ul spacing="normal"> <dl>
<li> <dt>Concatenated hybrid key agreement scheme:</dt>
<t>Concatenated hybrid key agreement scheme: The final shared secret <dd>
that will be used as an input of the key derivation function is the result of t <t>The final shared secret that will be used as an input of the key
he concatenation of the secrets established with each key agreement scheme. For derivation function is the result of the concatenation of the secrets establishe
example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client uses the TLS d with each key agreement scheme. For example, in <xref target="I-D.ietf-tls-hyb
supported groups extension to advertise support for a PQ/T hybrid scheme, and t rid-design"/>, the client uses the TLS supported groups extension to advertise s
he server can select this group if it supports the scheme. The hybrid-aware clie upport for a PQ/T hybrid scheme, and the server can select this group if it supp
nt and server establish a hybrid secret by concatenating the two shared secrets, orts the scheme. The hybrid-aware client and server establish a hybrid secret by
which is used as the shared secret in the existing TLS 1.3 key schedule.</t> concatenating the two shared secrets, which is used as the shared secret in the
</li> existing TLS 1.3 key schedule.</t>
<li> </dd>
<t>Cascaded hybrid key agreement scheme: The final shared secret is <dt>Cascaded hybrid key agreement scheme:</dt>
computed by applying as many iterations of the key derivation function as the nu <dd>
mber of key agreement schemes composing the hybrid key agreement scheme. For exa <t>The final shared secret is computed by applying as many iteration
mple, <xref target="RFC9370"/> extends the Internet Key Exchange Protocol Versio s of the key derivation function as the number of key agreement schemes composin
n 2 (IKEv2) to allow one or more PQC algorithms in addition to the traditional a g the hybrid key agreement scheme. For example, <xref target="RFC9370"/> extends
lgorithm to derive the final IKE SA keys using the cascade method as explained i IKEv2 to allow one or more PQC algorithms in addition to the traditional algori
n Section 2.2.2 of <xref target="RFC9370"/>.</t> thm to derive the final IKE Security Association (SA) keys using the cascade met
</li> hod as explained in <xref section="2.2.2" sectionFormat="of" target="RFC9370"/>.
</ul> </t>
</dd>
</dl>
<t>Various instantiations of these two types of hybrid key agreement sch emes 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 guarante ed for the scheme as long as at least one of the component algorithms is IND-CCA 2 secure.</t> <t>Various instantiations of these two types of hybrid key agreement sch emes 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 guarante ed for the scheme as long as at least one of the component algorithms is IND-CCA 2 secure.</t>
</section> </section>
<section anchor="pqt-hybrid-authentication"> <section anchor="pqt-hybrid-authentication">
<name>PQ/T Hybrid Authentication</name> <name>PQ/T Hybrid Authentication</name>
<t>The PQ/T hybrid authentication property provides resilience against c atastrophic breaks or unforeseen vulnerabilities in PQC algorithms, allowing sys tems additional time to stabilize before migrating fully to pure PQ deployments. </t> <t>The PQ/T hybrid authentication property provides resilience against c atastrophic breaks or unforeseen vulnerabilities in PQC algorithms, allowing sys tems additional time to stabilize before migrating fully to pure PQ deployments. </t>
<t>This property ensures authentication using a PQ/T hybrid scheme, as l ong as at least one component algorithm remains secure. For example, a PQ/T hybr id 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 aut hentication protocol does not need to use a PQ/T hybrid certificate; separate ce rtificates could be used for individual component algorithms <xref target="I-D.i etf-lamps-cert-binding-for-multi-auth"/>. When separate certificates are used, i t may be possible for attackers to take them apart or put them together in unexp ected ways, including enabling cross-protocol attacks. The exact risks this pres ents are highly dependent on the protocol and use case, so a full security analy sis is needed. Best practices for ensuring that pairs of certificates are only u sed as intended are discussed in more detail in <xref target="COMPOSITE"/> and < xref target="REUSE"/> of this document.</t> <t>This property ensures authentication using a PQ/T hybrid scheme as lo ng as at least one component algorithm remains secure. For example, a PQ/T hybri d 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 auth entication protocol does not need to use a PQ/T hybrid certificate; separate cer tificates could be used for individual component algorithms <xref target="RFC976 3"/>. When separate certificates are used, it may be possible for attackers to t ake them apart or put them together in unexpected ways, including enabling cross -protocol attacks. The exact risks this presents are highly dependent on the pro tocol and use case, so a full security analysis is needed. Best practices for en suring that pairs of certificates are only used as intended are discussed in mor e detail in Sections <xref target="COMPOSITE" format="counter"/> and <xref targe t="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 t o support the PQ/T Hybrid Authentication property.</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 t o support the PQ/T Hybrid Authentication property.</t>
</section> </section>
<section anchor="hybrid-cryptographic-algorithm-combinations-consideration s-and-approaches"> <section anchor="hybrid-cryptographic-algorithm-combinations-consideration s-and-approaches">
<name>Hybrid Cryptographic Algorithm Combinations: Considerations and Ap proaches</name> <name>Hybrid Cryptographic Algorithm Combinations: Considerations and Ap proaches</name>
<section anchor="hybrid-cryptographic-combinations"> <section anchor="hybrid-cryptographic-combinations">
<name>Hybrid Cryptographic Combinations</name> <name>Hybrid Cryptographic Combinations</name>
<t>It is also possible to use more than two algorithms together in a h ybrid scheme, with various methods for combining them. For post-quantum transiti on purposes, the combination of a post-quantum algorithm with a traditional algo rithm is the most straightforward and recommended. The use of multiple post-quan tum algorithms with different mathematical bases has also been considered. Combi ning algorithms in a way that requires both to be used together ensures stronger security, while combinations that do not require both will sacrifice security b ut offer other benefits like backwards compatibility and crypto agility. Includi ng a traditional key alongside a post-quantum key often has minimal bandwidth im pact.</t> <t>It is also possible to use more than two algorithms together in a h ybrid scheme, with various methods for combining them. For post-quantum transiti on purposes, the combination of a post-quantum algorithm with a traditional algo rithm is the most straightforward and recommended. The use of multiple post-quan tum algorithms with different mathematical bases has also been considered. Combi ning algorithms in a way that requires both to be used together ensures stronger security, while combinations that do not require both will sacrifice security b ut offer other benefits like backwards compatibility and crypto agility. Includi ng a traditional key alongside a post-quantum key often has minimal bandwidth im pact.</t>
</section> </section>
<section anchor="COMPOSITE"> <section anchor="COMPOSITE">
<name>Composite Keys in Hybrid Schemes</name> <name>Composite Keys in Hybrid Schemes</name>
<t>When combining keys in an "and" mode, it may make more sense to con <t>When combining keys in an "and" mode, it may make more sense to con
sider them to be a single composite key, instead of two keys. This generally req sider them to be a single composite key instead of two keys. This generally requ
uires fewer changes to various components of PKI ecosystems, many of which are n ires fewer changes to various components of PKI ecosystems, many of which are no
ot prepared to deal with two keys or dual signatures. To those protocol- or appl t prepared to deal with two keys or dual signatures. To those protocol- or appli
ication-layer parsers, a "composite" algorithm composed of two "component" algor cation-layer parsers, a "composite" algorithm composed of two "component" algori
ithms is simply a new algorithm, and support for adding new algorithms generally thms is simply a new algorithm, and support for adding new algorithms generally
already exists. Treating multiple "component" keys as a single "composite" key already exists. Treating multiple "component" keys as a single "composite" key a
also has security advantages such as preventing cross-protocol reuse of the indi lso has security advantages, such as preventing cross-protocol reuse of the indi
vidual component keys and guarantees about revoking or retiring all component ke vidual component keys and guarantees about revoking or retiring all component ke
ys together at the same time, especially if the composite is treated as a single ys together at the same time, especially if the composite is treated as a single
object all the way down into the cryptographic module.</t> 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 <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 data structure, and two keys from the two algorithms are combined into a single data structure and h
how the two resulting signatures or KEMs are combined into a single signature or ow the two resulting signatures or KEMs are combined into a single signature or
KEM. The answer can be as simple as concatenation, if the lengths are fixed or KEM. The answer can be as simple as concatenation if the lengths are fixed or ea
easily determined. At the time this document is published, security research is sily determined. At the time this document is published, security research is on
ongoing as to the security properties of concatenation-based composite signature going as to the security properties of concatenation-based composite signatures
s and KEMs vs. more sophisticated signature and KEM combiners, and in which prot and KEMs versus more sophisticated signature and KEM combiners and protocol cont
ocol contexts those simpler combiners are sufficient.</t> exts in which those simpler combiners are sufficient.</t>
<t>One last consideration is the specific pairs of algorithms that can <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 "kn be combined. A recent trend in protocols is to only allow a small number of "kn
own good" configurations that make sense, often referred to in cryptography as a own good" configurations that make sense, often referred to in cryptography as a
"ciphersuite", instead of allowing arbitrary combinations of individual configu "ciphersuite", instead of allowing arbitrary combinations of individual configu
ration choices that may interact in dangerous ways. The current consensus is tha ration choices that may interact in dangerous ways. The current consensus is tha
t the same approach should be followed for combining cryptographic algorithms, a t the same approach should be followed for combining cryptographic algorithms an
nd that "known good" pairs should be explicitly listed ("explicit composite"), i d that "known good" pairs should be explicitly listed ("explicit composite") ins
nstead of just allowing arbitrary combinations of any two cryptographic algorith tead of just allowing arbitrary combinations of any two cryptographic algorithms
ms ("generic composite").</t> ("generic composite").</t>
<t>The same considerations apply when using multiple certificates to t <t>The same considerations apply when using multiple certificates to t
ransport a pair of related keys for the same subject. Exactly how two certificat ransport a pair of related keys for the same subject. Exactly how two certificat
es should be managed in order to avoid some of the pitfalls mentioned above is s es should be managed in order to avoid some of the pitfalls mentioned above is s
till an active area of investigation. Using two certificates keeps the certifica till an active area of investigation. Using two certificates keeps the certifica
te tooling simple and straightforward, but in the end simply moves the problems te tooling simple and straightforward, but in the end, simply moves the problems
with requiring that both certs are intended to be used as a pair, must produce t with requiring that both certificates are intended to be used as a pair, must p
wo signatures which must be carried separately, and both must validate, to the c roduce two signatures that must be carried separately, and both must validate, t
ertificate management layer, where addressing these concerns in a robust way can o the certificate management layer, where addressing these concerns in a robust
be difficult.</t> way can be difficult.</t>
<t>At least one scheme has been proposed that allows the pair of certi <t>At least one scheme has been proposed that allows the pair of certi
ficates to exist as a single certificate when being issued and managed, but dyna ficates to exist as a single certificate when being issued and managed but dynam
mically split into individual certificates when needed (<xref target="I-D.draft- ically split into individual certificates when needed (see <xref target="I-D.bon
bonnell-lamps-chameleon-certs"/>).</t> nell-lamps-chameleon-certs"/>).</t>
</section> <!-- [rfced] This sentence is difficult to follow, especially the phra
se "with
requiring...must validate". How may we revise for clarity?
Current:
Using two certificates keeps the certificate tooling simple and
straightforward, but in the end simply moves the problems with
requiring that both certs are intended to be used as a pair, must
produce two signatures that must be carried separately, and both
must validate, to the certificate management layer, where addressing
these concerns in a robust way can be difficult.
Perhaps:
Using two certificates keeps the certificate tooling simple and
straightforward, but in the end, this simply moves problems (i.e., problems w
ith
the requirement that both certificates be used as a pair, that
two signatures that must be carried separately, and that both
validate) to the certificate management layer, where addressing
these concerns in a robust way can be difficult.
-->
<!-- [rfced] Will readers understand "hybrids" and "a hybrid" in these
sentences? The document discusses "hybrid keys", "hybrid schemes", "hybrid
settings", etc.
Original:
However, key reuse becomes a large security problem within hybrids.
...
Therefore, it is recommended that
implementers either reuse the entire hybrid key as a 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 a
hybrid.
...
Another potential application of hybrids bears mentioning, even
though it is not directly PQC-related. That is using hybrids to
navigate inter-jurisdictional cryptographic connections.
...
If "and" mode hybrids become standardized for the reasons mentioned
above,
-->
</section>
<section anchor="REUSE"> <section anchor="REUSE">
<name>Key Reuse in Hybrid Schemes</name> <name>Key Reuse in Hybrid Schemes</name>
<t>An important security note, particularly when using hybrid signatur <t>An important security note, particularly when using hybrid signatur
e keys, but also to a lesser extent hybrid KEM keys, is key reuse. In traditiona e keys, but also to a lesser extent hybrid KEM keys, is key reuse. In traditiona
l cryptography, problems can occur with so-called "cross-protocol attacks" when l cryptography, problems can occur with so-called "cross-protocol attacks" when
the same key can be used for multiple protocols; for example signing TLS handsha the same key can be used for multiple protocols; for example, signing TLS handsh
kes and signing S/MIME emails. While it is not best-practice to reuse keys withi akes and signing S/MIME emails. While it is not best practice to reuse keys with
n the same protocol, for example using the same key for multiple S/MIME certific in the same protocol, e.g., using the same key for multiple S/MIME certificates
ates for the same user, it is not generally catastrophic for security. However, for the same user, it is not generally catastrophic for security. However, key r
key reuse becomes a large security problem within hybrids.</t> euse becomes a large security problem within hybrids.</t>
<t>Consider an {RSA, ML-DSA} hybrid key where the RSA key also appears <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 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 a "stripping attack" where they take some piece of data signed with the {RSA, ML
-DSA} key, remove the ML-DSA signature and present the data as if it was intende -DSA} key, remove the ML-DSA signature, and present the data as if it was intend
d for the RSA only certificate. This leads to a set of security definitions call ed for the RSA only certificate. This leads to a set of security definitions cal
ed "non-separability properties", which refers to how well the signature scheme led "non-separability properties", which refers to how well the signature scheme
resists various complexities of downgrade / stripping attacks <xref target="I-D. resists various complexities of downgrade/stripping attacks <xref target="I-D.i
draft-ietf-pquip-hybrid-signature-spectrums"/>. Therefore, it is recommended tha etf-pquip-hybrid-signature-spectrums"/>. Therefore, it is recommended that imple
t implementers either reuse the entire hybrid key as a whole, or perform fresh k menters either reuse the entire hybrid key as a whole or perform fresh key gener
ey generation of all component keys per usage, and must not take an existing key ation of all component keys per usage, and must not take an existing key and reu
and reuse it as a component of a hybrid.</t> se it as a component of a hybrid.</t>
</section> </section>
<section anchor="future-directions-and-ongoing-research"> <section anchor="future-directions-and-ongoing-research">
<name>Future Directions and Ongoing Research</name> <name>Future Directions and Ongoing Research</name>
<t>Many aspects of hybrid cryptography are still under investigation. LAMPS WG at IETF is actively exploring the security properties of these combinat ions, and future standards will reflect the evolving consensus on these issues.< /t> <t>Many aspects of hybrid cryptography are still under investigation. The LAMPS Working 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>
</section> </section>
<section anchor="impact-on-constrained-devices-and-networks"> <section anchor="impact-on-constrained-devices-and-networks">
<name>Impact on Constrained Devices and Networks</name> <name>Impact on Constrained Devices and Networks</name>
<t>PQC algorithms generally have larger keys, ciphertext, and signature si <!-- [rfced] Please review the parenthetical here. Is the intent of "(e.g.
zes than traditional public key algorithms. This has particular impact on constr ,
ained devices that operate with limited data rates. In the IoT space, these cons LAKE, Core)" to be "(e.g., in the LAKE and CoRE Working Groups)"?
traints have historically driven significant optimization efforts in the IETF (e
.g., LAKE, CoRE) to adapt security protocols to resource-constrained environment Original:
s.</t> In the IoT space, these constraints have historically driven
significant optimization efforts in the IETF (e.g., LAKE, CoRE) to
adapt security protocols to resource-constrained environments.
Perhaps:
In the IoT space, these constraints have historically driven
significant optimization efforts in the IETF (e.g., in the LAKE and CoRE
Working Groups) to
adapt security protocols to resource-constrained environments.
-->
<t>PQC algorithms generally have larger keys, ciphertext, and signature sizes th
an traditional public key algorithms. This has particular impact on constrained
devices that operate with limited data rates. In the Internet of Things (IoT) sp
ace, these constraints have historically driven significant optimization efforts
in the IETF (e.g., LAKE and CoRE) to adapt security protocols to resource-const
rained environments.</t>
<t>As the transition to PQC progresses, these environments will face simil ar challenges. Larger message sizes can increase handshake latency, raise energy consumption, and require fragmentation logic. Work is ongoing in the IETF to st udy how PQC can be deployed in constrained devices (see <xref target="I-D.ietf-p quip-pqc-hsm-constrained"/>).</t> <t>As the transition to PQC progresses, these environments will face simil ar challenges. Larger message sizes can increase handshake latency, raise energy consumption, and require fragmentation logic. Work is ongoing in the IETF to st udy how PQC can be deployed in constrained devices (see <xref target="I-D.ietf-p quip-pqc-hsm-constrained"/>).</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="cryptanalysis"> <section anchor="cryptanalysis">
<name>Cryptanalysis</name> <name>Cryptanalysis</name>
<t>Traditional cryptanalysis exploits weaknesses in algorithm design, ma <t>Traditional cryptanalysis exploits weaknesses in algorithm design, ma
thematical vulnerabilities, or implementation flaws, that are exploitable with c thematical vulnerabilities, or implementation flaws that are exploitable with cl
lassical (i.e. non-quantum) hardware, whereas quantum cryptanalysis harnesses th assical (i.e., non-quantum) hardware, whereas quantum cryptanalysis harnesses th
e power of CRQCs to solve specific mathematical problems more efficiently. Anoth e power of CRQCs to solve specific mathematical problems more efficiently. Quant
er form of quantum cryptanalysis is "quantum side-channel" attacks. In such atta um side-channel attacks are another form of quantum cryptanalysis. In such attac
cks, a device under threat is directly connected to a quantum computer, which th ks, a device under threat is directly connected to a quantum computer, which the
en injects entangled or superimposed data streams to exploit hardware that lacks n injects entangled or superimposed data streams to exploit hardware that lacks
protection against quantum side-channels. Both pose threats to the security of protection against quantum side channels. Both pose threats to the security of c
cryptographic algorithms, including those used in PQC. Developing and adopting n ryptographic algorithms, including those used in PQC. It is crucial to develop a
ew cryptographic algorithms resilient against these threats is crucial for ensur nd adopt new cryptographic algorithms resilient against these threats to ensure
ing long-term security in the face of advancing cryptanalysis techniques.</t> long-term security in the face of advancing cryptanalysis techniques.</t>
<t>Recent attacks on the side-channel implementations using deep learnin <t>Recent attacks on the side-channel implementations using deep learnin
g based power analysis have also shown that one needs to be cautious while imple g-based power analysis have also shown that one needs to be cautious while imple
menting the required PQC algorithms in hardware. Two of the most recent works in menting the required PQC algorithms in hardware. Two of the most recent works in
clude one attack on ML-KEM <xref target="KyberSide"/> and one attack on Saber <x clude one attack on ML-KEM <xref target="KyberSide"/> and one attack on Saber <x
ref target="SaberSide"/>. An evolving threat landscape points to the fact that l ref target="SaberSide"/>. An evolving threat landscape points to the fact that l
attice based cryptography is indeed more vulnerable to side-channel attacks as i attice-based cryptography is indeed more vulnerable to side-channel attacks as i
n <xref target="SideCh"/>, <xref target="LatticeSide"/>. Consequently, there wer n <xref target="SideCh"/> and <xref target="LatticeSide"/>. Consequently, some m
e some mitigation techniques for side channel attacks that have been proposed as itigation techniques for side-channel attacks have been proposed; see <xref targ
in <xref target="Mitigate1"/>, <xref target="Mitigate2"/>, and <xref target="Mi et="Mitigate1"/>, <xref target="Mitigate2"/>, and <xref target="Mitigate3"/>.</t
tigate3"/>.</t> >
</section> </section>
<section anchor="cryptographic-agility"> <section anchor="cryptographic-agility">
<name>Cryptographic Agility</name> <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 s tronger algorithms, comply with standards, and plan for long-term security in th e face of evolving cryptanalytic techniques and the advent of CRQCs.</t> <t>Cryptographic agility is recommended for both traditional and quantum cryptanalysis as it enables organizations to adapt to emerging threats, adopt s tronger algorithms, comply with standards, and plan for long-term security in th e face of evolving cryptanalytic techniques and the advent of CRQCs.</t>
<t>Several PQC schemes are available that need to be tested; cryptograph <t>Several PQC schemes are available that need to be tested; cryptograph
y experts around the world are pushing for the best possible solutions, and the y experts around the world are pushing for the best possible solutions, and the
first standards that will ease the introduction of PQC are being prepared. It is first standards that will ease the introduction of PQC are being prepared. This
of paramount importance and a call for imminent action for organizations, bodie is of paramount importance and is a call for imminent action for organizations,
s, and enterprises to start evaluating their cryptographic agility, assess the c bodies, and enterprises to start evaluating their cryptographic agility, assess
omplexity of implementing PQC into their products, processes, and systems, and d the complexity of implementing PQC into their products, processes, and systems,
evelop a migration plan that achieves their security goals to the best possible and develop a migration plan that achieves their security goals to the best poss
extent.</t> ible extent.</t>
<t>An important and often overlooked step in achieving cryptographic agi <t>An important and often overlooked step in achieving cryptographic agi
lity is maintaining a cryptographic inventory. Modern software stacks incorporat lity is maintaining a cryptographic inventory. Modern software stacks incorporat
e cryptography in numerous places, making it challenging to identify all instanc e cryptography in numerous places, making it challenging to identify all instanc
es. Therefore, cryptographic agility and inventory management take two major for es. Therefore, cryptographic agility and inventory management take two major for
ms: First, application developers responsible for software maintenance should ac ms. First, application developers responsible for software maintenance should ac
tively search for instances of hard-coded cryptographic algorithms within applic tively search for instances of hard-coded cryptographic algorithms within applic
ations. When possible, they should design the choice of algorithm to be dynamic, ations. When possible, they should design the choice of algorithm to be dynamic,
based on application configuration. Second, administrators, policy officers, an based on application configuration. Second, administrators, policy officers, an
d compliance teams should take note of any instances where an application expose d compliance teams should take note of any instances where an application expose
s cryptographic configurations. These instances should be managed either through s cryptographic configurations. These instances should be managed through either
organization-wide written cryptographic policies or automated cryptographic pol organization-wide written cryptographic policies or automated cryptographic pol
icy systems.</t> icy systems.</t>
<t>Numerous commercial solutions are available for both detecting hard-c <t>Numerous commercial solutions are available for detecting hard-coded
oded cryptographic algorithms in source code and compiled binaries, as well as p cryptographic algorithms in source code and compiled binaries, as well as provid
roviding cryptographic policy management control planes for enterprise and produ ing cryptographic policy management control planes for enterprise and production
ction environments.</t> environments.</t>
</section> </section>
<section anchor="jurisdictional-fragmentation"> <section anchor="jurisdictional-fragmentation">
<name>Jurisdictional Fragmentation</name> <name>Jurisdictional Fragmentation</name>
<t>Another potential application of hybrids bears mentioning, even thoug h it is not directly PQC-related. That is using hybrids to navigate inter-jurisd ictional cryptographic connections. Traditional cryptography is already fragment ed by jurisdiction: consider that while most jurisdictions support Elliptic Curv e Diffie-Hellman, those in the United States will prefer the NIST curves while t hose in Germany will prefer the Brainpool curves. China, Russia, and other juris dictions have their own national cryptography standards. This situation of fragm ented global cryptography standards is unlikely to improve with PQC. If "and" mo de hybrids become standardized for the reasons mentioned above, then one could i magine leveraging them to create "ciphersuites" in which a single cryptographic operation simultaneously satisfies the cryptographic requirements of both endpoi nts.</t> <t>Another potential application of hybrids bears mentioning, even thoug h it is not directly related to PQC: using hybrids to navigate inter-jurisdictio nal cryptographic connections. Traditional cryptography is already fragmented by jurisdiction. Consider that while most jurisdictions support ECDH, those in the United States will prefer the NIST curves while those in Germany will prefer th e Brainpool curves. China, Russia, and other jurisdictions have their own nation al cryptography standards. This situation of fragmented global cryptography stan dards is unlikely to improve with PQC. If "and" mode hybrids become standardized for the reasons mentioned above, then one could imagine leveraging them to crea te ciphersuites in which a single cryptographic operation simultaneously satisfi es the cryptographic requirements of both endpoints.</t>
</section> </section>
<section anchor="hybrid-key-exchange-and-signatures-bridging-the-gap-betwe <section anchor="hybrid-key-exchange-and-signatures-bridging-the-gap-betwe
en-post-quantum-and-traditional-cryptography"> en-pqt-cryptography">
<name>Hybrid Key Exchange and Signatures: Bridging the Gap Between Post- <name>Hybrid Key Exchange and Signatures: Bridging the Gap Between PQ/T
Quantum and Traditional Cryptography</name> Cryptography</name>
<t>Post-quantum algorithms selected for standardization are relatively n <t>Post-quantum algorithms selected for standardization are relatively n
ew and they have not been subject to the same depth of study as traditional algo ew and have not been subject to the same depth of study as traditional algorithm
rithms. PQC implementations will also be new and therefore more likely to contai s. PQC implementations will also be new and therefore more likely to contain imp
n implementation bugs than the battle-tested crypto implementations that are rel lementation bugs than the battle-tested crypto implementations that are relied o
ied on today. In addition, certain deployments may need to retain traditional al n today. In addition, certain deployments may need to retain traditional algorit
gorithms due to regulatory constraints, for example FIPS <xref target="SP-800-56 hms due to regulatory constraints, e.g., FIPS <xref target="SP-800-56C"/> or Pay
C"/> or PCI compliance <xref target="PCI"/>. Hybrid key exchange is recommended ment Card Industry (PCI) compliance <xref target="PCI"/>. Hybrid key exchange is
to enhance security against the "harvest now, decrypt later" attack. Additionall recommended to enhance security against the HNDL attack. Additionally, hybrid s
y, hybrid signatures provide for time to react in the case of the announcement o ignatures provide for time to react in the case of the announcement of a devasta
f a devastating attack against any one algorithm, while not fully abandoning tra ting attack against any one algorithm, while not fully abandoning traditional cr
ditional cryptosystems.</t> yptosystems.</t>
<t>Hybrid key exchange performs both a classical and a post-quantum key exchange in parallel. It provides security redundancy against potential weakness es 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 exc hange can combine a widely supported classical algorithm, such as X25519, with a post-quantum algorithm like ML-KEM. This allows legacy clients to continue usin g 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. Thi s strategy ensures a post-quantum secure channel while keeping the overhead mana geable, making it particularly suitable for constrained environments.</t> <t>Hybrid key exchange performs both a classical and a post-quantum key exchange in parallel. It provides security redundancy against potential weakness es 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 exc hange can combine a widely supported classical algorithm, such as X25519, with a post-quantum algorithm like ML-KEM. This allows legacy clients to continue usin g 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. Thi s strategy ensures a post-quantum secure channel while keeping the overhead mana geable, making it particularly suitable for constrained environments.</t>
<t>While some hybrid key exchange options introduce additional computati onal and bandwidth overhead, the impact of traditional key exchange algorithms ( e.g., key size) is typically small, helping to keep the overall increase in reso urce usage manageable for most systems. In highly constrained environments, howe ver, 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 overhea d, 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> <t>While some hybrid key exchange options introduce additional computati onal and bandwidth overhead, the impact of traditional key exchange algorithms ( e.g., key size) is typically small, helping to keep the overall increase in reso urce usage manageable for most systems. In highly constrained environments, howe ver, 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 overhea d, 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>
<section anchor="caution-ciphertext-commitment-in-kem-vs-dh"> <section anchor="caution-ciphertext-commitment-in-kem-vs-dh">
<name>Caution: Ciphertext commitment in KEM vs. DH</name> <name>Caution: Ciphertext Commitment 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 encapsu late the same shared secret, which enables flexibility in key management without enforcing a strict one-to-one correspondence between ciphertexts and shared sec rets. This allows for secret reuse across different recipients, sessions, or ope rational contexts without the need for new secrets for each use, simplifying key distribution and reducing computational overhead. In contrast, cryptographic sc hemes like Diffie-Hellman inherently link the public key to the derived shared s ecret, meaning any change in the public key results in a different shared secret .</t> <t>The ciphertext generated by a KEM is not necessarily directly linked to the shared secret it produces. KEMs allow for multiple ciphertexts to encapsu late the same shared secret, which enables flexibility in key management without enforcing a strict one-to-one correspondence between ciphertexts and shared sec rets. This allows for secret reuse across different recipients, sessions, or ope rational contexts without the need for new secrets for each use, simplifying key distribution and reducing computational overhead. In contrast, cryptographic sc hemes like Diffie-Hellman inherently link the public key to the derived shared s ecret, meaning any change in the public key results in a different shared secret .</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA considerations.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="further-reading-resources"> <section anchor="further-reading-and-resources">
<name>Further Reading &amp; Resources</name> <name>Further Reading and Resources</name>
<t>A good book on modern cryptography is Serious Cryptography, 2nd Edition <t>A good book on modern cryptography is "Serious Cryptography, 2nd Editio
, by Jean-Philippe Aumasson, ISBN 9781718503847.</t> n" by Jean-Philippe Aumasson <xref target="Serious-Crypt"/>.</t>
<t>The Open Quantum Safe (OQS) Project <xref target="OQS"/> is an open-sou rce project that aims to support the transition to quantum-resistant cryptograph y.</t> <t>The Open Quantum Safe (OQS) Project <xref target="OQS"/> is an open-sou rce project that aims to support the transition to quantum-resistant cryptograph y.</t>
<t>The IETF's PQUIP Working Group <xref target="PQUIP-WG"/> maintains a li st of PQC-related protocol work within the IETF.</t> <t>The IETF's PQUIP Working Group <xref target="PQUIP-WG"/> maintains a li st of PQC-related protocol work within the IETF.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.bonnell-lamps-chameleon-certs" to="ENC-PAIR-CE
RTS"/>
<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="HYB
RID-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"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="ML-KEM" target="https://nvlpubs.nist.gov/nistpubs/FIP S/NIST.FIPS.203.pdf"> <reference anchor="ML-KEM" target="https://nvlpubs.nist.gov/nistpubs/FIP S/NIST.FIPS.203.pdf">
<front> <front>
<title>FIPS-203: Module-Lattice-based Key-Encapsulation Mechanism St andard</title> <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</ti tle>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date/> <date year="2024" month="August"/>
</front> </front>
<seriesInfo name="NIST FIPS" value="203"/>
<seriesInfo name="DOI" value="10.6028/nist.fips.203"/>
</reference> </reference>
<reference anchor="ML-DSA" target="https://nvlpubs.nist.gov/nistpubs/FIP S/NIST.FIPS.204.pdf"> <reference anchor="ML-DSA" target="https://nvlpubs.nist.gov/nistpubs/FIP S/NIST.FIPS.204.pdf">
<front> <front>
<title>FIPS-204: Module-Lattice-Based Digital Signature Standard</ti tle> <title>Module-Lattice-Based Digital Signature Standard</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date/> <date year="2024" month="August"/>
</front> </front>
<seriesInfo name="NIST FIPS" value="204"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.204"/>
</reference> </reference>
<reference anchor="SLH-DSA" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.205.pdf"> <reference anchor="SLH-DSA" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.205.pdf">
<front> <front>
<title>FIPS-205: Stateless Hash-Based Digital Signature Standard</ti tle> <title>Stateless Hash-Based Digital Signature Standard</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date/> <date year="2024" month="August"/>
</front> </front>
<seriesInfo name="NIST FIPS" value="205"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.205"/>
</reference> </reference>
<reference anchor="Shors" target="https://arxiv.org/pdf/quant-ph/9508027 "> <reference anchor="Shors" target="https://arxiv.org/pdf/quant-ph/9508027 ">
<front> <front>
<title>Polynomial-time algorithms for prime factorization and discre <title>Polynomial-Time Algorithms for Prime Factorization and Discre
te logarithms on a quantum computer</title> te Logarithms on a Quantum Computer</title>
<author> <author initials="P." surname="Shor" fullname="Peter W. Shor">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date year="1996" month="January" day="25"/>
</front> </front>
<refcontent>arXiv:quant-ph/9508027v2</refcontent>
</reference> </reference>
<reference anchor="Grovers" target="https://dl.acm.org/doi/10.1145/23781 4.237866"> <reference anchor="Grovers" target="https://dl.acm.org/doi/10.1145/23781 4.237866">
<front> <front>
<title>A fast quantum mechanical algorithm for database search</titl e> <title>A fast quantum mechanical algorithm for database search</titl e>
<author> <author fullname="Lok K. Grover">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date year="1996" month="July" day="01"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/237814.237866"/>
<refcontent>STOC '96: Proceedings of the twenty-eighth annual ACM symp
osium on Theory of Computing, pp. 212-219</refcontent>
</reference> </reference>
<reference anchor="RSA" target="https://dl.acm.org/doi/pdf/10.1145/35934 0.359342"> <reference anchor="RSA" target="https://dl.acm.org/doi/pdf/10.1145/35934 0.359342">
<front> <front>
<title>A Method for Obtaining Digital Signatures and Public-Key Cryp <title>A Method for Obtaining Digital Signatures and Public-Key Cryp
tosystems+</title> tosystems</title>
<author> <author fullname="Ronald L. Rivest">
<organization/> <organization/>
</author> </author>
<date/> <author initials="A." surname="Shamir">
</front> <organization/>
</reference> </author>
<reference anchor="RFC6090"> <author initials="L." surname="Adleman">
<front> <organization/>
<title>Fundamental Elliptic Curve Cryptography Algorithms</title> </author>
<author fullname="D. McGrew" initials="D." surname="McGrew"/> <date year="1978" month="February"/>
<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 Curv
e Cryptography (ECC) as they were defined in some seminal references from 1994 a
nd earlier. These descriptions may be useful for implementing the fundamental al
gorithms without using any of the specialized methods that were developed in fol
lowing 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 informatio
nal 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>
<author fullname="A. Huelsing" initials="A." surname="Huelsing"/>
<author fullname="D. Butin" initials="D." surname="Butin"/>
<author fullname="S. Gazdag" initials="S." surname="Gazdag"/>
<author fullname="J. Rijneveld" initials="J." surname="Rijneveld"/>
<author fullname="A. Mohaisen" initials="A." surname="Mohaisen"/>
<date month="May" year="2018"/>
<abstract>
<t>This note describes the eXtended Merkle Signature Scheme (XMSS)
, a hash-based digital signature system that is based on existing descriptions i
n 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 con
jectured hardness of mathematical problems. Instead, it is proven that it only r
elies on the properties of cryptographic hash functions. XMSS provides strong se
curity guarantees and is even secure when the collision resistance of the underl
ying hash function is broken. It is suitable for compact implementations, is rel
atively simple to implement, and naturally resists side-channel attacks. Unlike
most other signature systems, hash-based signatures can so far withstand known a
ttacks 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 cryptog
raphic hash functions, following the seminal work in this area of Lamport, Diffi
e, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifi
es a one-time signature scheme and a general signature scheme. These systems pro
vide asymmetric authentication without using large integer mathematics and can a
chieve a high security level. They are suitable for compact implementations, are
relatively simple to implement, and are naturally resistant to side-channel att
acks. 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 resea
rch 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</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="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 part of a family of documents that describe th
e DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection
of resource records and protocol modifications that provide source authenticati
on for the DNS. This document defines the public key (DNSKEY), delegation signer
(DS), resource record digital signature (RRSIG), and authenticated denial of ex
istence (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> </front>
<seriesInfo name="RFC" value="4034"/> <seriesInfo name="DOI" value="10.1145/359340.359342"/>
<seriesInfo name="DOI" value="10.17487/RFC4034"/> <refcontent>Communications of the ACM, vol. 21, no. 2, pp. 120-126</re
fcontent>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
090.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
391.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
554.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
034.xml"/>
<reference anchor="NTRU" target="https://ntru.org/index.shtml"> <reference anchor="NTRU" target="https://ntru.org/index.shtml">
<front> <front>
<title>NTRU</title> <title>NTRU</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="FrodoKEM" target="https://frodokem.org/"> <reference anchor="FrodoKEM" target="https://frodokem.org/">
<front> <front>
<title>FrodoKEM</title> <title>FrodoKEM</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="ClassicMcEliece" target="https://classic.mceliece.org /"> <reference anchor="ClassicMcEliece" target="https://classic.mceliece.org /">
<front> <front>
<title>Classic McEliece</title> <title>Classic McEliece</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="FN-DSA" target="https://falcon-sign.info/"> <reference anchor="FN-DSA" target="https://falcon-sign.info/">
<front> <front>
<title>Fast Fourier lattice-based compact signatures over NTRU</titl e> <title>FALCON: Fast Fourier lattice-based compact signatures over NT RU</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="RFC8235"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 235.xml"/>
<title>Schnorr Non-interactive Zero-Knowledge Proof</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="F. Hao" initials="F." role="editor" surname="Hao"/ 180.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="September" year="2017"/> 881.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This document describes the Schnorr non-interactive zero-knowle 242.xml"/>
dge (NIZK) proof, a non-interactive variant of the three-pass Schnorr identifica <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
tion scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discr 370.xml"/>
ete logarithm without leaking any information about its value. It can serve as a </references>
useful building block for many cryptographic protocols to ensure that participa <references anchor="sec-informative-references">
nts follow the protocol specification honestly. This document specifies the Schn <name>Informative References</name>
orr NIZK proof in both the finite field and the elliptic curve settings.</t> <reference anchor="Serious-Crypt">
</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 encrypti
on (HPKE). This scheme provides a variant of public key encryption of arbitrary-
sized plaintexts for a recipient public key. It also includes three authenticate
d 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 deri
vation function (KDF), and authenticated encryption with additional data (AEAD)
encryption function. Some authenticated variants may not be supported by all KEM
s. We provide instantiations of the scheme using widely used and efficient primi
tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke
y 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">
<front> <front>
<title>Internet X.509 Public Key Infrastructure - Algorithm Identifi <title>Serious Cryptography, 2nd Edition</title>
ers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)</title> <author fullname="Jean-Philippe Aumasson">
<author fullname="Jake Massimo" initials="J." surname="Massimo"> <organization/>
<organization>AWS</organization>
</author>
<author fullname="Panos Kampanakis" initials="P." surname="Kampanaki
s">
<organization>AWS</organization>
</author>
<author fullname="Sean Turner" initials="S." surname="Turner">
<organization>sn3rd</organization>
</author>
<author fullname="Bas Westerbaan" initials="B." surname="Westerbaan"
>
<organization>Cloudflare</organization>
</author> </author>
<date day="26" month="June" year="2025"/> <date year="2024" month="August"/>
<abstract>
<t> Digital signatures are used within X.509 certificates, Certi
ficate
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>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-ce
rtificates-12"/>
</reference>
<reference anchor="RFC9242">
<front>
<title>Intermediate Exchange in the Internet Key Exchange Protocol V
ersion 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 Exch
ange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange c
an be used for transferring large amounts of data in the process of IKEv2 Securi
ty Association (SA) establishment. An example of the need to do this is using ke
y exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment
. The Intermediate Exchange makes it possible to use the existing IKE fragmentat
ion mechanism (which cannot be used in the initial IKEv2 exchange), helping to a
void IP fragmentation of large IKE messages if they need to be sent before IKEv2
SA is established.</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"/>
<author fullname="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-M
orchon"/>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
<date month="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 mul
tiple key exchanges are performed when an IKE SA is being established. It also i
ntroduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purp
ose 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 f
rom "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a fi
eld 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 "Transfo
rm Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exch
ange Method Transform IDs". These changes generalize key exchange algorithms tha
t can be used in IKEv2.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9370"/> <refcontent>ISBN 9781718503847</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9370"/>
</reference> </reference>
</references> <reference anchor="Grover-Search" target="https://link.aps.org/doi/10.11
<references anchor="sec-informative-references"> 03/PhysRevA.60.2746">
<name>Informative References</name>
<reference anchor="Grover-search">
<front> <front>
<title>C. Zalka, “Grover’s quantum searching algorithm is optimal,” <title>Grover's quantum searching algorithm is optimal</title>
Physical Review A, vol. 60, pp. 2746-2751, 1999.</title> <author fullname="Christof Zalka">
<author>
<organization/> <organization/>
</author> </author>
<date/> <date year="1999" month="October"/>
</front> </front>
<seriesInfo name="DOI" value="10.1103/PhysRevA.60.2746"/>
<refcontent>Physical Review A, vol. 60, no. 4, pp. 2746-2751</refconte
nt>
</reference> </reference>
<reference anchor="Threat-Report" target="https://globalriskinstitute.or g/publications/quantum-threat-timeline-report-2020/"> <reference anchor="Threat-Report" target="https://globalriskinstitute.or g/publications/quantum-threat-timeline-report-2020/">
<front> <front>
<title>Quantum Threat Timeline Report 2020</title> <title>Quantum Threat Timeline Report 2020</title>
<author> <author fullname="Michele Mosca">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Marco Piani">
<organization/>
</author>
<date year="2021" month="January" day="27"/>
</front> </front>
<refcontent>Global Risk Institute</refcontent>
</reference> </reference>
<reference anchor="QC-DNS" target="https://www.icann.org/octo-031-en.pdf "> <reference anchor="QC-DNS" target="https://www.icann.org/octo-031-en.pdf ">
<front> <front>
<title>Quantum Computing and the DNS</title> <title>Quantum Computing and the DNS</title>
<author> <author fullname="Paul Hoffman">
<organization/> <organization/>
</author> </author>
<date/> <date year="2024" month="April" day="22"/>
</front> </front>
<refcontent>ICANN Office of the Chief Technology Officer, OCTO-031v2</ refcontent>
</reference> </reference>
<reference anchor="NIST" target="https://csrc.nist.gov/projects/post-qua ntum-cryptography/post-quantum-cryptography-standardization"> <reference anchor="NIST" target="https://csrc.nist.gov/projects/post-qua ntum-cryptography/post-quantum-cryptography-standardization">
<front> <front>
<title>Post-Quantum Cryptography Standardization</title> <title>Post-Quantum Cryptography Standardization</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="Cloudflare" target="https://blog.cloudflare.com/nist- post-quantum-surprise/"> <reference anchor="Cloudflare" target="https://blog.cloudflare.com/nist- post-quantum-surprise/">
<front> <front>
<title>NIST’s pleasant post-quantum surprise</title> <title>NIST's pleasant post-quantum surprise</title>
<author> <author fullname="Bas Westerbaan">
<organization/> <organization/>
</author> </author>
<date/> <date year="2022" month="July" day="08"/>
</front> </front>
<refcontent>Cloudflare Blog</refcontent>
</reference> </reference>
<reference anchor="CS01" target="https://eprint.iacr.org/2001/108"> <reference anchor="CS01" target="https://eprint.iacr.org/2001/108">
<front> <front>
<title>Design and Analysis of Practical Public-Key Encryption Scheme s Secure against Adaptive Chosen Ciphertext Attack</title> <title>Design and Analysis of Practical Public-Key Encryption Scheme s Secure against Adaptive Chosen Ciphertext Attack</title>
<author> <author fullname="Ronald Cramer">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Victor Shoup">
<organization/>
</author>
<date year="2001"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2001/108</refcontent>
</reference> </reference>
<reference anchor="BHK09" target="https://eprint.iacr.org/2009/418"> <reference anchor="BHK09" target="https://eprint.iacr.org/2009/418">
<front> <front>
<title>Subtleties in the Definition of IND-CCA: When and How Should Challenge-Decryption be Disallowed?</title> <title>Subtleties in the Definition of IND-CCA: When and How Should Challenge-Decryption be Disallowed?</title>
<author> <author fullname="Mihir Bellare">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Dennis Hofheinz">
<organization/>
</author>
<author fullname="Eike Kiltz">
<organization/>
</author>
<date year="2009"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2009/418</refcontent>
</reference> </reference>
<reference anchor="GMR88" target="https://people.csail.mit.edu/silvio/Se lected%20Scientific%20Papers/Digital%20Signatures/A_Digital_Signature_Scheme_Sec ure_Against_Adaptive_Chosen-Message_Attack.pdf"> <reference anchor="GMR88" target="https://people.csail.mit.edu/silvio/Se lected%20Scientific%20Papers/Digital%20Signatures/A_Digital_Signature_Scheme_Sec ure_Against_Adaptive_Chosen-Message_Attack.pdf">
<front> <front>
<title>A digital signature scheme secure against adaptive chosen-mes <title>A digital signature scheme secure against adaptive chosen-mes
sage attacks.</title> sage attacks</title>
<author> <author fullname="Shafi Goldwasser">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Silvio Micali">
<organization/>
</author>
<author fullname="Ronald L. Rivest">
<organization/>
</author>
<date year="1988" month="April"/>
</front> </front>
<seriesInfo name="DOI" value="10.1137/0217017"/>
<refcontent>SIAM Journal on Computing, vol. 17, no. 2, pp. 281-308</re
fcontent>
</reference> </reference>
<reference anchor="PQCAPI" target="https://csrc.nist.gov/CSRC/media/Proj ects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf"> <reference anchor="PQCAPI" target="https://csrc.nist.gov/CSRC/media/Proj ects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf">
<front> <front>
<title>PQC - API notes</title> <title>PQC - API notes</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="RSA8HRS" target="https://arxiv.org/abs/1905.09749"> <reference anchor="RSA8HRS" target="https://arxiv.org/abs/1905.09749">
<front> <front>
<title>How to factor 2048 bit RSA integers in 8 hours using 20 milli on noisy qubits</title> <title>How to factor 2048 bit RSA integers in 8 hours using 20 milli on noisy qubits</title>
<author> <author fullname="Craig Gidney">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Martin Ekera">
<organization/>
</author>
<date year="2021" month="April" day="13"/>
</front> </front>
<refcontent>arXiv:1905.09749v3</refcontent>
</reference> </reference>
<reference anchor="RSA10SC" target="https://www.quintessencelabs.com/blo g/breaking-rsa-encryption-update-state-art"> <reference anchor="RSA10SC" target="https://www.quintessencelabs.com/blo g/breaking-rsa-encryption-update-state-art">
<front> <front>
<title>Breaking RSA Encryption - an Update on the State-of-the-Art</ title> <title>Breaking RSA Encryption - an Update on the State-of-the-Art</ title>
<author> <author>
<organization/> <organization>QuintessenceLabs</organization>
</author> </author>
<date/> <date year="2019" month="June" day="13"/>
</front> </front>
</reference> </reference>
<reference anchor="RSAShor" target="https://arxiv.org/pdf/quant-ph/02050 95.pdf"> <reference anchor="RSAShor" target="https://arxiv.org/pdf/quant-ph/02050 95.pdf">
<front> <front>
<title>Circuit for Shor’s algorithm using 2n+3 qubits</title> <title>Circuit for Shor's algorithm using 2n+3 qubits</title>
<author> <author fullname="Stephane Beauregard">
<organization/> <organization/>
</author> </author>
<date/> <date year="2003" month="February" day="21"/>
</front> </front>
<refcontent>arXiv:quant-ph/0205095v3</refcontent>
</reference> </reference>
<reference anchor="LIBOQS" target="https://github.com/open-quantum-safe/ liboqs"> <reference anchor="LIBOQS" target="https://github.com/open-quantum-safe/ liboqs">
<front> <front>
<title>LibOQS - Open Quantum Safe</title> <title>LibOQS - Open Quantum Safe</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date/> <date year="2025" month="November"/>
</front> </front>
<refcontent>commit 97f6b86</refcontent>
</reference> </reference>
<reference anchor="KyberSide" target="https://eprint.iacr.org/2022/1452" > <reference anchor="KyberSide" target="https://eprint.iacr.org/2022/1452" >
<front> <front>
<title>A Side-Channel Attack on a Hardware Implementation of CRYSTAL S-Kyber</title> <title>A Side-Channel Attack on a Hardware Implementation of CRYSTAL S-Kyber</title>
<author> <author fullname="Yanning Ji">
<organization/> <organization/>
</author> </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> </front>
<refcontent>Cryptology ePrint Archive, Paper 2022/1452</refcontent>
</reference> </reference>
<reference anchor="SaberSide" target="https://link.springer.com/article/ 10.1007/s13389-023-00315-3"> <reference anchor="SaberSide" target="https://link.springer.com/article/ 10.1007/s13389-023-00315-3">
<front> <front>
<title>A side-channel attack on a masked and shuffled software imple mentation of Saber</title> <title>A side-channel attack on a masked and shuffled software imple mentation of Saber</title>
<author> <author fullname="Kalle Ngo">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Elena Dubrova">
<organization/>
</author>
<author fullname="Thomas Johansson">
<organization/>
</author>
<date year="2023" month="April" day="25"/>
</front> </front>
<seriesInfo name="DOI" value="10.1007/s13389-023-00315-3"/>
<refcontent>Journal of Cryptographic Engineering, vol. 13, pp. 443-460
</refcontent>
</reference> </reference>
<reference anchor="SideCh" target="https://eprint.iacr.org/2022/919"> <reference anchor="SideCh" target="https://eprint.iacr.org/2022/919">
<front> <front>
<title>Side-Channel Attacks on Lattice-Based KEMs Are Not Prevented by Higher-Order Masking</title> <title>Side-Channel Attacks on Lattice-Based KEMs Are Not Prevented by Higher-Order Masking</title>
<author> <author fullname="Kalle Ngo">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Ruize Wang">
<organization/>
</author>
<author fullname="Elena Dubrova">
<organization/>
</author>
<author fullname="Nils Paulsrud">
<organization/>
</author>
<date year="2022"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2022/919</refcontent>
</reference> </reference>
<reference anchor="LatticeSide" target="https://eprint.iacr.org/2019/948 "> <reference anchor="LatticeSide" target="https://eprint.iacr.org/2019/948 ">
<front> <front>
<title>Generic Side-channel attacks on CCA-secure lattice-based PKE and KEM schemes</title> <title>Generic Side-channel attacks on CCA-secure lattice-based PKE and KEM schemes</title>
<author> <author fullname="Prasanna Ravi">
<organization/> <organization/>
</author> </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> </front>
<refcontent>Cryptology ePrint Archive, Paper 2019/948</refcontent>
</reference> </reference>
<reference anchor="Mitigate1" target="https://eprint.iacr.org/2022/873"> <reference anchor="Mitigate1" target="https://eprint.iacr.org/2022/873">
<front> <front>
<title>POLKA: Towards Leakage-Resistant Post-Quantum CCA-Secure Publ ic Key Encryption</title> <title>POLKA: Towards Leakage-Resistant Post-Quantum CCA-Secure Publ ic Key Encryption</title>
<author> <author fullname="Clément Hoffmann">
<organization/> <organization/>
</author> </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> </front>
<refcontent>Cryptology ePrint Archive, Paper 2022/873</refcontent>
</reference> </reference>
<reference anchor="Mitigate2" target="https://ieeexplore.ieee.org/docume nt/9855226"> <reference anchor="Mitigate2" target="https://ieeexplore.ieee.org/docume nt/9855226">
<front> <front>
<title>Leakage-Resilient Certificate-Based Authenticated Key Exchang e Protocol</title> <title>Leakage-Resilient Certificate-Based Authenticated Key Exchang e Protocol</title>
<author> <author initials="T." surname="Tsai">
<organization/> <organization/>
</author> </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> </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>
<reference anchor="Mitigate3" target="https://eprint.iacr.org/2022/916"> <reference anchor="Mitigate3" target="https://eprint.iacr.org/2022/916">
<front> <front>
<title>Post-Quantum Authenticated Encryption against Chosen-Cipherte xt Side-Channel Attacks</title> <title>Post-Quantum Authenticated Encryption against Chosen-Cipherte xt Side-Channel Attacks</title>
<author> <author fullname="Melissa Azouaoui">
<organization/> <organization/>
</author> </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> </front>
<refcontent>Cryptology ePrint Archive, Paper 2022/916</refcontent>
</reference> </reference>
<reference anchor="CNSA2-0" target="https://media.defense.gov/2025/May/3 0/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF"> <reference anchor="CNSA2-0" target="https://media.defense.gov/2025/May/3 0/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF">
<front> <front>
<title>Announcing the Commercial National Security Algorithm Suite 2 .0</title> <title>Announcing the Commercial National Security Algorithm Suite 2 .0</title>
<author> <author>
<organization/> <organization>NSA</organization>
</author> </author>
<date/> <date year="2022" month="September"/>
</front> </front>
</reference> </reference>
<reference anchor="LattFail1" target="https://link.springer.com/chapter/ 10.1007/978-3-030-17259-6_19#chapter-info"> <reference anchor="LattFail1" target="https://link.springer.com/chapter/ 10.1007/978-3-030-17259-6_19">
<front> <front>
<title>Decryption Failure Attacks on IND-CCA Secure Lattice-Based Sc hemes</title> <title>Decryption Failure Attacks on IND-CCA Secure Lattice-Based Sc hemes</title>
<author> <author fullname="Jan-Pieter D'Anvers">
<organization/> <organization/>
</author> </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> </front>
<seriesInfo name="DOI" value="10.1007/978-3-030-17259-6_19"/>
<refcontent>Public-Key Cryptography - PKC 2019, Lecture Notes in Compu
ter Science, vol. 11443, pp. 565-598</refcontent>
</reference> </reference>
<reference anchor="LattFail2" target="https://link.springer.com/chapter/ 10.1007/978-3-030-45727-3_1"> <reference anchor="LattFail2" target="https://link.springer.com/chapter/ 10.1007/978-3-030-45727-3_1">
<front> <front>
<title>(One) Failure Is Not an Option: Bootstrapping the Search for <title>(One) Failure Is Not an Option: Bootstrapping the Search for
Failures in Lattice-Based Encryption Schemes.</title> Failures in Lattice-Based Encryption Schemes</title>
<author> <author fullname="Jan-Pieter D'Anvers">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Mélissa Rossi">
<organization/>
</author>
<author fullname="Fernando Virdia">
<organization/>
</author>
<date year="2020" month="May" day="01"/>
</front> </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>
<reference anchor="BSI-PQC" target="https://www.bsi.bund.de/SharedDocs/D ownloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=916626"> <reference anchor="BSI-PQC" target="https://www.bsi.bund.de/SharedDocs/D ownloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=916626">
<front> <front>
<title>Quantum-safe cryptography – fundamentals, current development s and recommendations</title> <title>Quantum-safe cryptography - fundamentals, current development s and recommendations</title>
<author> <author>
<organization/> <organization>BSI</organization>
</author> </author>
<date year="2022" month="May"/> <date year="2022" month="May" day="18"/>
</front> </front>
</reference> </reference>
<reference anchor="PQRSA" target="https://cr.yp.to/papers/pqrsa-20170419 .pdf"> <reference anchor="PQRSA" target="https://cr.yp.to/papers/pqrsa-20170419 .pdf">
<front> <front>
<title>Post-quantum RSA</title> <title>Post-quantum RSA</title>
<author> <author fullname="Daniel J. Bernstein">
<organization/> <organization/>
</author> </author>
<date year="2017" month="April"/> <author fullname="Nadia Heninger">
<organization/>
</author>
<author fullname="Paul Lou">
<organization/>
</author>
<author fullname="Luke Valenta">
<organization/>
</author>
<date year="2017" month="April" day="19"/>
</front> </front>
</reference> </reference>
<reference anchor="SP-800-56C" target="https://nvlpubs.nist.gov/nistpubs /SpecialPublications/NIST.SP.800-56Cr2.pdf"> <reference anchor="SP-800-56C" target="https://nvlpubs.nist.gov/nistpubs /SpecialPublications/NIST.SP.800-56Cr2.pdf">
<front> <front>
<title>Recommendation for Key-Derivation Methods in Key-Establishmen t Schemes</title> <title>Recommendation for Key-Derivation Methods in Key-Establishmen t Schemes</title>
<author> <author fullname="Elaine Barker">
<organization/> <organization/>
</author> </author>
<date/> <author fullname="Lily Chen">
<organization/>
</author>
<author fullname="Richard Davis">
<organization/>
</author>
<date year="2020" month="August"/>
</front> </front>
<seriesInfo name="NIST SP" value="800-56Cr2"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Cr2"/>
</reference> </reference>
<reference anchor="Lyu09" target="https://www.iacr.org/archive/asiacrypt 2009/59120596/59120596.pdf"> <reference anchor="Lyu09" target="https://www.iacr.org/archive/asiacrypt 2009/59120596/59120596.pdf">
<front> <front>
<title>V. Lyubashevsky, “Fiat-Shamir With Aborts: Applications to La <title>Fiat-Shamir With Aborts: Applications to Lattice and Factorin
ttice and Factoring-Based Signatures“, ASIACRYPT 2009</title> g-Based Signatures</title>
<author> <author fullname="Vadim Lyubashevsky">
<organization/> <organization/>
</author> </author>
<date/> <date/>
</front> </front>
<refcontent>ASIACRYPT 2009</refcontent>
</reference> </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"> <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> <front>
<title>Migration to Post-Quantum Cryptography Quantum Readiness: Qua <title>Migration to Post-Quantum Cryptography Quantum Readiness: Tes
ntum-Resistant Cryptography Technology Interoperability and Performance Report</ ting Draft Standards, Volume C: Quantum-Resistant Cryptography Technology Intero
title> perability and Performance Report</title>
<author> <author fullname="William Newhouse">
<organization/> <organization/>
</author> </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> </front>
<seriesInfo name="NIST SP" value="1800-38C"/>
<refcontent>Preliminary Draft</refcontent>
</reference> </reference>
<reference anchor="KEEPINGUP" target="https://eprint.iacr.org/2023/1933" > <reference anchor="KEEPINGUP" target="https://eprint.iacr.org/2023/1933" >
<front> <front>
<title>Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols</title> <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/> <organization/>
</author> </author>
<date>n.d.</date> <author fullname="Alexander Dax">
<organization/>
</author>
<author fullname="Niklas Medinger">
<organization/>
</author>
<date year="2023"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2023/1933</refcontent>
</reference> </reference>
<reference anchor="NISTFINAL" target="https://www.nist.gov/news-events/n ews/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards"> <reference anchor="NISTFINAL" target="https://www.nist.gov/news-events/n ews/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards">
<front> <front>
<title>NIST Releases First 3 Finalized Post-Quantum Encryption Stand ards</title> <title>NIST Releases First 3 Finalized Post-Quantum Encryption Stand ards</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date>n.d.</date> <date year="2024" month="August" day="13"/>
</front> </front>
</reference> </reference>
<reference anchor="ANSSI" target="https://cyber.gouv.fr/sites/default/fi les/document/follow_up_position_paper_on_post_quantum_cryptography.pdf"> <reference anchor="ANSSI" target="https://cyber.gouv.fr/sites/default/fi les/document/follow_up_position_paper_on_post_quantum_cryptography.pdf">
<front> <front>
<title>ANSSI views on the Post-Quantum Cryptography transition</titl e> <title>ANSSI views on the Post-Quantum Cryptography transition (2023 follow up)</title>
<author> <author>
<organization/> <organization>ANSSI</organization>
</author> </author>
<date>n.d.</date> <date year="2023" month="December" day="21"/>
</front> </front>
</reference> </reference>
<reference anchor="HQC" target="http://pqc-hqc.org/"> <reference anchor="HQC" target="http://pqc-hqc.org/">
<front> <front>
<title>HQC</title> <title>HQC</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="BIKE" target="http://pqc-hqc.org/"> <reference anchor="BIKE" target="http://pqc-hqc.org/">
<front> <front>
<title>BIKE</title> <title>BIKE</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="PQUIP-WG" target="https://datatracker.ietf.org/group/ pquip/documents/"> <reference anchor="PQUIP-WG" target="https://datatracker.ietf.org/group/ pquip/documents/">
<front> <front>
<title>Post-Quantum Use In Protocols (pquip) Working Group</title> <title>Post-Quantum Use In Protocols (pquip)</title>
<author> <author>
<organization/> <organization>IETF</organization>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="OQS" target="https://openquantumsafe.org/"> <reference anchor="OQS" target="https://openquantumsafe.org/">
<front> <front>
<title>Open Quantum Safe Project</title> <title>Open Quantum Safe Project</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="CRQCThreat" target="https://sam-jaques.appspot.com/qu antum_landscape_2024"> <reference anchor="CRQCThreat" target="https://sam-jaques.appspot.com/qu antum_landscape_2024">
<front> <front>
<title>CRQCThreat</title> <title>Landscape of Quantum Computing</title>
<author> <author fullname="Sam Jaques">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="QuantSide" target="https://arxiv.org/pdf/2304.03315"> <reference anchor="QuantSide" target="https://arxiv.org/pdf/2304.03315">
<front> <front>
<title>QuantSide</title> <title>Exploration of Quantum Computer Power Side-Channels</title>
<author> <author fullname="Chuanqi Xu">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <author fullname="Ferhat Erata">
</front>
</reference>
<reference anchor="AddSig" target="https://csrc.nist.gov/Projects/pqc-di
g-sig/standardization">
<front>
<title>AddSig</title>
<author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <author fullname="Jakub Szefer">
</front>
</reference>
<reference anchor="BPQS" target="https://eprint.iacr.org/2018/658.pdf">
<front>
<title>BPQS</title>
<author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date year="2023" month="May" day="09"/>
</front> </front>
<refcontent>arXiv:2304.03315v2</refcontent>
</reference> </reference>
<reference anchor="PCI" target="https://docs-prv.pcisecuritystandards.or g/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf"> <reference anchor="AddSig" target="https://csrc.nist.gov/Projects/pqc-di g-sig/standardization">
<front> <front>
<title>Payment Card Industry Data Security Standard</title> <title>Post-Quantum Cryptography: Additional Digital Signature Schem es</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date>n.d.</date> <date/>
</front> </front>
</reference> </reference>
<reference anchor="I-D.irtf-cfrg-bbs-signatures"> <reference anchor="BPQS" target="https://eprint.iacr.org/2018/658">
<front> <front>
<title>The BBS Signature Scheme</title> <title>Blockchained Post-Quantum Signatures</title>
<author fullname="Tobias Looker" initials="T." surname="Looker"> <author fullname="Konstantinos Chalkias">
<organization>MATTR</organization> <organization/>
</author> </author>
<author fullname="Vasilis Kalos" initials="V." surname="Kalos"> <author fullname="James Brown">
<organization>MATTR</organization> <organization/>
</author> </author>
<author fullname="Andrew Whitehead" initials="A." surname="Whitehead <author fullname="Mike Hearn">
"> <organization/>
<organization>Portage</organization>
</author> </author>
<author fullname="Mike Lodder" initials="M." surname="Lodder"> <author fullname="Tommy Lillehagen">
<organization>CryptID</organization> <organization/>
</author> </author>
<date day="7" month="July" year="2025"/> <author fullname="Igor Nitto">
<abstract> <organization/>
<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-signature
s-09"/>
</reference>
<reference anchor="I-D.ietf-sshm-ntruprime-ssh">
<front>
<title>Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlin
ed NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512</title>
<author fullname="Markus Friedl" initials="M." surname="Friedl">
<organization>OpenSSH</organization>
</author> </author>
<author fullname="Jan Mojzis" initials="J." surname="Mojzis"> <author fullname="Thomas Schroeter">
<organization>TinySSH</organization> <organization/>
</author> </author>
<author fullname="Simon Josefsson" initials="S." surname="Josefsson" <date>n.d.</date>
>
</author>
<date day="15" month="August" year="2025"/>
<abstract>
<t> This document describes a widely deployed hybrid key exchang
e method
in the Secure Shell (SSH) protocol that is based on Streamlined NTRU
Prime sntrup761 and X25519 with SHA-512.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sshm-ntruprime-ssh -05"/> <refcontent>Cryptology ePrint Archive, Paper 2018/658</refcontent>
</reference> </reference>
<reference anchor="RFC9528"> <reference anchor="PCI" target="https://docs-prv.pcisecuritystandards.or g/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf">
<front> <front>
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title> <title>Payment Card Industry Data Security Standard</title>
<author fullname="G. Selander" initials="G." surname="Selander"/> <author>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma <organization>PCI Security Standards Council</organization>
ttsson"/> </author>
<author fullname="F. Palombini" initials="F." surname="Palombini"/> <date/>
<date month="March" year="2024"/>
<abstract>
<t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDH
OC), a very compact and lightweight authenticated Diffie-Hellman key exchange wi
th ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and id
entity protection. EDHOC is intended for usage in constrained scenarios, and a m
ain use case is to establish an Object Security for Constrained RESTful Environm
ents (OSCORE) security context. By reusing CBOR Object Signing and Encryption (C
OSE) 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> </front>
<seriesInfo name="RFC" value="9528"/> <refcontent>PCI DSS: v4.0.1</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9528"/>
</reference> </reference>
<reference anchor="I-D.draft-ounsworth-cfrg-kem-combiners"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<front> bonnell-lamps-chameleon-certs.xml"/>
<title>Combiner function for hybrid key encapsulation mechanisms (Hy <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
brid KEMs)</title> connolly-cfrg-xwing-kem.xml"/>
<author fullname="Mike Ounsworth" initials="M." surname="Ounsworth"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<organization>Entrust Limited</organization> hale-mls-combiner.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<author fullname="Aron Wussler" initials="A." surname="Wussler"> ietf-hpke-pq.xml"/>
<organization>Proton AG</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</author> ietf-lamps-pq-composite-sigs.xml"/>
<author fullname="Stavros Kousidis" initials="S." surname="Kousidis" <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
> ietf-pquip-hybrid-signature-spectrums.xml"/>
<organization>BSI</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</author> ietf-pquip-pqc-hsm-constrained.xml"/>
<date day="31" month="January" year="2024"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<abstract> ietf-tls-hybrid-design.xml"/>
<t> The migration to post-quantum cryptography often calls for p <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
erforming irtf-cfrg-bbs-signatures.xml"/>
multiple key encapsulations in parallel and then combining their <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
outputs to derive a single shared secret. 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.9
941.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
528.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
652.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
814.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
794.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
763.xml"/>
</references>
</references>
<?line 1623?>
This document defines a comprehensible and easy to implement Keccak- <!-- [rfced] References
based KEM combiner to join an arbitrary number of key 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> a) FYI - We note that draft-hale-mls-combiner-01 has been replaced with
</abstract> draft-ietf-mls-combiner-02. Should this reference entry be updated
</front> accordingly? Note that the title has changed.
<seriesInfo name="Internet-Draft" value="draft-ounsworth-cfrg-kem-comb
iners-05"/>
</reference>
<reference anchor="I-D.irtf-cfrg-hybrid-kems">
<front>
<title>Hybrid PQ/T Key Encapsulation Mechanisms</title>
<author fullname="Deirdre Connolly" initials="D." surname="Connolly"
>
<organization>SandboxAQ</organization>
</author>
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>Cisco</organization>
</author>
<author fullname="Paul Grubbs" initials="P." surname="Grubbs">
<organization>University of Michigan</organization>
</author>
<date day="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> Original:
</abstract> [I-D.hale-mls-combiner]
</front> Joël, Hale, B., Mularczyk, M., and X. Tian, "Flexible
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-hybrid-kems-0 Hybrid PQ MLS Combiner", Work in Progress, Internet-Draft,
5"/> draft-hale-mls-combiner-01, 26 September 2024,
</reference> <https://datatracker.ietf.org/doc/html/draft-hale-mls-
<reference anchor="I-D.ietf-hpke-pq"> combiner-01>.
<front>
<title>Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms f
or 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> Perhaps:
</abstract> [PQ-MLS]
</front> Tian, X., Hale, B., Mularczyk, M., and J. Alwen, "Amortized
<seriesInfo name="Internet-Draft" value="draft-ietf-hpke-pq-01"/> PQ MLS Combiner", Work in Progress, Internet-Draft,
</reference> draft-ietf-mls-combiner-02, 20 October 2025,
<reference anchor="I-D.draft-connolly-cfrg-xwing-kem"> <https://datatracker.ietf.org/doc/html/draft-ietf-mls-combiner-02>
<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 &amp; 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/tra
ditional
hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML-
KEM-768.
</t> b) The URLs in both of the following reference entries point to the same
</abstract> URL. Should the URL for [BIKE] be updated to something else? We do not see
</front> BIKE mentioned at this URL. Note that we found the following page for BIKE
<seriesInfo name="Internet-Draft" value="draft-connolly-cfrg-xwing-kem (Bit Flipping Key Encapsulation): https://bikesuite.org/.
-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 arbitra
ry 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-DSA Signature Algorithm in the Cryptographic M
essage 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="Kampanaki
s">
<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 do
cument
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> Current:
</abstract> [BIKE] "BIKE", <http://pqc-hqc.org/>.
</front> ...
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-sphincs- [HQC] "HQC", <http://pqc-hqc.org/>.
plus-19"/>
</reference>
<reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology">
<front>
<title>Terminology for Post-Quantum Traditional Hybrid Schemes</titl
e>
<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>
<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> Perhaps (update URL for [BIKE]):
</abstract> [BIKE] "BIKE", <https://bikesuite.org/>.
</front> ...
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-t [HQC] "HQC", <http://pqc-hqc.org/>.
erminology-06"/>
</reference>
<reference anchor="I-D.ietf-tls-hybrid-design">
<front>
<title>Hybrid key exchange in TLS 1.3</title>
<author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization>University of Waterloo</organization>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Shay Gueron" initials="S." surname="Gueron">
<organization>University of Haifa and Meta</organization>
</author>
<date day="21" month="July" year="2025"/>
<abstract>
<t> Hybrid key exchange refers to using multiple key exchange al
gorithms
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> c) We updated many of the reference entries in the references section to
</abstract> include titles, URLs, and additional publication information that may be
</front> helpful for future readers. Please review and let us know if you have any
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design- concerns or corrections.
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="Mike Ounsworth" initials="M." surname="Ounsworth">
<organization>Entrust Limited</organization>
</author>
<author fullname="John Gray" initials="J." surname="Gray">
<organization>Entrust Limited</organization>
</author>
<author fullname="Massimiliano Pala" initials="M." surname="Pala">
<organization>OpenCA Labs</organization>
</author>
<author fullname="Jan Klaußner" initials="J." surname="Klaußner">
<organization>Bundesdruckerei GmbH</organization>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<date day="7" month="July" year="2025"/>
<abstract>
<t> This document defines combinations of ML-DSA [FIPS.204] in h
ybrid
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> <section numbered="false" anchor="acknowledgements">
</abstract> <name>Acknowledgements</name>
</front> <!-- [rfced] Acknowledgements:
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite
-sigs-07"/>
</reference>
<reference anchor="I-D.ietf-lamps-cert-binding-for-multi-auth">
<front>
<title>Related Certificates for Use in Multiple Authentications with
in a Protocol</title>
<author fullname="Alison Becker" initials="A." surname="Becker">
<organization>National Security Agency</organization>
</author>
<author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
<organization>National Security Agency</organization>
</author>
<author fullname="Michael J. Jenkins" initials="M. J." surname="Jenk
ins">
<organization>National Security Agency</organization>
</author>
<date day="10" month="December" year="2024"/>
<abstract>
<t> This document defines a new CSR attribute, relatedCertReques
t, 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> a) Would you like the cite the draft here? If so, please provide the
</abstract> draftstring so we can create a reference entry.
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding
-for-multi-auth-06"/>
</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 version 3 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> Original:
</abstract> This document leverages text from an earlier draft by Paul Hoffman.
</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 s
ecurity
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> b) Would you like to include a surname for "Florence D" and "Ben S" rather
</abstract> than just an initial? If so, please provide the surnames.
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-hybrid-signa
ture-spectrums-07"/>
</reference>
<reference anchor="I-D.ietf-pquip-pqc-hsm-constrained">
<front>
<title>Adapting Constrained Devices for Post-Quantum Cryptography</t
itle>
<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="Kwiatkows
ki">
<organization>PQShield</organization>
</author>
<date day="4" month="July" year="2025"/>
<abstract>
<t> This document offers guidance on incorporating Post-Quantum
Cryptography (PQC) into resource-constrained devices, including IoT
devices and lightweight Hardware Security Modules (HSMs), which
operate under tight limitations on compute power, memory, storage,
and energy. It highlights how the Root of Trust acts as the
foundation for secure operations, enabling features such as seed-
based key generation to reduce the need for persistent storage,
efficient approaches to managing ephemeral keys, and methods for
offloading cryptographic tasks in low-resource environments.
Additionally, it examines how PQC affects firmware update mechanisms
in such constrained systems.
</t> Original:
</abstract> This document leverages text from an earlier draft by Paul Hoffman.
</front> Thanks to Dan Wing, Florence D, Thom Wiggers, Sophia Grundner-
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-hsm-cons Culemann, Panos Kampanakis, Ben S, Sofia Celi, Melchior Aelmans,
trained-01"/> Falko Strenzke, Deirdre Connolly, Hani Ezzadeen, Britta Hale, Scott
</reference> Rose, Hilarie Orman, Thomas Fossati, Roman Danyliw, Mike Bishop,
<reference anchor="I-D.hale-mls-combiner"> Mališa Vučinić, Éric Vyncke, Deb Cooley, Dirk Von Hugo and Daniel Van
<front> Geest for the discussion, review, and comments.
<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 tradition
al 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 and Digital 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 seed PQ
guarantees into an MLS session 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> <t>This document leverages text from an earlier Internet-Draft by <contact fulln
</abstract> ame="Paul Hoffman"/>. Thanks to <contact fullname="Dan Wing"/>, <contact fullnam
</front> e="Florence D"/>, <contact fullname="Thom Wiggers"/>, <contact fullname="Sophia
<seriesInfo name="Internet-Draft" value="draft-hale-mls-combiner-01"/> Grundner-Culemann"/>, <contact fullname="Panos Kampanakis"/>, <contact fullname=
</reference> "Ben S"/>, <contact fullname="Sofia Celi"/>, <contact fullname="Melchior Aelmans
</references> "/>, <contact fullname="Falko Strenzke"/>, <contact fullname="Deirdre Connolly"/
</references> >, <contact fullname="Hani Ezzadeen"/>, <contact fullname="Britta Hale"/>, <cont
<?line 855?> act fullname="Scott Rose"/>, <contact fullname="Hilarie Orman"/>, <contact fulln
ame="Thomas Fossati"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="
Mike Bishop"/>, <contact fullname="Mališa Vučinić"/>, <contact fullname="Éric Vy
ncke"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Dirk Von Hugo"/>,
and <contact fullname="Daniel Van Geest"/> for the discussion, review and commen
ts.</t>
<t>In particular, the authors would like to acknowledge the contributions
to this document by <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.)
<section numbered="false" anchor="acknowledgements"> Instances in document:
<name>Acknowledgements</name> 2^{64}
<t>This document leverages text from an earlier draft by Paul Hoffman. Tha 2^c
nks to Dan Wing, Florence D, Thom Wiggers, Sophia Grundner-Culemann, Panos Kampa 2^{(128−c)/2}
nakis, Ben S, Sofia Celi, Melchior Aelmans, Falko Strenzke, Deirdre Connolly, Ha 2^64
ni Ezzadeen, Britta Hale, Scott Rose, Hilarie Orman, Thomas Fossati, Roman Danyl -->
iw, Mike Bishop, Mališa Vučinić, Éric Vyncke, Deb Cooley, Dirk Von Hugo and Dani
el Van Geest for the discussion, review and comments.</t> <!-- [rfced] Please review the "Inclusive Language" portion of the online
<t>In particular, the authors would like to acknowledge the contributions Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
to this document by Kris Kwiatkowski.</t> and let us know if any changes are needed. Updates of this nature typically
</section> 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-l
ibrary/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. -->
<!-- [rfced] Abbreviations
a) We note that KEM is expanded in the following ways in this document:
key encapsulation mechanism (KEM)
key encapsulation method (KEM)
key establishment method (KEM)
Should the latter two (one instance each) be updated to "key encapsulation
mechanism (KEM)" (most common in document) or simply "KEM" (as the
abbreviation was already expanded)? Or should these be handled in some other
way so that the expansion of KEM is consistent in the document?
b) How should "MAC" be expanded? As "Media Access Control (MAC)", "Message
Authentication Code (MAC)", or something else?
Original:
It is crucial for the reader to understand that when
the word "PQC" is mentioned in the document, it means asymmetric
cryptography (or public key cryptography), and not any symmetric
algorithms based on stream ciphers, block ciphers, hash functions,
MACs, etc., which are less vulnerable to quantum computers.
c) We have updated the expansion for "AEAD" below as follows. Please review
and let us know any objections.
Original:
HPKE [RFC9180] works with a combination of KEMs, KDFs, and
authenticated encryption with additional data (AEAD) schemes.
Current:
HPKE [RFC9180] works with a combination of KEMs, KDFs, and
Authenticated Encryption with Associated Data (AEAD) schemes.
d) How should "BIKE" be expanded? As "Bit Flipping Key Encapsulation"?
Original:
Examples include all the unbroken NIST Round 4 finalists: Classic
McEliece, HQC (selected by NIST for standardization), and [BIKE].
e) We have added expansions for the following abbreviations upon first
use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Security Association (SA)
Trusted Execution Environments (TEEs)
Hash to Obtain Random Subset with Trees (HORST)
Hashed Message Authentication Code (HMAC)
Internet of Things (IoT)
Payment Card Industry (PCI)
-->
<!-- [rfced] We see both of the following forms used in the document. Should
these be uniform? If so, please let us know which form is preferred.
hash-then-sign
Hash-then-Sign
-->
</section>
</back> </back>
<!-- ##markdown-source: <!-- ##markdown-source:
H4sIAAAAAAAAA+S96XIbWZYm+J9P4cWwtiI7AXDVQsVkd1EUFaJpCYagyKiZ H4sIAMKl72kAA+y92VYjWZYg+q6vsCZWr4QumQAxOJAZGYUL3CHdcccRkZF5
6WmlA3CQngTcEe4OMhBMjeXP+T31Y6zNep5m3iSfZM53lrs4HJSUmZ1V3a3M a2V7mKQjyRKTmcIGcAXp93fu6pf+ifqx3tOZTCYBEdHVeXuVV2UAktkZ9tln
kEjAl3vPvffs5zv9fn+ryZtZ9izZvizrpv/DMi2a5Tw5q1aLpryq0sX1KpmW z0MYhq0yLhN1EmxcZ0UZfqqitKxmQS9fzMtskkfz6SIYZ3lwnk7iVKm82GhF
VXJeXOVFllX19lY6GlXZLe744az93ThtsquyWj1L8mJabm1NynGRzunxkyqd g0Gu7vGNT736d8OoVJMsX5wEcTrOWvE8PwnKvCrK7s7O8U631RplwzSawXyj
Nv08a6b9xc/LfEF/j/uZ3dif0X11s1UvR/O8rvOyaFYLuuvi/MPLrWI5H2XV PBqXYazKcTj/qYrn8N9hqPRI4e5+q6gGs7go4iwtF3N44/L89k0rrWYDBYMe
s60JXfNsa1wWdVbUy/pZ0lTLbIsGcrSVVllKAxpm42WVN6vtrbuyurmqyuWC Hx8ctUYw20nQ3ekehjv7rWGWFiotqoKmVC1Y4l4ridLJSaDS1jw+Cf6tzIbt
h/njxeX21k22ok8nz7aSfkIj39raus2KJT0xSexKHtk2fSBv3/6JnpIXV8l3 oFjMcjUu4JcsL/G3v7WiXEUnQf+813rI8rtJnlXzk4CW1bpTC/hsdNIKwgA2
+B6fz9N8xteN/wlTGZTVFT5Oq/E1fXzdNIv62d4ersJH+W02sMv28MHeqCrv 3Gq1ijJKR5+jJEth8oUq3KFlRHeSMo+HZTsYZrOZSkv4BEAwi+bzOJ38rdWK
6myP7t/bpgHUTVpMPqazsqC3rbJ6a5E/S/73phz3krqsmiqb1vTTaq4/NFU+ qnKa5Th6K4B/4ypJGD6neVzmUfA6SlX+d6Xo2yyfRGn8c1QCTE6CD9ldHNHn
bnrJuJzPs6KhT4i683SxoCH+H1tb6bK5LitMj0aUJNPlbCakPyWSVGnyPC2y w7gEiL/P0lGW8gdZlZZ4Ct+ncalGwTuYbJTN6Ds1i+IETi+iCToDmeBfUxyu
6g9Zxt/SiNIi/zVtiNTPknflTZ7y52Oi3rPkTVlMykI+KJdFg/X8scibbJK8 A8vcWF7MbZxXsyhRxUOUBzdqNFp03j1jRbD4CcAp59XnakJPvYvyNCqju8hf
ppdNyjl/lyk5Un7BYKQv+KcCjxvQMLfXB/Mhr5bzdJbVd2mVvM8mk9UXjIeG 6mU6kpf1Cu86pTPv5xznXbvMs3gGe4qzIugPp1mcxlEa3cXFM1Z6Wk4BdfwF
fkVUqmTsVXbFV71OqyJt0ps0HuhFMdGbbXw3gyZ468cKb31wkC/yOc0oL+tk vc2VGipvRSM9QadwJ+BFhQOVJGESDYqVUJxlJdyniyxJ1ECpu4aFncWTuKfy
OL4u8yJPi/Qmr79gpKfNNW3OeEDfVVk2zqIRTewFgzp8gQyqP8pmMzoRo3oj 0lnbdVyWxaDKJ1MPjNenjUfdL+FSFEE2Dk5nClDPB2kZzzpTPf2/jmCyIUzm
DedlQ+fyVTmbZaMsu+kY2Iv8Kj/LqiYY22XeNPVoWV1dt1Z2eBoNrsnng2t7 rTdO4QJddYKPVVoA5pc8K+/gKr5TtS9g+SdAAeiSB+8RPmpEX2gyId/RZ3AZ
9D9N6EFjelA0lryg4/d2kHy/LGo6VI08UUb3Nr/JWl/Q0J4Rl6DzWjfJG8w9 lCrhyh7s7AT9DC7nqAxusmjUDvoVvBns7uw4O/9YltFD1A4+piVga+bvtwew
m/AXxkr0O/6MtnmWNc+Sw0f7+8mwnNERaZL3ZTpJ/vynf0mGS7o5OdjfDyb2 H2kcGsHi3nXfBXtvD9z9zmC9nUyv918VLwW3C/c4zfIZQP1ewe0Lrt6H786v
fdOkd2kv+b5oaCuW8ezOiLQT2yITGt/rw9fJ0XePwinPaciD0ob8T5mMBjOm TuhlTRGvslGVqPB9VJYApvB1VOBVUovwPB1G86JK6MyCKzWcwgkWM4R9Oory
Q1qU1ZyIesuc4u2b/uvzt8/45sQ458uLy2H/cP+I5l5OlrOs/yZtGiJaf5TW 0QYPE+UT3Oy0LOfFyfZ2ep/MK0AOeLTsTLL7bfwFP9l+c3nd3/5w2b/t4G+d
ODLZqn9ejNNFvZzx6iRvs/E1rVU9T4bgAGk12dYnptUV5m6cpLidLZa0D+ja 7s5eZz4aM8TgDFWBxJTXhv/wyQCfRNq3Zz4++3h5AgDsHO50j2jszjieFx39
ZnBV3u7hB3yyh3fuvbsYfhjgpwG9fbCYTOUpzCiTaTqrMxnyi+Fp95CP14b8 iKE09C80r9EB4pD0iSGp++HOEcPlrH8qb60FDGJuGSVBP57A9a5yVQPHr4HH
nIeM3dOks2SYX9ERW1bZ33Cgx5sGOnzzavNIHz3DEJqMznCdvErr67/DSB9t voHH0gKbYeSBaF9/6kHIG5+f8EHkwMgDUv/9RQNM6N4BpSqCi6iY/gfA5OBX
HCkx2lrG6aXnbFWU8zyd9en8ZEk6IzGYN9fzmkXkosKH03Tc0KdyRhMaZjLJ weTgSZgcvAgm8Ezh357rLFmk2SyOkhAInwpOExAM4nI6K0houM7xwzfRsIRP
63GV0Y6elVepXo+vkp9VENMeXCybrJLZtCeTVr/ktyxeaKR7fE9/cb138mj/ mfoFABoAWTHMFZCC99kkkufxq8CIJtlsXpUqb75kUf4lvu/A0rYBOts/4Tvh
6f7hE7qFJNdt1h7rKQ2EDqK9Yi67cUxUdKPmQdOkU2zhpM4gvbqHMJkN0vGc fLp9fLBztNN9tfYiWEJ9DfPnwQ8d2pb5ngjjtfMhMHiQOUqgKifBH+WxKP9L
xzAp872D/cHBwfGjvcOjJ08Pjgf45/FjuvH92sKe0jEgiTXhV30/alJigyRr fH9Sn/e+61yu3eNjkFd2wy5C+G2e3as66E6DcQTU9CfZ8YwJzBAQKdJAJBjC
1xa0ZkJdLkezfNyns6S6Sb2qm2xe/2bDMreGBfLY0I4enRwd7w/4n8Ou5X3/ eNEAEA1OO8qH02aIjJJONJwRSEZZvA1Hvbu7f7Dd3Xt1tLvfwR+Hh8+Ey/vs
8uzx/sn+M/nx6dHJgf346NGx/Xh8/Fh/PN4/4k/ffXj/Y0xofNJNNXAYHlxe LnjXkTUv7egVbGolXPq3H3vB744PAYJ5NlRqBBIJcSlgvEH5AM8uQhVPpuUU
TLJfBvV1M5/RhS+rclI6BuOOgH7a/agpvr3JZK50xdksJQ1q/HZ8PstJ7sSP sCCtYKunvSuUouZZEQMMAAVupwokS3yHUQBGaAfzeSfo7nbD7u7xCnqpEbxx
0i8T+7b7kWO5ajAfZ3yVPfrlu64Dir30siTFK6uSWcT5sHlpyye1X0tsx8TT 1zdL9/gU6DnAYUQA/jgoI+Dy6WT5JheErdfVIImHITAFEZmLRVGqWbHietfO
ZX026Yw0vD7uGECF3PuCBTo8evSMGDUud6za7f2+bN7WoM8Gyf+Wzm5IaPz5 AlFUr2zv4Hhvf6dDP7pPXT17JDdZGiWj4H0nuAFOJmzWf5jw9hTxNprF+aoH
T/9VLvzzn/5L7c6E3IT96I9ETqNf0OFOZ70//+n/TS6vVzUfmvfZbZ7dJae9 YITTUQJ8M3Vpyhs1yKsIoL57/EooS9Pp4onMKkRRvMfmXOEI28F9luARtYM0
5LacDZLH+71ksRgkh0+OH/cPnzw66CUHJycng3jCXdP6cE1qbNN/ny1IDLUG g598YrvdnXC3e7iSVHln5kMGD+1N7xC0iRP+9WjveFf/enCwr3/d3z+UX/d3
bIq5XAMVgJamyBK5ODncP9zfQNGrWTlKZ1Vekypb0+OImwjH4BPFrKje03n3 9uBT+P3D7c33/kXDT1Ywa5AU6JzidKS+dIppOUscjB9HSYGi4Zs8G2VLgoP+
GxlCo4/vV/z4Ph7fuRI/nPVfvBtuGOsZ8y4mIp1g0owSunbDKO/u7gY0mqLg tHnoMX57pxgNGsbsJRFoPcOr4XkSgwDqDy1fBvrb5imG/FRnNlT01Kqp3nxo
sZXEJ/v7RwdkIWziwWDUrfdutmBMJijr3TCGcV2NvVxYVOUfsnFT7y3wWCPQ 4GRvTt/3Pn6As0ca9Car4HTyIBFePyC+BgLUHCh3UNjbgCQhsPBc3nWUANqE
OHjs5m/6dfzCrgmczcrlZEqGQtaaBmbGm3Exy9KaHp6E70nqZUXSpM42TGJE +EYHz3rbRTNez/LRdvcO4ORa+Lwjq/UBYbKqCOnG1dkwf+cpsO2gC1f1fBQj
kmQwds+GEsMirh8N1h7Suahnw/2D1pheZDiRvI6nRTqjnU+HYZpcVnS8+RAE cm48/279SUVpeD2Nk3g+B2QGTaQoMu96nFYTFHuR8y5fjsv+6w8BXJvdV7tH
/Jl0HZACIo7U52xOp54NMxKKVyn2YHI6SRc4psnZdUnGXHKWL65Jxcx+oa9I Bzt7R/uvDL0P+0Swa2vn735XGMLPZB3Jj6X7MYB6DmJ8lKwAdBKndx0QT32K
lxvfbJhbRmMumkGejiveJof7+wfE1p92TeL5q9f7J61ZDJcj+qHJaUR5IRsy v7O3fT1dFDfq/hRYfaf7av/w+YDoTXMQQ+BS/z9RImqbAOAjsG/Qx5EDHC9D
m5LY4bHSdC7eveifnZ0+S34iLZ4n+6q8g7RfziY01pR04uIq67/I3ARH9Ii8 AGcktgXTxuohOBVqcLjD1GBf6DcsJuy+Oth9Bj1o3sftFBT4MrxRc5Dza1DV
pi/Ku2zyH7982Cd7xwedw/7u7funT9ck5USFomOkSc2UJT4VETY1wo6ZsH2i cgM/g0oY3IlUBfwwnt3OCkhOkmwQJbD1O6CQMBxIHSxZENFnUrctZxWWvIRS
fZ1e0fdM1XqwYYCLrKS9NhjXpA0PSDsfZJPlXp3PbvNyb0gq15j09X93uD8c hg9zGj7E4befD+mreDgFKTK4ygrR3FY+CaiRgW4IgsEy4N/SyoElFHegV8va
56Qa59N8TL9cpgtSLPZUXONbx+T3Tj/qxx/dhx9lK3yUnfDxVAb80XbCR9kJ a7LiLskgiJOfeuHZh/4KsBleS/wOqTo8uwJgDw8PHQBMmhKYMsCNcGdvN1Sp
/bcy4I+yDTadfTLfTy8v2qf/hzOy7OnzpCibrP6iM342fH+2N8/IYNy7tOMe FVWfA4TrqEpASR6Pa8yIBdz9sNttuGy90w8fgo/jMRApzX5601iNg1uQntIs
cpF+yEVIkRgv2fLey35J50Sx/jQnfXQvXeR9fuem8ZLy8/TV+zabxN5qSlUK ySYL+ToHhbJ3+xGXRnIZirC1za+2hWn5XUTWFYAYFvnQyvDzPPu7GpbF9hyH
iYMfP01GeYOLaXc22RWRF9v0aUL7j35c1uCkh/tkrcxm2HtFmdcrklh006bZ 1QgzdIZd/U1Y+BO+RCgPljlLVo3GSZSr2n7xBaA780RFBawhcJcTFFU+h0ug
ev2QrMm9gxNSafdPnhyfbBjkwf7wrDXI5yQP2AeCYQUnu0/HI/lxgUdAYcVZ Vux1AKDtDM3IqFyT1hJ6e9KDvOAugAoV/AAijcoH0RIidEnebBBJ7B6D17Ay
Yv28X05JiGT906p5gNP/vMQMa1px0jDU0GXOtTfS9/WrOiXub+/rL/lV4Kv0 3HV/Z7e23zOFfIgw+hTkJ6BSJLNc58DUiGA5ch0o+3geqJ/04XLOgNf11RB1
d6p27foMhuICiUR9Xo3JaGQ1E18za/VSXcla/OboS0kZqdokGB/tn2y0FN5c uWgSIWEAuSmaI28ChMsKlQa9eD5Veam+wFdlGQ3vVkBOAUTSshNHw5wuTHdn
PP/+h/bCv8lH9CGR8PsFsRkTWMN0uomn01m6Xo6YSCXd4rk43bI3y0flz3XX Zxeo9dGLpb9eDn81SXb2yT/HqGih7lLNfVCK0O4DkTCQ7oy6xkUGp8iI7lUb
y1+vRlk1zCdtAXOa4MM+MbSiyGbKcsXseEUy647ERnKB/Y3NnhpzPHv/vw4/ Lucc6L2z1NcX73aO61y4GsAvJZBxEC6ZaKgxCNIERQD05YezsNc7PQl+mCo+
nL4Z9vmxX8zqDg/3SOnu1LOH6abx1RjfWMeXBuObp/UNKZZgzfX1cjqd0S91 hovsgRaHu5lGSaLSiQrPlAH9QKFmCF9kD2r03fMBery9v/sCgF7F0zgPXqsE
OW14zPnamPkNG4ZK+s3NoMZ46aQxbWlb5eNZxobC/v6Tvfrg6OjpSX//8Ki/ EWjtk2cqBSxHMjVVcfrz2mfP0Wz2Lk7Kn2ugb+CZzwG93tTbq5ujoyX9ZSSq
T8rIo/5R5yxorGdt/bKDwGzYxWY26fR1ckojf1c2JEuzWxo7fTxaJa/yK5KI ihHOgoLwFhirh7aRRtshoW0ImF1EE/iecHaVCjNXGZCJzrCI4qQzi8uOGlXb
/e+rCanLb1PobldfQ/KTg84zrq/voPl3WZFVZBgM1ynPAyex2FdhE+v4l6/P RZzcx9l2H1jXsFSj/9rd6Q9j2E4M9Bb+oIUX26JD4bdGbtw+/SwffzYffuZ7
eTloLiqUNp2g9YEenOydHHeKwbckk6/ok7Yecvn9m9cknz+UtOCTOnlDzILE 9pmv2edTXu9nfc0+8zULr3i9n/mOvYzFgC40joO3WTJ6AKHuibvTp90hb46S
BanMpJA0UJViHZAGraqH6CdJrJ98DUWfPulcfRvoYfuMByObQWwm8MZBdoKB +BdoYyIrAnImICgdNRCt/uXpVfAnELXhdVR1HQWXBKbdV5761D3aDffWWHqs
yfKfLuEtbPijiQztF5CeBDZJo6Ycl7MNI8yzLPtlAY/oAD+qmSvSae+EzNTD uLT3ahs4/audXeTz1596p9eXdVb3qReEAXwOE5Rq1an7DK3Xv+ltz0CHj7av
w8cPjfboIc05HlbA803LUFkdaG1d2/3rtmvncM/eDU8P+/tt9lAU5bIYg21D NW9zWWboskyQQYcVuT621ZdoBsgTjuMETj6axyHN+ZyjW8vXQIs/uripSzBI
7JzBHV6Nc1KP3vHBh/NAAwHJqePz4jg8HGwyk1gLGEyyaVbUGSsHNLJHe2/T UsoMHiLK193ZPwoGcYkPA1Eq1QRQEqnTUQBkB36tChRyujvBLE4SJDlpFhcL
1d7RPlS2oyeHT58cH+z1+f/7pDucfsQAP9IzP56++e779xcfXr0dDi5fvNx0 kMXhpVVgsdamaFBs7x7vHHR2jl/tH79AtM6jeBK8jUepWjwl7wFCBOd3Ko98
9F6SfrWuWTv64mvs1YBfqEZqCnTMPoYPHrd1/kZ7a9FkleNvJ0+e9om1He33 KoKS3H64u7eMVmyMssu632Ng7e70ezVgvQbp9Q4BgOBxWF4I1Dn4fo5zIWIi
D54cPjrpP/54cPKNXtTn+M0D82hv+J3vi2zXTeGiZp5GOsL3C3FIPy/Lpm4q KSdLZ5iNQeRV4WlerhEGf6oQ0nDBUlBExTFCAsP2QOYL8yICAVHPF1Y0FUo9
CVeIvsA2NstlvY31nXiO68bEJiX2a+Z7/OjJ4ZP+0ceDTstheNEnZbLbqGWZ 8N9I/CB1SBIyfHLGfg9j+0DZPQ53DhkosKO+fdso0nE+rAAdxswVUe2ySpbg
m4S2Hrulp0sy91j0zOpeQmtV4chPiKPPygXrjMwkq0yCNxMxux/QkEZ1PhjR Qvove889f8/aCDL/wc7xwQtJUqnm0wgUk9cqArI3AZmvxi32wh00dK065/r0
Q2lH7g2vSbpNXpRjUrfLu2JWppN67/zdHg107zK04p9X5fia6LgXKgiRYTqA dNrvL19//FS/Ge/jAXwIZ/txDuxXy7n9aLxKxgMCPa0GdHoZvGKlOngFFM5B
o+k/FsVv6cQ9jnnEwdMBqYc4jqxhrzvsLkMrlL7epGFXg9Vi0JR7C7EQFj9D 9pMH/g+gx6KbFpHzYHm56AoFyB+/Gh8OjlB9e7eAh/vxqC6Wngb4YQgCQZqq
lSNm/2T/+OCkrSjh88H+8YDl1fCy/3R/v//ocZv47yO68ZaBV/0Fiaxbc6nD RIQptgZfAHgeUMi7RIqC5CXSwkXv5q/929P3/ZCGfbao0O1u7+4fvMD09ldY
l8gbiP3tJA2IMPU1aP+Zg7LZIzxcZOArEY3ZQTy8HOhAq8ONqt9q6QxQN5Hf FaLJn57gCVX8swp+iNLJ2sfeodATfJhk6yUJEIyi4Kwa5Nn9ev3wfZxWBcjQ
DfA5Sc7r7La+WbH76WWeNn1a43leJT8Rr0pOR2XV1M+S08XCvReWgp4M3kkv w7ukSmuY1KRAPUPusBDqR6sOrMADG8qBRc6BzaLiTo1I1ium1XicwB9FNi7p
xZVMirLyAmd90RN7yenw4pQUtssPCYzNbRtFl9PFGLFGLPfSGh/RlmEz9dHJ EOOlQ6QZ1lk4CjxAoOGElEgbh4kiU8fOzqvtYndv7wgoQBeuDKh5B+He84/1
AWm4J4/dD366bT3osn8Aohw9PWvP+m1Ou4+XiWax2UtjH77P0klekHnwzD4K tz6I22kGewfuDkCp24+6tML9sOmWGHFg7Gqg8dCEWzjiwR7LBfv7e+H+4c7T
BHx0x4dsfF2UZDeskgtSnSrSjqt0RAKXWD97jbOKfYJkZqin7CFSFONxmflt csFKGOGZ9up2qYZLSD6ZmmP0/KoAnAHQZSVoUuoedgEfDxbBRTwBfSj8mI8A
UJPAqPdIIqTLWbMnpt4hlMGDQ0Rw+3ObVZ/9K/XC5j/uL6psls/zIq1WfY58 ja4iNKdMXnItj3dfwFCfd3zPvJTPP+UPcVKQ4aLIq9/stvHGBcwN1+2tStHF
b6Ta6/Pzy4t33/14GftpX2cZ88kfF8kdtgT4JbRFREGqEhzOyzhitLxD+FRA z1TSv3R0QKBihSL0+/bb63fndBPhzEQ5WMXhlg9k93j7eP8FKhUo1QWsLApu
o8TM02VTzlmAp4G/hr5WtW2hCkbd7QHukNJHZD8eHann7eXFu9M3LWc3fUxE ovv1lLJf/T1bwGbSKTycrReHTtNqHs1QVyzLbB6Npoto/Qt9gC688HoawZ2o
hs+KGPnLvCJN4Yj+pdfnv0JRDNc9ZOvqKtswEl4YdzKzu7rPanLNP2Ncx3v7 ywq/6IAMIK5Ar53AWHUrw/XH9+9Ax73NgMaNiuA9SDygr4Q3cCvRqgO3xDMz
T8XDVenLySynlxOrn9rLY+dXYFaanw720+m74fCiFSnBRwncu7VZuZu3Lwm3 wWGJYYGtD4FvfXjJjTl69QKC10v+/X8g7dUmt3Tt069Vmv37/8RQj4EOU1k5
os69XrnGGGE30TSWt4Np1bm7nAo3LeFR+rhcfKSB8yM/Mjf9iB9oAB91Kh8j 8DTKQdAPrrJZvH5QoZHkdy3WPvkmj9J///9AMg//AugE58AGObOUX3/pGHb6
3i577JWJLudn+OFsfUDw+tAevv55bM795xevz+Mb8cmX3MkJFv2fvovujuj0 TLt10ck5xARV3ACjdVDPRYGVKeFphdFEJX004lP8grcTdGtQl8psmK2y3cdK
Y00qQeG02jrZ4VSL3STKsOikGoJQRNnxDdHOJVNwwsYePyPwytD9ztjWUaxZ qS9zjJjq4K9iwmf1afv46OCg233SbE/evNtOEML/bkFLX/VIHx6B/11UzUSQ
2In6eTrfBeNaKQvJ6SIq7384E797K5jiPu9e8Dqd9/+Q/rwknYXUnnpRckjZ nvkrPHOFw6j1z1x04LCfGugCJ9OPrDuny/PzcxZNHR5IBl1x/Qf9bBirciHs
hPNHRLbrMS3rR+xiONPxhbfNIs0DH39JDPDwiITp/hFZq9jRkwnJhdaW5s82 T7gfKLvh7v5ztOKd4+2Pf+phkEO329kDlXzHO/O9ddZg/3AdTUmbVcQ64RgB
7NDIOeY8YljuSX6FoMzeumP7+WWL5tv45EvZysHTvcePnurWvTxrnb/LdMUC m/jny/jfC3w1VyqJiyIKTn/Oqiir1lPcv1ZJHAXvqp+z+7sn5ZhsEEcUWZcq
/IzeiMSOJWmQq+QFbQnP/uJ479r2Ia2J2PHtYDHOa73FHXoeA7303x3uvxgO 2NB6kwl7jNDNcg/6459zNVJwS6Pkt+OMCJLeh/5pN9ypC6FpmlXpEEVzQZqZ
9+xJ+KhPH/Rvjz/ufzzgwW1t9fv9JB1BhaXds/WBWEE6AScCX01DjRD+8Nkq yocxoNEHEi/Ri490Ni4XNihF4s+6nVXOIDJ3dEZqrNJCkRUElZvtq2ixvbeD
ATe6hcRqh3KTHWyc3eSO3cqkKMLGr0PnWVo1PbCTSa72jMRqkhsyEYPA8iQj lsa9V92jV/u72yH9/852r3/6GRf4Gcb8fPr+7ceby9uLq37n+uzNU6fJxo7+
E3BFrLUpJ+kqKUd1OcuarJekNbMq4v+k96TioE/rejlfiKRY4pUkXwpVxUnx qQutvpqXRqnqiljwJoqTZdu2QUn8GvmJI7OJ5VWbsH0Rrr9WFFgWu4GowaJy
MNroqIoymYmYuS5nkwEZ3DTbSYXge3Odk4rr5AdLGzIWqpRIsxyzc3qOPA/P I3YfvzoKQZrc2wl3X3UPjsPDzy+R3P6E3taYQm/Ofnea3j/FCj7FgFpvq/WC
DiH1oxCGn0MvuSN6XSdw30w4xsDTIapA3iejErIvIARe5p6iTu3kA40oMTaQ XrP0vUqoSNQX4CboyAZx7qmn3yBW5/Fd8GdArwjpklr/wmU6yeMRPj6Iqocp
wDCGnUpPXiUuwyyhv/nJI1o39hZh2ehpTAveEfEYIxV/h+yB3R6NsCFDxeyX vF2XQ1AX2DlcvhRLYSbijQpBkuvRm20QL4Zk7P2AJjU0bFlqibbYodLKwi6o
XIKb7Br74YwFRPYLjRrfa3TaBb7GFjyAhnpbzm6zCYcgHI34oRvJNEh+LGbI CUwxDw4PwoPjZ1DMNYer0bDOKDc/pmrLYOBlQWoBHNjHOQe6vs6ysihzDoRm
qyHF4jYvl3W83xLxjhI1sThJfZ1PG1p97EFikYgWEGHZ94Bgkq4cfSkUTybL uxJ5u8kgI6/RNnwUXfbG/AbYun/wqvsq3Pu8WyNPO+HOgQ5q+t+Cwlf//j+Y
DO/GOJdFTvwK1yzgrshYa9g0KDkT83wymWVbW99ABavKCe0BMIatH6Jtj/nR Wt9kRbGeVL9RwAnTURb8Oc51oLSHI6cjILVDOXpLRMPg/Pubj72bv17f0pZe
0Py++gP2SIqXllUmW3Rckp62aEAYucnM+RqBB1V8Fxx2rb9N8kYeeAcrE2Go gCjd3Z1XjCh74d7eS7HEBerr/mV4/aluc/zkWJGCoY/X4wr4BVkEkqIdAK3K
2wzbKMWIafuIccnK08JFqeAhNI16kJzR38RWSWOcZf6WbDqF+s0vy5D8w+Qu UdYagVaZZHOyJpMCkyuOqx+xN36NKXJQxJ0BDAokfLsPgqkanWXDYvsse0iT
K9Ie4ezGx1eIFxe822D4YW5QvkDAwORj0rlX/7xGDrdHaIHUYiS2McqYVMVt LBoV2+cftmGZ29euc/91ng2nAKtt1+Dl+Wc7GBj0XZp+Cxzp8GnhjCg7TFPn
Rt/SyTtt+LmcVNJEG51+Zr5AtsSk9zUMqBYOVO/SA9MmoV2RsNudqDXJ6MYl g4ho5NK5/rQcknbtemPh61U2+ryzmHfKbHvO7pb5T2hbBeLwamd/9/hlxsiz
FMS0XpHFhZTDkOXskNpaJjdE9QJcppMv7fKMCjL/Vxkt8S2yIYnCAwTTiDoV KI1BWPlTB+T9HKQa9YQA/yECnAwuVErXbb0+iN7991m19qH31Z0K/hwliAA1
dmkGdy2OzFWJ6Tric05MQEIN003zjJgS0XONij2vH1+VRGa6ZrTMZ7wmc9pZ IvmKrN1IevrX4dHOTnhwWEesGw8riKJg2PYZ4O69jtnGGD/CfgroBn0Mjr2Y
tHnvyAhYCusgcctjWScJbebvi4xzK+kcz1f0zLwW+qyTD/NDCk2GNU+xWwtI kh60nrCsDtHtzxWKGR4GUURt/7ojC827LzuH8yRCIep1lN89Adb3cQLMYfoE
AtmsZ5c/yub5Dj/QBGgxeGMap+JdK6s6JnX1W2KXmHktN5TLZiFWS3IFn2w6 C7qJgQrmIzjf+9gz2dpIptXmIwog7l+fBGYzdRJgg4jdLSOXWFTGSWwDzeKo
6y+WtPlIg+InlwWtEA2xhm1KR5pzVeWYViVNDTyVlugun7X3HI2cSF+WveQ6 DDkqMfgBhLDgdJDlJQYrzucGgujCERZAN14ihtOJllmMK3FDD98UlaIF6oiF
xVlJCuK8CCE24d14tvBkGiAx0F/G2QzsB4diWSADSxKCg/3GD9aQ1ZflOPXW ye2owI/gHpM79eB4t7tzcHxofrGnVD8mF66ufx0uwAy3OYiKqbov7rQ1wvdU
5ZN7fyScmDQ0Os1IiUVhyKIxqQWUPY6o0dyxLXT3yDwfWEsSGRzjxM08YZIt 4T+PaPcvTzVt3hGc3kXA7R316uC6ioHkEPYCSFZHqOgPbxQsKVUFaoOqoAie
dPJ8Okjj7UwS+jAn62AX4x2k3GEH0ABBnOmS5eD62+gFSvyQJZskKZznKGbv M8y5MiEsQFf/nCWgWwa9E/2WY5zwBnWCaC5h6XkGFCYagAYMMjTFwaqcQvSA
yikGiBFM8nFjEkiib9Mkm2ek9YBDsi6Cw41xpU7s8A1pfdMzgRQfv2WBDE8S e0hg1brTSIfDTNkLVIDkXWyDaA2Uodxm5yBZRne725gVNtMbDymupJhrEA3D
mg24xhXUO/r0DkFw3gS8mUbwwWSeo2Ef0KbOcZzu770u/OkTnaXzX4gcNViy eQ7qzixOo3wRUkbZiw/uB/T2RbPgg3qYZpU5pFWPX1V5NYmjKaig1XweLaJn
O9rX4BcsHxCzASPAam4QuTHX4aUrp9OsatEa61XUIHW4F/6xRpLEbX4Lji9b Dk83+IlnSWkKgOc8pE88eR2lWRG8i2ZzJ8Np9eN/AtR8m2UjE0+1+skKjRpo
YJ370utDjtQWxGk8tJaCo0c4RbJqml9dN7ToiEisEZk5IbHrioWIVwLoDZAh syufePIG1EEUznIgE9VTo2ZTkNRza6FbBdzl9KI10EoUYF6OAhEA4YmHLyq0
oOgguWhMUPOalfMR2a0WwjINhscsoom1L5N4NRm8NfNKFlg056W71/Fev4Fz VoHoAxcVlpJZS8WKF97hUbx7AAp1lz0Ud088fZoCqqULmOZpqOE6Xld5+tSh
7Fx2EBDzqTJmjAt+3DXrHyLAIx4sPBmqJn6lxb2U7VXT4CGWaho9LU0l54dW iQoNy72O0I/6FIzRdfg2Tlyr3IpH38J9QVnP8NaVT55X6d2iAsrxLp49RQCz
edsMbXpaOd3u+Q9gVdHvdELcR5V5draZEHqcWmJ0484IdUYNT4GFLwuV8jJ4 BFgUwK0CzuvRPlBIjeKqs5VWpjUhe9EEsIFeXtv7ztQMnnl3fn59+eHt99d+
2AtgxKTcViRH7nhpulmBExck+pdXTBORjaEW2nk6ie0qH0eofOd9Dgn+5z/9 pPQ7pUi1+H4ePCBzQRUDfRToac0zFFOsGQBEYeI1JCmgHwNpGtAP0B1LclrZ
i3j26IdTUpPmabHLYzo/O0t2zmeznFTycXJG2zWLvAm7A2Q5hFPlCCcxWWKP GDH4Wozoc7HlFc0x2A2mnL3t3eO99dlYzvlHGMUMgojRIZqesirrWfRlzXMf
psg62jHhNWowWnXxfWHpJNnty36Q9kksvKDFLFImI7TTDbyZD6IMxJ19FgaO 4rsEBryixAsvecOcykutMGY3eHBvLj+cvq8F1+N53iiMKQQ9402cg3yxBz8B
PYcC9VTWUnLKvJ48qdI76OP0HDp5XkOn2SygkdlDZW1Zxs/BmyRBVHavmCt0 mPHP6IRwWZir12n+1AxXYiBG9lIPRUiupoJ+Ryjvb+9w/luYy+ThGCcHvWSs
JDqXQgwQ0pUXLKlVNQs5roTZdEL4kjV3Y6EyTuF6eMvAl7g4OyKwG64lkcOF J/eDE534Ax1uWaw9pTU5cxxzcPqh37+sJfXgRwHGQRc6kmI1EwfFOC04XG4T
nzcpzLwHA59uz+7UU5sJuWijwRKc0lJmzV1GTNgZZ6wAe5+m0MIeIoxwRJuA QQ2YiaFvQTXfWhHxj75uAEl13xnnjRzV2JF5qM/V/DPm1uAcn0lj+Iy/wIo+
WREnXza5ekNZSzLpYmSSg4AZQdMMlRPiWBD0pEwXWZ9e16d/aYHIshpndij9 C1g+e3qO5qtrQUJ7rOFWuCtBCxdaATQBOp96y5vBEDPg+dOfhquSFl5fvjv3
xL7FzGhEK1ZoVLqLFQKHL+1jpqVaPs7wwPo9aEdiV49ZJZsYdcJFnOQQCVg0 B8JPfslI15++v7wOf3hbT1xzTuX7QoHEY+z2RbBJaeFyCmuBQfnqTWeFaVtw
Ji3tn3JZ0QoSg5+FCgh0hTr/NfMEbZuU8VEbJC+8RQSduE/SgWWoJl/R5Omr wEOglx1MgKflUdL5Ng3uREw1LNqEc+j1LgVxBBKU1YwpGMAhJ4za7MoslJtP
2kxAVOKQjrPkwiVTxcTGsn1mhxceY+yf6wrchXS9lk5f4dipVimWAOmW01w5 PQ6Z92d7D/ejGAK+IDFcChJvnrKIZuHfgYmpohPN58U8oxRcrVR/TvSQn00i
HLSG4mrGaV8Y/QB+iPD2NJ/XysZvadymQSZXy3zCTnDeJ7aV79T5Br0jOkaz xdPksQ9C1Z9ozIbF07qsw1Sv/Zx8KybGoJ5RCPfxAbmCY65fQYP8uJ/u3s5+
fFSRpoaVLIhidJnbgr2udQq4dU83Fay8PvGBud+8tHlEqcthvi4RWcGmy/zw Z2dvb/fguaQdfSU/xcFfqjUPvVH5NCqDc1hvtOaxP0V31SDo/6zGS1SdrFfH
x5ysToNckIXn2GnNGWicRgpJtahybIZ4yXrBeXTaUbA9bOFxF7ZDFtVjzK0e S7Sdo4XsoikI/nQ0Ak1qzUVwyRMamzibJkqaclxd/Xl9JKEJH8SbOoonmB+0
gwwceNCFRYeb5AU9K8/6r7LZbJ7KrgKXr5sVrcaN6Mmy1EIgXQDsyxr6AX5g 3RTy/hJKbAjFdf2qvE6y4R1owKAX1fhPXY18hh/8aPvw4OiZJ/4OpAvUqmKU
5VIVTbqFTDYXQFem5rP7eLfqg2j8nKPEJuCmSbUHHO7m04l9PKO35o3t1qyt 2zHA+S6O1rH1P0UYZ+6qAk1Pkbx8oaJ83UO32Wy2QPNAoqbRRK179HKSoem7
uiqnhhBwxl/kB2F2k9bXMHvHGnWoyrkwTNqNIsDpVJCaomKpIn6B+j2VHX+l LLN147FFHQ45z9DS+UtkBwO7616NS15HC7LB9NBKcZmOqqJEUQ/ugJXW/Bzq
VTmDe89MVDD2LqHvKRPWRNVQO0h6LkjlbZTzw0cCdsc6uflW6PE4qtBzYVjX tZgB4y+/BydADqKkmTpnwwL0yvvOfBgX8qqRCujsYdD/2t056/e39Yj4UQgf
ZUtbT+eoLWK1pCyhKqeaCtrxTllYtUXwo11FyrRxYfDfWiV6k97Ql7xXwPno hPf7n3c+7xpmWVf+m3IncYnw6klwD/exg4wShuoMMiQ/WE5iNi8wtmMGsgzI
PYNkiHPgFVRhJlC+lA+RnVs3zO5nmrOhSi+UPvpZvaYykNnMO4Wa9IoudmEs J1iuQbKFR3ExTyK4jOcfeuH16eVN2Du/ue3LADAPKOzJIhyO80n45QEtJndq
ZqKqJyyuIIVIS7zi2LUJvXHZZ0HJD/M0z0S8FJynF9+ZspZMmgHkDHL/R9kU Vnv1L+EPIDrLK4CWKpwlMF02A+VO5bWHrz+FV+/1+FS5ZTq/U+H8p+XnLq7f
ZjkfV57tQJypHbkbMGlWyc674emuTVWrEDnVsE404DNhD5Akb4GZqfUVcQib nbsP8jbmP+HQJHUovOn1jXCxgfAvnQMiW+ZtLhAzXQzyeBSasPawmAPpAH2j
tcTisXN+HCaFczDZO21NyKCR3JNPnxIJmGn4xygBDk9H2eXEeAW59hqEeS94 PszFX1/fXJ6F/cu3Yf/6vHe7PBTJBcUsxJIxwImRHNTG6H380L+9Ob38EJ6d
PMLrvssgupOX2YQZ8/fEVsaiolxY+QJiYjaenefDi102nfiI+Anz7NzSdSUX /zm87n1yBykBRrKaEWWS1F6+fd8PYRHhu/O/hud/6V3od3N4l45jMCjsPurL
eLZ6f68pDTQZWV87RumM9nUtqxeT1i3HhRUNcD6dec75hUH0dQfRP2GbRDcn f/26z2vvXZxfnS+9KxPDWdZfBLiDdiIvmKoX/BY8bo61/h6qNL2PV68vP5zf
b3rJaGlyWtQfuC2agLebFyNeLKIuR8Robwgl2f+RBgyKPcMBMykij1VLK9TE tFphGAbRAMEyLFvw7w//BT7AmN+K9B8Ym8ymOTIcRQ4HuCXk02m1/u1J1P1b
kcgBFTyr+8YV2zj+3BO5rnAH7WF1mCKb9B+xV7gejIjrJmD6dtu11me+FfA3 iwv/rH0o3HnVujzvv+VQ4xOcMzj/AjwDFDNaxO7udvdwu3sgM67AdT3Xiq+R
HVrCzl1IFLUN6NR/OQdO4RpNkIJeJajzEJ4sVS08Pq0Ci0eYzpprMXG8L5tm N75klqXrocdf+gJ9RjcKgDvkADin1pH7mIzr3iQ9pPtZuLP3onWuu3De+Cue
zAV2bJ6LrxNTaFYLtfiJRc01h4zzFCcl5kLCiZk1O3tIBjYJzNzm2jRMvIEH QQ2G5it4PseeDeocSlykE6+c+qnb6q3hqYcNKshibt70gvMRiG6qUk+uoeGa
xtovVkIEhWoBTkMnSiEWEmvXzKjNFwGdZcK53tt4wFy8bp7l2Z5nMTfPUnDL N0ze8FS40305yItiOgsxb3yOpS3wT2+y5a/R1UvALaYMUNzc8fH+rjvqEq3x
Dau7g7K8bmfSrrBtNvGLVdIpsxxXQL1qOldhTgx/NCvHN/7XeLF6ydvTM/o7 Bl36Ntw9fCm8VlAlM8+K7196fRop2PIkzpcvJQPrSJ6eaN0zIC9784G6EOfL
a8aDMPbBVL9dzgr1RhMJ1l2UrUDHpMxEWWe1SY6Uqk5prRTr1AjAN64bc+gE qB6GfxSq+G/5GG7434I3f70MwuAHFTyAlBWMMlLuWc1GC9QDJrk9qAAQ7B6t
b92RhUiJfHXmiemP6/29FPxgJxGBSiirNZmqW21FtDW2ZUGcSzTfwBEhu97m f/Qt6ORox4fz+cvVeyCd0RZIJXkOaC8SDZVc8kltgAWMuB7bc7C402r12HFK
iUUgxYToTDwDPG3nh9cvdiG0wytEo8X3HTYtEVvTl0XXmpW5d/llxITAegLm BP9ZtyPw/kmpr3Zw22kHP1DA8Rn81m8Hr+EHRZB2HCtp3K69v8E5WwCDnp0k
3dIa2LUvz2eljtYJNmnGnpbZSizyPFj6yO8LiznZwZzpm3ZtpaqULlXZThaM OFP3MfINKgPjCOG1l12NYwOmz/I7hAaoDBNAv6LNnohUlSFZAtsCk9ooT170
+GXBuc3Fyqnr5vC1pV/T8x15r0pRFsRnki0Cu531HSY3G+bGaZ1ziJMZWko0 drB7ZPLYMaanvok/rNXbQVzcRh/w9tKJ1IZpnv2PHQefABMIKPbAOR0m2HzO
uLWaIE6DpVFiDbnGLTIfVCKaUan81EW1XezLxSE2+G2us9mClS95CiYuz4Lq cW8BFv3BvhqlQ8CibzeePvUNkYG/3fiFO23e2gZJuH8Y5yDxamH3DyTn//FF
SlJP2HXLBQR+b4+j352Bc0VLVQg3CAlWSw2P07DSmrUVwUzIGy4aTPIpuAYM aOEhwh+2eQQ9ntwVyi0FMfvbjdvOBmYs4+X5doPwd8MoL/BtQyG7jT/ak/qD
LmIKjYpF9q1aDVsGAxa/uPcxq8X4Lt5/eEnMVnw4ycuy4kQm9X1yekOyc/by W43tj1Ql7g/b3md64m2eefVCztyF4N1x13EWpXSfVs/dw0JzX37p5K/dyftR
/Xe7A4TKPpAakIvsbEfKsupZcuqDxcz+1Oavw7iYVYQ86M9xcnZJj7BcEg1t gvWSnOlfA0GST1cu4Pt3Nl6uh9ZFq0j1kA6pX7q2d+7aHOLhLrDmfolXLxN0
EXe9EocFH2BXz8hlEM9YW6GdTsRd2Dd0VhpxpLWZkx3GnH28BR9A1KfILsiq /GmsktEzV0PXaQYYOf12Qy79Bqhpi283do82ggXo0t9uIBHYCLYZfbct/v6B
qmSP0NYbOvjBO1CJvJw1/aac0cbnUNVIlkCMSyj5IPCcLsoXxKEW0SBbJJD3 vRaX6TgLeJk+BdoI7qOkgo+fe0Fwjj9smyv7x1bIxKB1CxwiGqFZGzlP5AbH
IFZXiX1sQUJ28PDxxzLzLMDpkKTVEQ1K1bTe2pzqw/HgZ+Fnm92So7UqLecZ YBJqsgjQtH2PblodFzLURqxNtNxtBQ+USw3jom+gcFP2ohxoJazCWHC4nkVw
AhNwnjMLZ5PKsxbKe29HKC6tdLkEoORamgFv33oJDZMT0Gch7etuz+ZGHSq0 pxY2Ba4IRiDAZgu4l2UG8AmyQZEloO+3kR0iB5tF8F8sykJ1qYqims3ZiVLh
1rLBFQkvaCsAfzlDKoMaOEG8E9bqtErnGRzGPvk+JiMrtZgisuH9qyNHKJ8G lPOYk6PgmTgPtB4tq0qzIGEPzDRLRp3gNoPdjpCow/MxUHbjWiEeE6fjPAK4
UOlBR7AzXWo4/YyBs2x1tmIWpLKzT9t+ZY80W5PqlcLXxPMcv4To7fbYqC6Z VRy3NMNABcdADlzUq1dg99AG1hsPpwGmGLF4RNsBqKCTOxhk6BZyAIGTmVE4
4XBumiZXTXbPzg+QTU7xIdCeXOFIfmjHabyXKUlHGAoJefEXlSwGbSjJduiB ZhIWBysKtEU2wPBsjPOFkReBKVcawH9p5AGcG2U04bHBaAQLsh74a/SinTav
DBzwrGGt4g/M/R655XXLbiNgiN08JqmcrYVkNEuDVXQXVTB8HrZaLAo8gs1L 4cCYncYY41RGmEyCMI65zA4ltX3qkd9AfYnZmS+VpkxZjqFOm0eZ4T5L7tWI
Lyd1dzLgDEL+elyKa6t73OI+mMr8cE37/Qs2+vKFGb3Y1tj+WcP7uc/6hbqP ku8NoOg4VsKqE3yfJmhPmudAh7GEjod0wokApHhCQTGNxyWgACIiYDjmmAN0
iGbqS/nWiQcaq3hf3ABUJvNiLBC05CMMRTLZbnywtD2QdvoKKYUSMguE3xRn KQwey0fI8QUYIUmVFkYVSTu4ziqNQYfAZ+YYOc+1KlctitXRWTwaJarV+gZZ
cj3owPb0dqBwSiqQuPNGst/CBJ2Br6/2a9e1dLxxRubRCAPk4rsM5f61GEbi fp6NKtI3W61PHu7j/mBpFrn+jogS4aRZrhhP4QIO1bxEwPBLmsIVHPpG0JxT
VZBqUPGJVGkuhfyIEBY621kKhBo+J/5khpGKumt/dY5xzGKZjFp1LxTTJW9v 2Zri93gaNOADBi5iaYh7hbgU4YoBhzhekZyLc1M5AlPZdOxKh/gbBktHAxD3
EsWQInQLB/F50GU0aHUHgajTclkYqyUGK8y2rEQGuV3aEe+pXeid01BW0EIQ zCtqPMZAF5pMYRlKAneWz9E4zWuYYCmglFAOQ+Fwb8gXEYBOEByBzkz90xI4
X8UeDaiMI8PUpCUs5LSGOzNFyERU1n4fvtCcPfMwdcQGBmMxxa/mWja6jimJ DI7AAUkMHdCOgSJQpfekyXWCUxZJsXQNn67Bdvh9rhWU9kuoUMFkqNiCAaMy
M6CnApqbZmCBb0sYlrm0+Y293lbDD3G3kRmCW9HD6zSfyNYWNadmDwExuF8z AKwIKOMXoDVS8GJVkFy9mM0U1sd16c4mMIksuAOop0hqGonTFu0ozUqg2HDE
F/cQ/sJ2bXKbVrklT9MJ4bACv0u4m3GqthmyrFlJXPmxyfUthhaRTNSSMJPo 93BhEMIdLCMB0MkRSxXmFeKVmWS4XQN8hK4LQilQMUYmgvBcgmLb+o8nGScj
g+Oi26pQ9raT7bWsuG0+J9vKEPFrbeyzzZfdy+C/7rk4dE9za2DDikUWuG54 DKo4oTOZAWYB8j6oHHgXJzcCZOi0l0ACyPwxVZT9Cvd4toAx44Lhsww+3B8W
raKqDXe8NXADdSENUnLg7PflAdAavjGMhjAxLOT5W1tcXj7W7CNzVzsfFCxl AVR45lHKukOq2fH194w8b/EX2AAcBiGmJleEtXyqw6hQvweaiTsv+IWsKucc
bM66HOfM2VyGi60OR/nX5L2LAW6KVYrzt+2gnUjK2jInO9XFR4L0tqLb/mXn rxNMMIMsSsJ5BchXKB45S+GEYImohOOVDrD+Ml/TPIOtIWFtWDEe2zTCKxKk
tDef6bQiblKRkZRhMHCJ8DX46E15q+4IIy6O0F25xkdlu4hAuEtXZvHP8Ele WMYIqH7pvoRDMj2GdQHx/DJUCVIdvAtVitUzWbVx0AzGbetkfUnkd2tFjnSt
3DCjcXRiH4F4sLG4UfrDYF2r5h3cg9NCGKq42on3rUZVPqnjLJMwzzDORYP2 yMTUimwv8yYzv8eYCCKwOimV5rNBlzy3YVNzdLFRLQEANGKDIA3vM9b7aj5G
SDN9CX1CqsB75gjy/ite21pcgWsR/W71r5Xx1mQLPsfLOpBOjn0i87Sq04r4 YBlUFQMHkE2f2hpfpY2siiSC18FenGSeocEY8xcQOuOKmODyVKWBvkuKNQdJ
UmDZsDtH5FMQhM+Ka7ChSXBTjyWabryVZqSMx5zdqa61LyGFGJec37y19YIs TQytT9aFQnQwsmIUD0sdjM0J/+MA4w8mRBlJEMFLjeuKDLuhF6Lirq0ZkX/t
5bzJTEJUV1lf3L7rfHdSOr1AvMkaGQFGEhzrhTnofGpgnJDYMRw+ozQ/Yp8k qhQtesAxS6QWmNRuNGLCAtKYBxivqSwlQ0QAZI7xGj0+Wk/k169wh86/ADgK
m8x/VJbEroRfMUZDHZiv4jIVpqCpOUjScroVp0MuFgC1AWJZ+GJP02AEFhmb JMXmSk+RThBfwKRiJAB4nCv4rU9t6Ppl47HKa7DGw0oLBLWLDL8rUHS9j++R
qIdYkysfTmrBqOMoPoKokLb5baqB8Hk0ZTzOSjpgSn4TeAojzfL+G3duP21t 0jMOLFNdmN6lRHUGHPlLq0k3cnWjgATFybSEQ8f8wSUgEwUEMp0T87DMH2ZA
Yb8uCxey06QIZx66R6iObBfEiV70PdxZHOQy76GwOOhNta/nc25dk4xE7nFV 3oEQ7QSXpWbQdGZk6TD+T2UTiTVLItFLc7qiAImMaCQxKhRuzbuG5loEjhFz
1rwMcOZKlD8viHjh8XDGhXNeOoLt9pA8uhZUBzuTwJG3Z641vDBbcZqliz9G KXAGiA4ItUgQ5zTclOQOZtwe7WVajHIm/gmHe83oVcDikR0VrArnfHnglDd0
e0hEFW/zrKXABM7X/nqemRq6xXi2hHuELuByGuwRpHw4mkZ+QJvX6flQPEEO yAaMlo032vYD9GXD33BDzEe5jmXcIEDIdaqxz5WY4QqMkkQ7dKtc8uLRMYUE
mcMX27YjkXLHq7enZ/3hq9PDR493e2yyZixRaFp0OMTKqblAMOLetaSVa1yA GCTbHPjHAx1NMx0wbAJYfjUhmDBPdEXQxtvZBqRj+o3VOTa5toxEzoZStXOL
dpP7Zc7J0aolZeotaaU7Mc/d7IOG1eYI0PJG67BpxH0M2W/zdsjOKCAeY044 1nPe6wWb50kSgyw+DHqAqspTn7c6WAXG3Sal36NLamQkWAM3ArrkDg0Wy9vS
yxs2sNjnKlMC+VHGVHGwGLSQxDa3wZyrgPPM8S6J/ksq1drWdQNVa8VT8UuJ 8jVwc/1l6BSrBfqdwkGmEYEQJdIVhJkuIS/E3HviBIY2u0z0lM+RC+5Z2RiU
6JKk4HPfsIoAGqSzub6JZfAxyFTwrRg1zvEWcUC6aQIlcIy5Z5PlQmnpcKqK rgcUxGEcuHVWNIfdzFEK04PyuRJfnyFd4gKvjLmsp8B1aDwG1jxAPp4TdxZx
9fMNR2VPEkE0OyvUDNqvJ3bCnBJK6Uwvv/YpsWR7Sn62o7TnGqCfufyDRHuO zKW2nOUpG8IvSVrX5JPXyRQPZ+nYzglGgXAUhinXrzG1EVYJyYR/TsR0W78p
DuiqR5o/2zGsBa3KpdOENClUKoTpRPKCITVGEuZEbLN3B4lCHOfnS5iNrEeR N1YxuADJUAUcw1Gq8kEBATZaGQm9NoKXYaEHYSI4ACQgMkSlP8tYYn9JMtKc
q6yfz2l1dlmrg3j3Bet8OGs/xfCZXD4QXMX1FJvJi5VPAgixcDnd8s1cLn7t RYOJLwHuCKVLVyABaoVcHgToVIUwXQg/4YDIU6IvpN3Y73FnsKIFCTHC2lnz
YyZ4tc9NUZdsp7LlDpHPE3fFH5u1UTGplkWjpF3fQsyJNLfKZwcZw5xBV/N5 wAhowGOCpWg7RtnA81urQCJWD0kMG2nouIc4isfGtUXW1yKrcrTFlbBnR/pA
QaNsnMLL0DlXoslyrAkFPkDO9ZiuflXY88Hh0z6cfBvCMnTd4X++f3z8ye0Y QaGIf1YWoHVd0r9qneDMakEoB4fAGYh/StwEZ7kWWu3DVhEg4FTUAkOLX6xX
/xBjvhK/qNnsi1SSICc1iPatP0gyuH3NNuipiRWNeBy9/gPNFjtARxV84R+n aTzTlxfjoxF/pjlSFpDvanJ8jtdOJEmW/kGeHMdC3VBiSCeJ0o68Dhog3Nej
boPMfG30PHihZrOMyw97m6ckqWqjzFy8nBsLbodUjblA78CjH2bcsSuju65A eFYICb+HdWupMZhU8YhCvglPNCpjCw2cAmUO7xol8SCPcmITKUAM7bkaBdtN
Eu+6Gc81UW22Yr+3H5wYNOzazpzZLXsLUx53ab8QGPYEWVd6MbLEmCdiR4tb 5+RQ6rYgFWp2IdCBmUVeQB6W6GJUWSvMwECkU3b5QyqxDYucg1ZnSGlBxcqo
dn0YbIBwEgKnKyApHIZbPpeSEzJKVLPkTbBDW+XP/9f/Pd7dO/yEM9xLoC7U sCVyqXkeIzLUqaOnwxvhyMEQffb4oiTsN/UGAL0GA0uZSrt4cgZjxSq8UEkC
yLMj4ihwz6PHHRomv4Iz5WVfIsjCbxkhp00Rl2h/HjzuJQf7h8d/xSOODjWy qB5snl3wM0Dpw6JcwKncsbDMR27MBHIWiKIFign4CwmYImzWsBgGwTwqk5Tc
Ay6HCBAiZ/f3cHFplOz+3kO9ffq0G2SX4VwV17LrWMlURZKdNRoLYsW4Cdxq dsvDIRLzwHMszl1Q9SPmv+726kt3UdsGBCVwmGjGYNRVdRlWyDZyBKP9edYQ
VpZAqkSfCJTsnEpG+qSrqHa3LfBzt3c0e9AzIFXLiwyGQFrl2CtrvFySfO7M oj1RMUW9dyhhuXk2Y+oJqMmcHK4IyCvCozBKliKMmZH8SrUyQWO41lGRyjdx
5mAjShYsrW+cP1IzMIIyHCKmmn6QuohG5DAQY9En3qCgAqJrIxcReZBwGBz1 fwsZ1+xYoPwBrHQOsm8pbACNJEj7SDjXxhUYHu8tCryoWRdZTWyPZtjmguST
s2uynhtaFkZ3ZFFGBtKdCqyOx6UkPbNbZVwjhK6ddipb9BdwQomLgvKrRSZG LEOZOZIqiA1z8smJVoK/6qdAqjYCBFLjQvh7Gd3Bt4QuSAdhok7Qx1thRVUm
qPgSzI4i1TROFdDyEKevWo51XvskMAvMK0TlJ6jpuWVpFSrvgozuMQ0ZvIGH LSiG6dz7GTAfIv6JpL6L+IviH/wugTq8kiSxZqEymsDDJoWjsNpSNZ8gTwJ5
c/nDWU8cqXmtWeBrngRm4JaQiIjiZGNq6mileoJjOBat4OAJiS4aBwfoNlTj cUL5fJoFDjPimjSWhbliXpNSjTD/xYjEZRATkOlgGeqBGqNeTheXNtthk2pD
uZfS23Rr9uSHk0PZafiFjqsJFBK2Y0414aWxmXC64yQo/WEgh2yTFk/P7Dkl /jfqNotg80P/dEvv1G+kIjHEIzIBcZkhpGyihnnkQm+a0xMRc77vB6mxMOk5
tu0K+LLqwVNoWnTXctb0nHAKKKO83ZSUzD1CoEAsdwFZTXT0xWjThB+3LTlH NZsEzYbz179+DTiiXMKCNSCQ3JM/UCoLWEm5sOKENl/QepjwvVXIx4M3mJ4M
mhO0OGio8V2u1IHUjjPGau+TTF4i1e/aZ+NoTpS9dBgQPcof0jSmHS5g36Wd E0tRXFzPpS6kjWHWej2br/uXW6RD0RWxG6bdmZNryre0NPbxUXI8YTOE9voW
xj8oQ0JqE5Bwkp2vxc7ZDROjej7jSGyuOrPFxzKzbboh7LG19ec//dd1MDbA RQmgdcGH50PWnIapUEyFn0yQFs7n5B1tYpQf00YAm+U9g0qzbJaEKHTAIfPa
qoYylFPRhRDd5UWamE6qn481s8tsvebIrt11eQNaZ6Srt3R5U6qI3QLXdp7+ iOEfFcCWwqLRR0pwJPNH5JAnsg47pCT1DFY1AZEjHn37kzNW84sLUnXsrQdo
oTQCb0gWcb5U9VSxP5Qrcm2nzznpRRMr8rBCx3nDenKHwH52Fvv6qFuvKxs1 TfANwGCxly4Vpnt8pE4bX79q0bvZsuZQN1laQLZdVB9ETYAr/3z6G6FlNEgo
s1KCMZcSxCYr0kHgFUk1vUdUektHYr9vmOVxPvsundNOuL9XoF3dN0OkblRV PBbrYTNFNvXK3fVJQwtcYZSUU9Z0rCkbdkxNUkhLZ1MnbqFczEXxB/o0kzoc
COfLlwCAlwSb5atqPrcWEnsJounjnDfUdiS6u1xFopT7eHcH5maekrGPpUrm HDuT4V6AHxGpJqMPsEHALxA4yqkWNnEGWhgJwngSzCZEIDDCOkAK/SG+oE34
KTAw1PXUAfEHWFnEAZYFdlQm9XNpR9ECqydBKY56EiNfX90sJ1jNWvzj8ZJK SiYJrIa5ge/N2NZmyZxGdOJtMxUhhVxxqJsw1wpbEqMv6ffpImjkU4YSYK+k
FcGkJ3kELCNZ56VV6zPAI/vVgeaIR95Kaj+ZHVzLnYn5gbEFtdrijGpHtkF4 aCYsGyj4AGNX7Z/+EbWDq9Me/FeVw47r9SBY31dJKiZo2PiyXbLm4hhliqV1
QTv89Il/BL6k/ggUx0+fYF/lYJxY1DnEXKF56MR9MokIOeOyZUPcEd241EJU kpvqYhObbhqlAKQV01Jbc5xZNxn8EUodysLSDvr4yDXIgXgggDKUVgvQVVt1
lNkMGaTKq8Vn0CzpLsscck5phIRprS0bGHTb5HHym7yOc5+JAXqXEnoeKBto SbS2tioFasWir2OFYFzX+8QzAGEE4AyUghIqPr0720JG7T7BIi1+36DUBlNd
u3WQ6hMUDVoMYIPnW9Sytp+WdLHnatSkkCBjOAAzJ3kQKFFmQOMkpZnEsZXH bZAlrCSLrc1WAelBguMQ7JqkQPZ8Hl+JIIZKqSIzS7JglTx2jt4z9qLKHGzi
OztdnAictG1RoB3aG1VjBOEpOgOOqySu8qt0tGqkbIFfc3/PiEt0inriMBbl nuGbeksYESh1IT0jHRJZAHSvUqq+ly6WLL36+JeEfQPiScYyAhtN1NxR3knO
uFVxEcVAuVTDlW6QYIIE6sUCfhPLYqOj0pOwXt3TsoXwWraCuqi86RU7+SAb IZCTdq5prLEOUXKLL0kjmRY1xIiusEg8RuoN4KkQwgi1YimE1OQJGJ+X8T+s
9D7Pu+USRuEFnirqfDczb1da5/hdX/jdA/xeBJHDAAnxDRVorZVx0YU+Wbt0 sNtMVTInmYtHwX3zWCixArNjOl0zASGh18PB34bRTOC0UqYHLrwKrlpt5Kqo
MpeBEqNNhnIbyD9XPSklY71BDzP7ITgaTVRNrwocPsQ+ARQo7mfN5POuPY2M ICGF/c5xSV0rgnhMpwJKF5CFUtgh2VZ1ZX2FSiz+YeYjGovru7y5ffM73dIi
ufrn8ecH6tL5cXJgBrDtDXZJO2tUIlccP/LVyPPiUcKz02K23rvvzFvzenNA eJPllN0rts+3mDcSbPbe3Lzd6qCL7Ba4f8w8s+4hw4jek+DU+oqJ8onmX7ge
qssJH9xzf+9wSzwzSvlEh3kMgWs7mk3wJHY9rEpd+HpcLvRYRuE+txycmtam MV0Od61Vx7DYCobQuUTi1ALCOmGzBd1i0wmCyqmeBK0TklQA4wHCc/0l3JmS
lEsM9OESQYEQeaOeD+j/fTOPas0ICQYVyB+rHEB2j0+xWcvw0ZBLziGSb5IP rWl1IqUvZUyG3pQuItbnZVRQeZ6Raaj1HgiAPw32UqqSMiyzBPCfXFUDPgpW
wcGJ99yldyDzkM54mM8ZtspJTW5bdEoM5PNpOj5JsfP09fTEJZtOXK2bNdIq NFHGR0DP4KF4DsRq7i21BgieCn11OevK2klIxh6iBHjctBGO5EniBm9QJGp2
urpVaG1wK3nVNqMY6WvxMZa/LF1bweQp/VBnLrcQcDHI75gFDmYOb3X6jp5t a3UGGDmFaQe951goB0vlvY2hCFmsMaRptzaIPUvevBt9m5YSYzimQOC5FHFA
bf17zr5Jr6osc7WrYE1cPsGw+q0LNAG7F+Q4t6pZW8rWzotXnJTaqt1sX3V+ yFxUKGZSRbTEPYSi2c65UpRyVTbVmQA3Q6EFu4z2MKpBtBzH64l66hgL4KP5
RtdFmlc0jPB9QiOICp+g1PMucwTHDM0Owkbc1PGy49mbqmFYOkiiEadUaM2I 2BbO84FJki3uEsuz2ak906hsj2C11jJsNJgCLYGaqBO/NTqjcgqDkZHb/Ik+
DzR4EIhYR2MLU+wQud1tKQdzson5s3NdEr9FLrW2R3tDkBUmChSGkc3hfVrf HFQqxVKF3wINNOQTuXGzFUeESoVXddVGqaNB8/7s+kjzZHsC4OYCL+ht3W9j
NCBEYBzQBp7YJnG9VTTiyvHHcHQ7KtPhLlDBvOtDOQkpHoXjcsLoLYhX5ap7 LU9BNMClAN9nG1JGnFEvJdhwrZKOQZ5ErYX/gTbHe2Z6wdsNHBkwegh8Wi15
LBhrkFWBAcCswsfFq98zdfA6Xauw4nS3MQrP5KkdgktXyLSIytfS7ba3mZ+h aCRig0R142TQ/V5Jd9HO4AFqvjA3iL2jDucU49fDjK1dzctmI8KYt4fP1Oef
HKSeTabn0IVuMy7sykyqqHrbnt1aBBDMGc/FmXrRhp+vn61/5moZwp0bBEbk k+oXz7Xmi3iN+K9KQuiQJA6xKAHIxIzye8MtKOvji3OEmkPTWczRiUnXGCXL
PWzbuxwGCbAwsA7ysZeFJuQCL25eTlz+HYsw6I89j9nDpht3lGLJJpU7AxLw YKO0ztP6QuqhLCAmsgfN4YVjvJTLPgjSqjesBMpRQWzgGzC2ubE6HdsDxp5c
c3Rfww034UnvhWYLRwpE5RZeJITsB2ucsLoX1f7U6TyLEqxTkRE3D7McrdIV 48Eh2gy0WcN1k7M10zXoTrV+RKYF7iXAlpE8irmzFDoM00IrkQNFwn9kr6Vr
BBs1CPIvOETMWXmkKeeuRmrXWkcAZHHxKzR3gxM8xA+iVia/K9QO15/Bq/38 nSuasKtxjUNi0qDZiokhHVeE3MCYkZ3AK+TKp0Vn3qLFJoQwHWdVqqkt0Fim
+TBaafy+85x4x3X/ebnKCmBVEvOg3RhSFCkyckbGqz57YSrOlF5rWeDBHOrk t1nOzMggaYP3pzAO+JKb2M3Z24oo6kAZLwxBE04w5bvqImaEThSWYcMQraMx
16wq+4jYzLLJFfuAy2lfgY6cm4fNxVl5J8HcmWbx4uDMylrLcX3AWXLwSP5w 2epR42GzPZIVXVK5oNLL8BwBEq+AXAoU4yQYC+k2O2XJ0SCGZCvDFWiLeFhJ
HUFWu6iiHAXzkWEXVi6fT+/CDpMyrdCbFdMjCMHiOVAsAFVpp/Yh3TV0538F CJFUwdhFFI8YsVnmKchKANTtZ2UcIUxcSLsN7qM81rVD4H6Qn4HmYtKmyVRd
P/RRbbag3JHierWWW8wNGJn8hjLDtznHGrEhriwbqiX5eHCCm+7v/+NF/8Ug LanElmgerJExD1QsmrhxRJfpamq6IYImUqt6qNwGk5sNIYwbdg40YLeNE7ot
r5ppfzytrvqjUd3304bjGpvjDCmTQNlyXOJZx2dtaeoibcElRjAMTkRgHE8M ATWoubJG5phr6Gi84lXmMovnBmWEyInDQWu/zbtAUeEb3cHKjQZzCXyrRd1U
8xNNtWZ3XwD6Ec9Jlu6zRazQN7QAlq2Z+3ufKPGJ1TR2RqI2wrnAyEYAEFPb hhJypI3Vxu6E+jHiYpENY6JjJqxFnwa5+JfYu3ECrnJUssG3bpQdcZxaFYOe
PtZE1tss8bh4Ut6drRdXsNbM6Ywh3swouNclspkLMdmRSALDbXLs4EMrd9Nh ahwkTkxb2qz/khXaas9wOdFxknekKSeaP7hPKHz0PrsXI4QGLt6Yh2yJajKW
LYVu+wlthj5XxDvzUTjVV6Z6S5oTNFpJZISOwi4GdQgBxCJ0EqkEVfwo8b+m MPl/iJhIscMWxYk7oisGTmQZYKs1Hq4X+9BZFqkJY9toqmD6yUZ1UNApkaHw
nfXW3PgLtda7WrqnNbYhp9BScpGhkqjow5/FJqw0r85YEIGH4fRHjTtLnWqE Y0zcCEM/AA1FRtjpG5QduE1Ge9n8Q2dbsPlvyZ3fLPDVwtxKNad7WxUOLzLU
QNCZHacklM1rHFs9nRuqq6RsJOdAiNRpAhu/tF/8NIUMvdj3o2mX3Q9P7iSw EmNO8yLKgQw5ag0ZcZgbOR54lU6R6oycl9rEvwTxFhKOMhxSXKcY1J4DClYs
bVm9AhEgWZlxlTfK2Fl7s+Rt3er4HK5b8ZMj3dgb++idwsgDOvhYrqmgc2It KV281TrVRiQyKIZs5l0msaPMSABsPRZfCObaoCE91SY5GwvoRyA2LIXuJ+wN
yHlpOdFZYQzh54zEfQ5IMCk8DIZ+aEgJOSqotQqQ83kd9NpELHk+c2eo82fM KKVKEm0xyjIgTUybqB1R4eitbCJlgiAxORiVZYQoin+cYw4sVjEp3YktPL0V
u8Qa1EiDjxY8Jd3wjSyBAP93NWG0on+wt/t76fD46dNf0cwx2bGOkMQz8cxX ML+RKMr1USy4Wt91j55T5KfxfSTe75m3VRxO1zZB3fEbxyboiY6P35i7+hVI
KL19lrxK5/AMwBdR5/2z1XjGCSyTuM2YK6SJdI+2nKlXBZ1yAAJk+gTzhWuy ESJplRpHnYRBGHXQjCFCsH7Aj+2C79GGRZ4nfcZM11A0KmwxSGPB1dwP4DzM
Bb1hbG8ooH4V7Bh/n2WT/lsywjWvhX8flrMSOR4779++H+5y+oorXrZBC6sY s4Lgj3Zb9u3HKUDNvRNGgVi2U25hOx17YdzmiuwhsjrLVPwIyYICKo3X0UMe
RA+g6+1qkf8uG1ySn9hr2TevJYNZ4FpzPzt/0l1eSWNHKcvIFv16gUMX1+ex ZkuE26ompDh21nA5tEy02nSYVGgQgQeosAwiBwZ5GJh6xj+9r9PzPpt/TOcm
vj7L2kMehkMIEexYwZUibc4T4FG4UiIO82hhEjBzWVkfCdqKbiictbRynjfe W5sYkWfmOB/5jYur017YvzjtHhxutUk5VcRGYFtwK1iNKag4okeyC44iFwcA
eJsxIrVfGEvetdKHUDwM/K70qN1u870Ad/3qtpxuyx3rltNmmnjUF/bNtCc8 oJP5Y0ax0CIJKbGP1AKciNCuNjejZmYAUDM8y7JhxSEu2eJ53TenIcDGYQox
0idIsz88QH6S3CVt/rGu1tntj3chtKIeIS4OXgNEli8XdeKb5GL4/Ref5dMN i0tSocjQyltC8GNBn5xcxNimGz6ULlJuXeeYOjCNVLCJ8NrieDeDhcZyQLHn
Tmo849rhhETiF4w3LkwY+5exwRy/IyzJXastFlBmVlSWI4/A8hUMhsmqzRxB uCAODOAIqyX8NrsRrcWC+rmQNrFTaINfcdRDWC7c4AaLPC3ebyjqfMvKjbHH
2PV7nFm++fTPsrQqLF1Od7DADF5loyo1p0KYrKSrUcvCthpEYiDPN71snc3Q efQRXhqhODjEvatRNReAm56k6TIRQBNmm2NEJGjLlRnq0wPRITqK0mkij09t
h9+Vi0Uqh24Q/tJmAhuOvxPQdiTpFoGfS6TVt7tX5iUih0QN1lYz7hQ4ps37 hCyooByubSBtSQvCT7sAnOB78hYIangqACk0JB8tssrISBIsyjVo4drSgVES
FGGoNleqafu0Aa5yLtLVhD3n19a8vol208IIUWIulEKfSlunDYgx8Tptv+vT RyGLicXYgzFE5P+nR4jWLPuUcxXGMzgdsi4j37c1wOkCF3aH7pCUUeA+FRVr
mkwyCM3kQ7UsBI9j4ZrDJu8Z1R1ZNNvJDp6/61cn+Z1F4jS5EmDvWTqfcZEU gIvn3uR6cY4uMWH5hfWf4Lw2ZEWMtI0imLllNmTcJIOsllFZr6rSUsC6jD5E
LmY3IVwD6B+6ePL4YDcovJwxpt6Vnp6lBDKGw1dOtUfz9bq+nvf5bjwJv6rO qiTkyrPvGqqaoBRnQ4YGahihsaFhtwCTaijBBdZZTmUJTdlIpuC73aMQLX4r
6zpK4uYPHrv3/htrBvlJqzT0VzFrJ2TxCdZmY60YVNG0Bxj6Qz1D1hYrLZJh vDXwXPe/Px7ufzX4YgfR9Jn9GgVpf56o4gSqOr6/5YE4nNuWtEWISnxGyeZH
2W2WSJjT2wm7HsKtlWWplzpOtIs59xmBSoNPXW/osRdMMg1Q0xTWV9RlX4sR KxehxEtJNrIs5xs7nlgPlLa5wYBoikoSxbW10Nq+clscxzZQ2vJLQbNIFDF0
t+kQoEoE+LI9qxSUciNat1fvXrzZtWILgThAayoStozNK7lB/NR0QipQypEc Y8ZtwNDS74bjkVGjOdGAo/KaSc8UIJcsyCBu18fKDtm8ldHAGcNw18MmyRj5
AacSZ/osXRaMduoqNshaaUo2SJlut1k7E1swni3WvCI9cZGJiJOxleJecNiP ih6BzxYmxhAyooqI12ynXV4GKScUk0DRCxgujugXzzgHBRQWkToJETYRXYZb
Hna1IwidcaY8PbC3+YVAv1jWnPCpViqHn2S8I/F+O6d7WIjMaRESMFS4wVri 292vqLO1A5QpCgzBA9BIV7CDwwb5kyagwHnGTHS90BwDDHeTHnSYRXzYDnZ3
oZZk6bw5lmtjiizNhVM022aQLme8/qauS1WW88ZJZqo31xVukycsHrVZPs0k uvu/Yoi9rgQrZkjm0DmETrXHR7R1iQPt8dG2Qf36dcuJPMOLlU4Z8UgGFZ8X
k8vg1dpVnxxg3DGjcyJIc2ny4c2QHkfjv05vaLdB0HP+Rmtful2IjCpTgeHD mW0krIvk5tKxr+k0BRA4QoBPne/HBjdULTBOpPJUoQ4Aaj+iwhKx5pieB61u
c28OLFp79zSv5gJLHRSLCfSFOtgV8FGQ8ca0seqeu3uWXcEnZHgNUnKm3419 kP7E5xEVd8buKAEXTtoNplqz1odsFX0QMeqGPm9ju4+T8dCEp6m3fQw2dG6z
36k6fiJwmSYTqT0tfYhEKtgCjJY5KUFjxktPzhGzZsEJUvZnzDoDaoPrBBhw 3/yaeBXoRg/CkRqGi4A9qnuhTQP0VRsZlTHwC5I6dokiZBdcS0ubEbQKBQKq
LZwwWSrvQGHHpjyjKktNZg+QUyQSmY9JZeMSV203WDmrjMMbFjWUYdNe+T/x Hxsg6SBGatWx1XFho760/10ajFPAvJeqvoExJ9TmQMQaanvgm9WM4wkebYu3
J0nT+vZqa+s3/Q1/Nn7BX279MdnwZ+MX/GV032rzfb+07/uSca5f88A4o1f/ uuWGHHGYifuJdoGsj7DpBFcRKlMtSWsWiYcDZKNCUuaJdgPVy+Px4js3hd0c
L637/sPafb923pf4dKCrdLF5kNGQZAG27p8l37wt63EqcP6/3ZZf5iRiZ9si CcUGUygSOcrEpVmIVbEWHFVYyxuW7E+H05ZdpqxOhweYVWOhEzdWRkJ2NqnA
TOoIGZ1B8lyywQS4vVDmpWIrYM7Bc9qenKiFMuKOF/iUb4DVu/3LNu0T7tXp 3RaAmX7h29YKNEyDzZc2m9hyo4DaLRtfw4pHQUeD1w6oDvo3sCbYvPjnhQW+
dUnNZfeA7cyaLHFF8ic1skJPWG3znV5TWZE+xhxNkhUEk0mCYAIYEp0BkZrb 2Xoqzsrd8hM7pnRYKhlJYYWpiGROLsIQxkfmxWnjn3pttvnHheQvLJnBSMbQ
v2779yOvdGasu4XI3YEHvFpj75nSgtNGaGZqvvOjWkw9rG8Ga8+0lyJkz8Sw 4bQIq9HKwOrBQkRZwxG1c43cfSBh3VOJ8pVJpIUDQyGebf7lWIi43qnIPCAQ
uTg+5KCl8trlIzCRQQGeM3OZNrtl3hJWP+d013KhagHoL/SScmhN6ceaaaQK Dik4ioiL3gkF646cZDUqV65WaaMwZtsoY3U71vOSXk+RNsBbVVK2jQTlQEbk
zjkM1NJWAz+pJb257Aj/NLHQ8spxWLCfpawx0YSu/A2N+orDq0tO5kfJyVzh Dy1HKzMEF/PXOIRheMCc2PogEWq/Feb+xoj70psLd11u/YsQGo0sKxx0rdZG
k0XQzALMAplWMBBXVxzSmxuYaqQ9Rc0mfDeqXQj4KPjvxQe3uVSSSCmzoyMH 3eC34Ul4lEIhicGNOXGSUAF6iY2PiDgYuJ4op5/dMuEukhwn51aZED/RFO6B
pxhKh9GNFBYUz8FqkfGdz6VkN7prlwvT/ZdZqHMtrlkUdm/BIBwR3S91p4gX +4Bw+PdMg3ZFiJMx+YuBlc32mEKucXxGEVoSDxS7WWXGiNvmN363Ik7X8Qy3
YN4ikbNfJG10TRxbnqqM24JvQRYv6glnAqWjOSCuN0CAUq3heI2kc1ynb0sz awHUbR3fRiI02e0iCTljtVKHyJEXwo1BOk/eRjM49MfHmze9w53jHUEMbHgE
6QlA0NSnX2labR9eqr7zohokN0a5DvTMNQ7sdXVhegTlLZbckS8mMpulcnbH 6pqNly74kaPu3gHIVjpsWtINJMHdCjm5UweqbuY2b5kkWc5Es4Y5VJ+0TW9o
Sbwjrvm8KIry1so4Gy7hnctb70jJENx1BRwpddKCvcfPH2VFNs2bgKfcklEy ffscC00dPPjdZUtxlJJLqkoRbRQndEYNGTUUwODkiImV27NDF2U1wiMr2Ffj
SzVkZGi1JHBpeXlHuVRkpCmlFYOs5gx8U5cqydkhEr4q4V45tacJWzoaYnL5 nxunuIzaHOBCQhzpXRjATk2XyceDHZZxyHvOOwHNlyoMKNaAcW1OBQE2ltZD
2NYJnolgcn5Z5EwYDroowN+CjBxTG7TZgJ40cfaFMOgSqtJi8kkmWANSCTpa LRDs3MoXToZ+x6bP+nfsaQziDuj4WFmHDnWGklgqaRJAXhS7J42Bo6bLPgDk
Tq4ynxbhxuEgTicC9qLxN2H6yEuEOu1Q+phr0e6oo4Qn2frLTHAT1stD4egS KBOIpeQkwZBmIcZs3CoreEvHtRmXCcYnwFnr+HSE3CrTqMVmxgCLU23H9oll
YljXBOwqJMcoBrkypGuAECg3EHphERyCtm9R4IIq2pAh7MOANgIR5qRucAE6 MOS21+2P1LzBJrQWJse/0S/DmkEdN7awqQcr1hGyiCGaqJVhLei2kzuPt24e
sTonRd6eKZwbcqtgGN2pck/U9ezXzC0++XTMlsxucmzHKVdPcWW0tgWYeqli Ab/VZRuMrYgNWZQ8oF2Sm4AdeakBQls0hgRK4pnEk2iwkJ4zNM3jI7U7gVvU
yq0YuKLALtIGBZrYEXRnFcLak143QYUF17qVM42TMcYG7imXjVY6YRhaf5Mh ZncGq2e1hCDPH0+ZRCazCDgPspi2z8FXUSZSe3O5C8vJZzWNHKdFXbwRyqum
S7xWrZpd+HReEnrrTYy1l8MeV4ezdqbJC5dW66fKiuO3hvhAB6y3hnMY4Qij 2Iw7qtN+mkTzI2MsioLt0DH1fDWNNlmfgZLMvnBImX1ryDpzGlvddLkDXS0C
0DhDlq5o4a7qyGmyQfyjVbEdgCj3vQUUgjPLq1gL4L4LbM5dsp9Qn+44HIsu qKlzb2GCHU1QlN+pFyixYcxYln3S5ixHEgzkOpPvkyIjAKrRJMXLh474OzKU
05M+/zg85MMl3PMfzs/pb+3teU42v7ARB63WCsyMy75CmLDTcmh6eceLzOzo kYeEgzkdI7TE65uc/OHTKzUZJnh1MKyX1Aikl4BagwyzF/BXehpjEGmZaF6s
SCAcC36jT0zRzwV8L9S/GR7OkJ1Brr7y+WdJky4YFpqeC0Oy1GJ/pB5A+Lun UVvrfDJGFu2YIX9pk5/Ieefx0dQettQooivtxtQ4XhhvN85IZP9aZHLyxTCb
9ZLLi3e0hyYuBZWYekpzWihF0ayjQazKWRn+VqlOA7IEiMH4suIXcXqIolXz y730nNjmPChssg4pE7dqvXlcnoQZjpjfWEcVDb6Q6CRnUQ4D0sksGG5mA76W
5udD6aAcEtECYKPx2RP26o/UsxBWgzaplKDSO5cTdStK1Wffm08queI1yYrb Qs7EIxiTB8/TP3+AFxM0p5GZYz7NKea19OqloeZ/n8VoAtcBNri1jSnKsBst
vCq5F0zQUUbeuVwoNqCDnhPxWGhsGqJgG9X44u4RQy6d9AVUH2KPT6kcTQOu uWOzaMThCVaDJKu5sFu+X1hzXt7j49vQpC8btxCUG5gRSwkPAabmqAcaBcgQ
41ok2kJ9xiUxwH5fGpeuAIOTzabOiWRTEp4eTYe0mBQwd8wxBBLril1cdPWo XHuy7FovWp5SCYc8nqA+ctLqA8aDlorLJfFkkivFh+KICmQhZkbHHJgpRzin
5DxnKBGTctHwtl2U8HFk4R38dB2eIgpO03k+y9PKO1aAVhICsAoAonGwOR3i VkSqZUislwFSRDPlhdtGfCzePMbWQmk7aMhqtyh4n4EhbDh2SsasolpkS6GV
peqdrIfF3I9XmpnWnVaMepqMsisoZ6EbAuO0aJ96fAACYsWmNQ2Ke4pM5Umz RhTC2HJJ3UjqO7u8iqcQbz65/Fm5EAEO5mp5FHl5DIDk92QEGP0zArLTsmgS
lL08BfBRycBYMLM3EBfH8VRv/pkLIWC2fmtSRAfPW1IkydRyuxmXF6pixTKt cEmif3p4kqr8TXDrTOUT+GvrVqS4nR6RhNfUsMeIqKBBt1qngPJPB2haSDey
X3NwuFXtweyRvQPoLRUqRDBtaIRwV6pGYC7nWMS0cfMV3ZC3kzewPVuywn4t urawt2AVeyuEMzzB0nTGtKrlMWjCz1bZJQGYcISE2Voc0Rh+KZSJMce63hjY
QmQQ/Vz7I8WKoudZvLhXax2r8jm3TcbseorGRNunYgTlpB5nBUS4oYCaVylO lzhuR4p0aHQXnLRa79ajDkZY+49IBk7bSXKpVTVoygHFiFc/j7/+1HkPnvPU
fYAvzRfjXP6w94GToVE8x1VOEbp2wqJklgogIzz+0z7OUwoPaZzDZyqcxRWF HJ8YOPMxjFAus3GpbetIxVgJ3QENJTv2S/rHjmOvSoYkUYwDTCmYTjIGrfvZ
R2i9bwfauXM9omXgcPhml21HPqxEkZ7tyY42XTxMGvZ6Oo33R4+qkqFNHexz FgHyFSKy17BWz68blHryjpE3lTN/WAisoUcdITrBKesruAw1Q2fDMtIgIByF
4uDC/eHXLl6cJBY4bXrJ2Sn+8h8lb9OCtgXzuUsfvn41fKtcU/KiSLpdM+7e GxB4pJFkpgS9JfiGwlHc1W1qp1bEZAOgrZVrtlxVOcBcyxQsVymJ7shjEfWF
sMHSQJ3nteFjKbAnMXVDEGPFy4gRtC2R2NWvWoEi9+eyAB2He7EWynMc8PvU muGAneDSH/Dsoq11rmm0lFZL4c1DzDvmkRpkQzkXFtRDxDCTTr0Fozub4Tvj
SCUru0awCOoIsJC15otNV55yfcT4DHlfZqSGI1s9E19rZzXJHoveMxYF2WEg LFtXk7tXlMKrtLAmimN9G0shIMjCcdxW62yJdOGNWfrU5K25SOo4vYVaolHM
xFrzerTrLA+TlRCtALSFYT852MsZXJslsnrFJf5AFxtLiovyQ0i55WCilZbp RK6x8xwD7ygLp0olBwMdYrNsZEKsSTJEvaxt87vJ8pFXIiVKjmYn+C1YU/Db
4341V5wEsNhG4E6XJHCjgJqgytrPoqpP9LtB8r1kHigVQmdjXpdXWbGyGzkU sqbgN2VNwa9nTcHTrP41kIVp+DpbqBTLlmC572Dz9ev+Vg0N4CMPsBgfyXdi
ytU/TRY+7O3lGUlkxlx6BXkkIY5WSREUIAg5ZyfOSuWCUTOvVoDNWtjw4Uo1 uAjJiplTjkwdTQJbxqcIflZ5FqLolqjRhJx82TiU0nbGTErWGJE3JW5buE+S
Y8HVMdbLTBrTzAQTOJ1sznfTksZ0Vit8jFUGWD+rcE1CDyVDOgRVlff30hJT FVKMwQYecbg1cBxKIlOFiS7hG6FtzIiMuQndlrcQ0dhh4lqDazu1oTg4Dort
4iDftPqPb8L0u/8mDnFubcV5ApuS+ixIo74JllwxiAUbTRIRsiKKVOUyqglm 2LlP39h1qqHrr30BBbTRTWSgMDeLEpRrZmWzYPQq67pi9JoxTAMJolTix8e+
hmbHc8wlWkRXnC/HMzoYwGFZSMKKFnNAFIFX4tMJew3Y30JiFd3YobptuxIQ GGsOO8dSLn5lhWn0TIIWyg0RHEqBmLD8aZ19mmAK5xENL1wb8zw/YsQtDakV
yy9yJSFpZDczngDbVKh5gjSFhSpNIV2CaR7UIUL9inpQ+QewTneXo3r3XLRy V7KWO9We/C3xyT1ZtAAFDCl4QLaCx0cbMPeV0rLIlo85ccaWDBr46QoLlElb
CThiq7rXmwrDj4eZgZDMbQYltJcg/S/8XewQS3e3apxeZ8C0B7m8nGUbvsRe sK1QuLyHqufVSXE6Cl53C40NlP+ulybueoypcRf5iG9r0fqmxp7rvh0BSoRU
ir+pSm3050l1OgvQ9NyQp5mGxblPs6Q0Cku5K9GVuCn7qWwBiVcwk5KBOohS FcXYaJhsvTC5hyNd45T1Sk7yITueWF2xkJFriRW+KXUD2YvBfn/lFdyYUWNX
ad6Xuj5f7eSP6AHWpwRPl3LozXuxXWvleypozxFxMkVQWI6DBd2NBPdT1OsA KrbBplkprOBSCykmwjyUI9NtpEu6qkKmFWK0K5kWYaRGCS/i4gReDZrG8GgB
HHwl5YX8pNTyeGDipVdF3mAhpxHoNjA7uLzt8Z//9C8H+//f/yPBPnoOg21y IGOwptqarDen13LSYEzucE7Oh10iG+c/7DYZCG3fwCpx9s2DBw8cv6SzOLhI
eZJM8K6Up9Xrjwtmo0872OfH4Xm9uKOKN/o7nhYnaDZWD+5dAK3cgXZ7PsQ+ DIfh+6U9sIoJyWw6V0fwHT9H9wf7mjC9xNrTTq8vA6o9I4v3WZzwPMPhnPjH
jEhid9n6LV3SOc7q5euLf44EPFDjwjMg2JQdwIp2HCRHqaeJGb1E0kaYdpZe miOKxES36KgGcUhOPQKFLYQkH+paOTGmXknyN+VvmIKbIzaW0aXrYZkXqnQa
4JpxwNl9B2QCDR5GbCvMx7R1NtMx9XseaGTmvPSoqWpxcHMC1qCRzcsHISgJ 9IktSDBZ31wm7knkWzUuqZwCyxYHnd3Obpt+iI/vEP+ekec7cDzfCUVyl1lr
3HYP4U3KZ+IuXW3bEZu4fmvBg6dEcfaVe5gyxickBheMuFbYTXNwc6oYEgqg oEp07GvnX2DisvkURooq9XxHtpNqQtnviDua69CjnFrbIiiT0CiRHboWBked
EERQ/7D85plVBrnszmA9GVvFeWXGOAUoFnXx1va0ZJ1toIJl3wbtLbKrGUmt JSir95UIaTwWJU9/YbkHBNaBVKIdbsG6gEECbH5QTnFHcs5Ftv0T9YOgjdvy
EfwN07RSgH49ZmtPJL16gpwEyXWQ4ihNgmBcsajajA7elcjQAHAX6Ik9ZUdV fpoHEAxAZQrR6adtUBtvPmzgZPATu71siDiMTQxhj+LhpkjzNxHcwzcZ8CKA
QJqAoq6Uq2ERMPFp7UDbSwXHcZpC0Po8Px7FM+24wMhEAsHhEiyJDvToa0lz zi2iB167FhkLP9zefB/6reGXG1EZUrvxHawBCTnPKXX0TdQplWsRjmLO8aiz
NM2w56Da2fXEeJUef4fZkFSyiNhg4z5GN+sJD0nH7E6wLGLL9FcBF1SyYWo/ S4DY3cFzRNbH7WnI5d9/f8G/5wKbWsEATCECMYDpQp83zgL78kwtdyZCYIpK
LxHnpcuYezs8ioAStHJjrppkzF8iC1SmC1tR90LO9ZQh+BewaRbjPCg4SNPK w+BmXCfIBbj6H5SOpkHabYC3VKjg+5v3hFmCt//GD/5NW7labOXS6c+FXlpc
GY9PmR0txfzkgHRgxgCYxW0l2Iot5AC2I8MkNDbFTf3pteJRrsBDZwKSqCFv OFXnByQ/vLm87gfdnUPOK7J7IKciLnwaz1s6eFU/LD2aAUXl4LbfgFqSGaWH
EC3rG4P9t6PyNujvqLB3HL73uXEMpsGhNsiYl3T3AcJsb8tKcmmKhvE2Ne5O S7375Ri+w2INsCvgiERjzVhYHqPkEl9c3J9C2DvULMHFsV1rlsM63f8tCP4N
+wQIFxoBEi8Tu43XHsHi+86ddYnzyLQ9xlVLJ5xqM2a/ryyuFGLHCr1n4i7h zgoo0t9OgqtsVCXKoAqL4NTzu7lQkxQK1/c92MTVhN2dPZRVZPCLTz0Y+SKa
SXCxf8+OQr3g8aEtnfa7oyXxYzvE9N5hMWhMEG+9qFr6oZa8uKjFZ0zzT6sI ockbjexFHPYWw4Sig+kGOIRV5y27wr9MUpfzigU2tJ1hMJyMoz26Es8K8wxp
UULrthyiZZ25CjrR7gsBCJyT2Y0iPhypOj4tgXPfAUaLQhtk/W3WZr1BQaos HhkA7ZJAMVJy8t4oNQqvqiSRAGL6uw93HoNpN2+ubkDcxjhhXTNGxtDbYIbd
7tDEpsvXQWZkyswcTch0yx+cPNln1xMAOBrOTvYAnzTXNynnUotVkVU3s8xa Cbxx4DX9EgvjJg2PQlVlCPLUhdpTR9XF8A3f4YpZszEmKRaFpMSqeVjMgQea
f1iGpuqi6+p9CyEAsEPugLWTY8OT18Rl4g9AwA1gRq88/IEijtmZDdSKV8+H zbhVE0h1TlR9F313OW7JE9OzTLQ/rh7EDTV0bjdFMUiyOPWjJBlrwLXwhNib
u7KPmAx+ip4SRIfAkrfMMlqyf347HCpMwtEJb/RXw+Hem7f24aNHx+LqeH75 tmyY8qkPhljD6gLec+5iR0TCyUWVgXh8RxjzAnmCgFH1JKij6muNqqtqihEp
Az7DP/SB61mjjb+9H7SDVr5YtifMomseUX0Wx0pI2Dm3IbdKccFchrThgoK8 l0nkzuwR5tOFJ2zFnptBI6YyHyBUZhl3CXP/E2H/E2ENwrYGPsntup6QwBJd
cXX/mn4hrSukdSgHmzQrsLkOQjCBPcDFaZfspuREMYPyj7JGHHQNZFEIytdo RL0loruKP9eIrG7x0N3ZF2JLowqv/dsJF46i88DkjZXDapJ94I4ifPBEiwAU
8pQxjVlZxyiw4iReJXjsXGJHWSGQMW7mxDeuIBfcmXLQNmmjRW5DJciGLcA2 /ZjwApftCXqIwy29qE29e82t9d/ItbeWrzTMsepKrxFU+Fbi5C0Di9qVFnA8
AHvpuK6JFt3l8niFyXOm0D8SwAg5JD5+nKxmsIpo5NyKU7iQUZoc7vfhX3SZ Gxrrxj6w0OXBGTiw8GbZK3hC9tLMc93kxNmNWMKz6vTr2AnXMhlzmPRAcQxN
Mt8GkbdCS0pSD853uK/uSHUvhqqHi5y6VChdMt8/RSnDWWCSHGAIp42r6WwE khmi5tCi5qErC5xofv0mz0YZiwPL5NSYqX3znEPqZFcJNtrUqUVyK7n4+kQN
GKHtJrQUCP4Vct9HTDRUw3brIHmR1xLO1WzN1ZrLsNHyTrjnihIKP3FkX9J1 8kib2t2sDcGvwooOPQ7AuRqeJzGo1bCi1ytmbSCuZilvs/k8YrrS8f6qE71m
pxaacXIp/YOfr8rHN+YWcoAetmvD1bE4pyLzGL0dfp5WGjE9UHMSFAjK3nSF QiejGIVWkx14kYt1Y2FprKeoR+B9sooGqhmQHRlC0pEoIbKBC0hp1kL7+LXK
s1L1IiincQYFMrZ0qombKqNoDBI0HXcOK5Zvt2VuPAQpnHCK1BpTtqR5d3wT kjnSmh3Fxl1I7tOIarwsaNEPoLxZMCIKymnW9f/G09z4EMKZjRQqnTLpbV6l
4kxBOhb7uFwKliYxGAi6bFKuroTHdMZd2TjSEQbYXS4ccVjxk/vUNEZTrG0T XMlwniWLNJuhGf2GOsZjwsFGsImTbNkzDII/S8yYjCD6A/aTV9EsIckW3yFP
wNHT5B6+Wm+U4wSvmKagr3fFgpjo8of1Wt6RV9+/J1G5w0wbsx9xjrAqypyD GxpZqNvbq8PdLad8TULlyScsBMtAFYff9PsXwdp2cjUqo9EarisaAlah7yrE
3WiIocoyJEQYG4yQTjn/tzAwBHvltRdx3RWKvPE1cV6zScKl8ceao+UtsG7Z lcmfg74sK5hrxOcgqBxoXH5qGf+Jz0v4zHCt0wQGL2JSE0hdVF6NxLKSJ1H5
GnPnpR04YshpDQPSgGu6fHXx7myo5AmhFNstIXN/sTC+m4yTK527kpQ3kfpn CSSWYZ6Byh4S37zpYR/Dv8kG6bZqD/U33zy3Vm6r9fjIwvHXr1ScZ5WAvEqX
8Ah+Tup7t+EnbTGERvWtKBdTrgr6CrLU5/c/3V+TxHPOs+aeofQYSzKXznA5 qwkYgWhxj48XWKeShnyWEtdu1uJ+hTj86wThJRH4BRLwr5V9f7XU+2x5d5W4
ut5VWc7dSXiurXp/gOus/Ostb8YXnndmlBN1hass2EcWY+W4tHMznsOE9R2r +xsIuo0irsZM2wpcEPAMrdKrEfApuZbl2SDA0UTakuFeIs8GJM/yKCw8ySDP
QHHjjF68y4nIWqAjHUPkF5cWL4+xp1itTFR+s/PqhzOBII0+trgQ8tFqruBM l2dR8tqSmFAtSz0+Jq5l5OvXx5OAZbBvNySbc0PnlBXYn53Ga36M689d9j8+
WZ7RFhzfJDs/nPXfvrg809qWQeAgcGG92UyVnVFVoqcRK5bvWUM7RnU8nW4y 24q6yv+BY0xNjW7P9YH00C8BNLSTUYCCP8fvWYTkMNS6sczGnBXVwFY/fxmJ
YZ4lmu/v5tjjcpcdVy5hOmlHPYQ2QiOt5OL1uSaKo5SBtg4Xkm1tnT5U+KAV 0mxRzuOXsOJnypCY1uexiudM2cR2fYb7Yn77qzit5bG/iMW+RFh8fETOswpI
fvk6Fq8/qi1Y4JkLR6xXhBoQsMfovSsl6oQdJAjHvgGEgna4XnPtoiMNgKx7 z2OkK1noMznoS3nn4+N3wj3FcXgLg+Cg9OCtbXv3+E0p33zlaFn9JxPsPL7n
QHoupbsF3B5UTO54J5Z29uqqnwfY31xgWiVvDBZyXEgQqDZkRue/ZJO+AOm2 BlUlBiHgC+Kl0++ze8ZGY2pLbrNjlxMurKt1y7Y/qZUikEcNCdqi3VEHB4mO
5h6CNPAMJL28Cy42jIOlEQw1wwMYCMRdGZT+kflfM3zGC4EESCVaF2MBJDsv b5qhTZFDnOuEoZZueaIiC6V03wYgNhZZwp5sbV1Uj4tzwQldfDh7v6VrFXFd
zl/vilSUpHNNhEnDG7XcM7rvNe4zlf+O9gBdR8+yHNAA7CUN0oTjpvK6XoFj 4CiYwfBD6mfHCbQ0ajRSP1FnDN3cgYN9k6hKqUOYKXiUATnJyKVPYLtX9Zom
PXjLzqvL1+e727RT/4GU6pODpyhHdUUaQX+JZDuiP6cQqLuHm6s7HFluvDEx 3BxR57wsgimG6RKT47VlHItp+ibZVmUNyTCKis3AgO3VE6JNvCqoKoL4+Sk+
4AIifquWaJSxQeBICGILQVBGKTWNrsqks5IyK2RV+LO9VnFlG59DGkhLlx/B ntc74OhcExTslvCkxCzOaJBWPQWnbOhSBCYsRuerLowDigsZ1N3Icpz++Wtn
luvEMUnEM8O3sMPGjkeQdWBoB/TONbwDK9PWiKBF9D473I7XNxGqRHR+Pc1H J9cwM/FLXL7BBjxIqyraMCcOJPFYcbqzbk9Sr5BIGRAm4HzEnVqi4PZ9H4aD
4uLFKEWV33YJq9IwBptlgV8s+1O0Zr5hoFWuKjzkGyTo92x10EO3MhdjE9Vw 9U+jO7XFrhr2UvmIadAQHSnag4gRUGZqJypATz6O8xk3dHRqq3HBaIlKlG5J
YZUC1HbEnM/os0+f+BhMsikNeU40/i4rdnaT/n+gI3/TS+qbXf+tcD36XL6H 3FpmCJhVtM3biZpgWI2ud8yeFPkOCSaHJGmCqkfEXgajEUGbmnpJDPdI+uOa
njBugu9fZPz9uOH7cE1db20Jc/n94ub31prMb+le8vvaf+7tIPp83LjPAz+a Jc5QDhpirfROcI6JNWN21ORlmBBBtGKA2bvOTfAabfBZ2RgUCgvjIfIsK6Vm
y6tSCHC/uTNtMg2i/r6u/UMjrxtzJU+UaX61jJKwuS5bUy9nyEpF5iZRXS2k sVNwnJMl4iGIbVQQkp2aVO+UvdoUFKoTG3jdgC3/L/wLoqi4n7Ra/xKu+Lfy
MHr8LE68785E9wnkvwl/3nD1H0l2ceCJfvpjMiTLixY4+eNXP3tD2vpvopx8 C/qy9Y9gxb+VX9CX3nuL1e99qb/3nHUuP7Nmnd7Uf6i998el935ufC+wuYmT
PPaPiSxy8tto9f/Yb1/4xU/c+OcrLlzcfNmFQXr/l79601Q2Lsr6I4g6sveF aL56kd6SCP4tkNy+ucqKIdAu7KT87Qb/AaKtSjaYlRReN1FqMmOyoUbY9A7F
bP5Y/F1H8SUXjpvPXRgUSjxUk9F6NQggk2+d+fbO+eInfvGsfa1Fk476NAL6 eS545hBnHmeG49SDYbhyXXij0L+PeRGX+Cm9gDEDG182AEuAckmulXSijEqv
zwouILLWDypqLxibNcDmmYgap1eQWrfxu2TnlCStqB+sCgo/2yxsMIhAaCsj ySmRJp1ZxyUIJBoVRlhs0JtW+sBWvkTROJuK2xhw4DDX2/augBT5+3nDzo/F
LjkMhyYEEupQX4M1XmdVogVeYIAlJ4NjBSyBqH90+BQeWucwhytplvVhxU8S FxJNumtdLBt66S2WyLsSWFBmG+xMgh9oqBpRd4uBImlHPQfTw5D3jFwXvu3G
jpJZTI69lCxtMpYTtQ6OX11oFapl2Fg2gYob3HHHXsJA+4FIIttrJxW7bO/t EBcmYYqAjBCgPRORqZNbIi1uqdAY3qrmIhUg/BleXDu05Lo3eGYS3YvxTbhQ
xdtzCC1kEF1+d5nAAJ3tOkezQk1P1N2FiFk4XWgw4hMU9eULeDMG2AVP9vq/ XfnBiTTTvlyTvmVHYx0tzg2BRWFcV54DoMCj/wLLnlBMekVFbzCYYCa9B5nT
a7bcyZffuByesbybVu0Zv799pf2pbw56xDoP9LsvZeFfcxK/6ko3lM9d6Yfy JE6JX96XtxJdh9OFOEiIJhcowqKHGPsi8gW370ICfHlr0Et4CfvtDSQppJdq
MBv/Qg76MAtd4+Se0LUsLBP6a+gQrcEh1uDQvvqqhzBLpa18/gvJkgPw08Pd 0WMu60gaa+E4eF6ggMczrnHpvUU5Tc6XyhW65lNihs1IGNjsDe99LtyIMZe4
r3zI34ImX3YlTfIzV36ZZNkkWowOh6DDwa68u32lMibFYyKFdFe/+1Ip9JWb cebJ6gunri8xZJ0rz+vWIctOLQwsyJdwLXpJUzMddZ0ej+Lvl1wfCpHVRzPi
3xeXfZ5KYwWJ+re7+el/GhhtE/BvNJJYVE+u+6kX1S02LlKbJC2E9U9kTv1j 1G2THcp1KUIMPQlNCJruZYkLXO6QSJWAKGTN5BBhxpAOvl+Ky2ZuTfxYPVAN
C5cIaR1Bo7JQR5c4rrWJWNP5nTUg6H8mjiIDjQ1Xgc+n25Xbm0gUhm/OXEkU jAFVS7xM0+xeF0AsqfjljOd8APmCUsl1fe5MdsuNan6HZoVUjePSISb3oGEk
mubih5ROOTRuLdERf6cK0QCiLI00kp71AH5HMvEikImx4vHugjUPdZJaQoDr kQTd6jZvwGjhVAmRTB0PHT0xgG+oR1lsu0igMcSdCU+fajppgJDeIuG5pppJ
gXvtGjZp8QLnmW2Yv2R+ihy3remR4ix5WIfhxDQ8DRxs0SHRTIqsYWenIkvU LC1QCAKawVdpTFChgFXphjMH9VPLC9KaV+4YB0m5zUM5zFeqro4U1+TlMoqD
uz7rvUI5e87u3/t7v+SI7l0jtzZtC+8oGdfhOghBexpsjBQtgVp0md7MtltF ajRRNmHLrMM0BxtxaXQJYWZyjynTKEibljZErwAtCi8Xk1G+UlxfeLm2Ihq5
1GwHOwDRzHKDd6ZhmOk2j7QfOD6R2pVbBhENFcTvBQFPFcMI+8gypNpVW/L9 GBi6xzAG52LannTuFFI0xWK9QgYYXngKpu+kbehrAlLXtS+m1C23U5NguFQG
hSgh4QTgODPASWuo9Y8R4D2ZxYe/tzrUvPnSlZTc9PEaDl2gFxKxX8UENrWM p36ViXQ/wbRPVIlMmbAHke8BzJYCG30Lrz7cs4roTYxoOaYqY2ROowKjehue
yav9wDBL8+NwLJKjY/n0gSGHDeiCPZg7L39QyMJ7m4gTAN4bCjcnEoRH5MWr fMt6K8uw86jEaoeIGvBm7naFBcFuJDVP8yyRWGMqSY2vZFUpJcFwFVKoSmGl
DiO7Xd7ezZH+Z1TnNmkuDz3TayZCh/Uru2Vv15XdsvffhNrZ+7Ir/8eS5v+j ikLkaiwmhtcmgEnv/BY1FPQjAXvS1D1OTYK/3SlJjr/XFZLhnrWXmgN5nfiw
qbL/GspJv8g/r6FIaA98s86R3JEWGYMTKsSDRtfHVr9pbgPTT8QG/706jXZ/ crPCGCAWw015LiPKOtGjtZKnThvC0OpAbntDnorkAOpWTArdNdkKZXRD4WIO
LxKn6AO6rUJ9et3k429ZFDlwJ44Ac0K0dyMHrJeTGdImwoqyauEQXtDlL6qA d2NB6enhcJDbawxvvMVMAPjk/Au8TPs7T+/jPEs53nXz9vy82GqbuofpMGFy
DcQaN0iIRJpuIVTASF5jppKOcwmDIXHFiz45mFbYTsnzPNOiQvTOoAGJyVHO Y5qX1OJeh1koJcHJstk3knvDUrRm0pAFPTR9kThwiu+d/kMMMjNl2iaSy1ZY
u+o3Vb6IJhO6Yk2iCIS2IEB46cbokyLCOSdfOqKMVJ1oCzwpZKRhcFyj5+C5 wElQRnPqucjBb6NMkAoTPFAyMOO0g+vLD4BeI5NA3waqAbuZC7Cx+3WJQcBW
OsSX5n64VCHObNTWtwjcjDnu5oulpdu0JbzrMFcOHkBqSZqqa+rcNGW0clna A7HvcpE3mJybuFDlZbKPGClFekHK7dCVv2iffD+waiPeSk6I4Rr7+sKduGWq
VTpBb/CpdNFY7w/1b1ZUfoVbUbnFwWcc0n97t+JDF3pPxt/VIf05/r/ukz6A AYe52iNMW43EdqhrJ2rtSviafyDKOU6m5vayV3NpvWM6uzDzTCX6HznGBha7
U/qg5ZU++Bq3NFaAxf5hawW+hph/mxl99kKaau9zboi/wr990HJwy8bcDbei ZcMP63lYV5wa5iFr5CurW8JQLS/ArZAKfOs+uLa4XLTAcvIqGRtLkt4ME31v
XHgIqh+2qH642+nWOOMIe1bt8GLRvbtt3ervu7Ux8C+68F97ax+2VkM26ddt JyDeRKiMEaS4w8SErJPw9CCjKg0oXYyyeUn4PM/Q/KHcN2h0WZ706hlHsziJ
7Q0r8Lfb2uuxibQrOKFujlcZZNrv1wf0+153SoCoDnZ9ryvPZL09dCMpU5I8 o9zaXDCx1m1nxq2FNGWbwe2uRCQlCc2ninTMRMwepOKihclATbB+vmuhwHXq
EpmT1hKeQQwYjxqRBE0Cydr1CgITz2UZtfUwh9lXB3i7eOnvcXL+yEv2exW+ MGo2N2F1bV2rsYA1UavuMQ+URGT/SbHZGKgec2IGuhi6oYQiUf9E5VpQn21r
eq0UY9witzEvwjTRCA96vV45gMa3XP9W1qjaq2H6itaVKzB/lly8e9E/Ozs9 LiNrJ3RkTjPWhSmoxx2KkDnzvIJC571KNCIMk9mgBFbkCkqo9MAK0TgpIoM2
TO7v6Uf8hCzkqYlk6cxuPWF9IMRH7h3cIRQETgdM46JZR/okDwd6qt6gONNS KPucp96RVtoGESJZzduSK108Vyr4UXvamEtY1ARIS8vobCdctcBpPx3PZmoU
GyQKDVV9QAaeB2Qc5a7+Tme/7bQGD259fnnx7rsfL5Fm7fEQLPcxjp3bcquP 0+7a0tQAsCendoRBMVQpsnjdVEvbm/y0ErSy2UJB116sfK1B5Ob1p+3bLSrz
JipLc9jTDm3C0zOrOO/ADzdIRdZUfMFBqAN6aCDNpx3VWYOYfZjoig3JqrEL gJXpqECT184yIA6URNwICc394xAvGkWJ+gmTWgDU4dxMPqScZkObUWOz/DhX
6gcJOiGQfOS6kfsVdUoKw1rBK/oc3Whkj+giocsGSuxarZjCeaFumFvZRlRV ab//fouUTrrFALC2xlhON/ccSLTM7duGTCZrnB7kGTUSMy0WA9Of01IFNotw
LNFJlU6bPqlmNdeWSccAHHB3Ny6W3LFWXwEhAC6ureTWYcxdRs09QQyxIbq6 OTPH2NN2/wp0nyC8uZu9U2QrPefrqygFfCLieG3zCS76V0JqOWcN2OWUOuD0
f0axQdYtFZM32XGbm31DsnF2HVI+O/CuU9Lw4YtCkpyU2c1861fQwb0z2qm1 SzxT1A/oUOk6cyFyH+5uK0GpYu33sdS1E0zVSF0XMFaUr8GCLsXf4ykJrTK9
ttO5yxis01LotItcY61ygt7SHDHUcmPav/zoJenKWvrFDXlVddeNb91zXMpa WMcaiHzmS6D0mg1gl6ZCcvnGCwvTEB2Huhku70iuH6lRI1sCT1cDte1hLUGS
BHJnkHCoLIGGrHDS/kB/Ywd6a8t9CJIIeP0yJz6m75Z6k3SSLpgUZ3yy+2c+ svfUlaiQZCtM0ED3yFgHHklhPn1kZHhHstRDa2mGMdhsY1/TVF4nLHppNyA1
vUQapO3GWasTTxoip53e9Tw6zryz6no5PzHWq4EtuX7rciDXejwKx+mH5WOu k4dS18uS4X7Wxj32a5H2McFGTsCmPX8c93nTv7MOMJLvOsFHTgURKLjmy7jI
eWsh2dMLLmJH4g3aWuludrN348VA+Yip748rgYR3nA33DxxQ9fNXr/dPuK5J Jipd6BfJv0oVj0rlDnZ13QM+Tq0OLgAoEh3tl6g2Ie5G8UwyIZ9WBCdjhed3
DpSHhZcGqq2MStcLcO2NtDg/gsicV8locGtjQpKgAclJSJmupKctUdquNi+P 0x3l6drpfAFTnK2oFPeJT7g3n5NQsIwrXKctSgop6q6roUienXcmzmXlOv5O
UXYHi4UqhjxpQQ4EUIbeUAsNX92O6lJtKkk4bDcY7GlbYam9CbYsZ2taw5UA qbjHx9PRqB9P2LHyTeC7cVe11Hn8xveQtlp+LPmqTEvt4WHBmmqIKr94NGlj
8dOjKSQeP6+96JwsaXMPMWEUdLtByctnKaa1t7NV1PtipeioUp5DAjYC7RBH 7E7ShWMi4edYQSXR3WRojzG7muCJ82qYwMXAIulzziCSAjbIw5CK4qcjMkOQ
OS38xfmHl/3brGnMuWrecU5ti5pTwF/BuQHADgxOKmoHZ+XdwI+OlQ+Fnwcy CQfYMdC8OQp8G6bsjU73MmVwIk8bp1q+pKxhpSdkw6j7UiF/m/zrRuuh0KZt
FDvSug5KdwKjz/dzZch5o1RXXJdUUETga5DQQwj7pG0tdHZueQzmZyrdP7kc hkJU9QAkCD7EWFTznMV89ksiqprptehDw6Pegl6ee4WiK9DLBAvD2b9ZsdFV
g5MionqqmMOZriC1sMZm1QM+o70T41FGGkkIZ2KkGSTCoZ4LI97a4hPI4BGS B3QFonajd7WNDL1K1IovudqH+02Otc8cjyTJh047G7PksRIXe5ln/Hg2ZpLy
pIedSTS/4oIMg2/wjL4JkNM4h8MfBL+9tTQNpdvPjOXHskurQfTkbwfcRC/f AENjx7EwYhRgFwgRKV6o6RRGrE3Et6aIEm8A3TocR+cqpatxsV5fynY2ljbg
7iXbweIEn7K3M7qQ8a6sIMt57a1woB2pky6BI8HcY3Eh+ctgLTjhbg0vCtvZ bLXymlMYCiZExDbeYqeK06RzwSXVaKRIJ1ahzhhN0rjEgxx7XTCxVjbFcx6G
6txRfdLqBKGXMAKgc8ngJHOAwj3f9daRkumldKwPylgDl405nJCDLDkwXuOI uztf2HkIg1CjK6rHxLt7yHioYnksZysy1O4OjIWDed3NrRmhYSQ/XRaBSbVv
Qy0G0MwhQ+n3UUQKZ7sS16t/caZxqIBpOYg0h3eJiy6QwrVg4Si+Bd3jh6dh rFGhFktQb5pYUSyqgIcVNH1ylcn6x1t6/e7yLx7Th6NykZ+bQjW0NNL3gOOe
NuTXPs8KLqMBBnpgz97nF4/eUaqC4GIyEi6FCmbZTIzionFP1Y5VAHprRCNr 2hLd0ZaIYsZXHXBgmmGj5fwBSwGLJ9IjWG5+rD5hrWNGFtuxM4i2g9puZVpJ
6/uwl6zvQhlJvA0Z+MkAI1zjM0ZiihUK5oQp6rSkkIa3kLtGalVC1A5LmFLk oe7AJHVjdjXdAacC2oYZhfCTrsNDtNjQt2ukq/q4fdDGAHOyvNueIdQcCGib
fY3fXbzAGArGGbfKeFrxbL6QrCiGPFhF69tBl1pa5gbbTL8yUGrOV0clVdNh s+RCOl5pczml7WHIAcoCXrddVBNnStdBMum2zolSSXNj6RniBcDqeMZ7W98W
+khadaBtmVtWNmb9wAbmItJaCnlQf1oYAJUBqOsCwbeu+eKuoa/SjJlyKHtc H7ReKLeTrffMS9UkAYY1YENoLj1yTRpebUSQxUcYtcDREFwKSsIkqHGnV1wL
RpcHCYgUOR7uMy1AcM3S1X5FMVFQ+cjF88sGZlc88EkumAYuPO1AkkRG6F6L 7tyE2afT7A77FbWFEuUOaByImsJVJVF/4ZVoPcfWN1RbHosJI4+1OZe0ipPg
9CAbiPVdbeWum7rCVWx4y3ilXXu0Wiwvri2pXQW6oNdHzcd6hjTmFDXdAqqd NTU9pmYAXPXaJLsCHGDoKaecaqGwbfqmkhWLmkXZmvdEgbiWCHMMbsPktR1p
8Z69Wqa0h5osE4wAeMgNZKZLqQ/as04mVcY6L7uHrQtQSC6Zuae6ltdbsTKs M/mIhmR/0GndugCD8Danbhdu7acKvcbwGBFuUyHagQSc3JCKxFG3PQALSkuX
sV+tuERhZZrMukAxkjkIenUttTiFaIa2+VXzM8Q9CENGOywXq5bbwIDoBfWY +kTNhJR3y0uwE5A651delnrcZS2H379m+m5Jvy1ybzu6DVZCN6iE+mWtEirp
lOS8djLbH9W0VgCtRcoqFb1bLDBJheANrLaw1ieTCvLipfbHgrAMC3+YsWsE nm5QG2nvWvJp17xbpu6G7ARBIrq/rom+jBhkEx5k1IZeIxT3oWkHpqo1+euQ
BTg84dH+VhjOVCB69evZzIAH4t3lat0A2s9KUra2m3kbay05Jyl+c724QTuI q7yBlzAGJbjKcg6ySUvqeSXOe0APLDUtbiQOxCEL9NIQxLAfzBVnZxHv1naT
t0K3qFYM9OdCWSn3uM5M9wEYyFrNzbbV2hRhdU3U47qrCarLbFfHw0O38jIs qEmBuGRS9ww6aeeU266NwZywYYVi+rhFm1yAYk7Lw9xBqrFBN9YurYu7+4BH
Zzed6QEfeJ7ST8vsR+n1zJBygSTv2q1qo/oU03VdNbBAVUGeA6ZM28QJpeuo AEtCftb2SkKutiXzadSoixb1o9yriys2QtNUqtDBGoWW51Nu2DMDDR2rJ+FN
3SGHnlhhWODdcgDk+zaDkfJRVToFvM2hTSiDFg5VJ4ZUywu480rWISgMPA8a KvxL4vgJTIdGFmGduMHV8qtVIUB4vTB/rHxj8/pdb8uGXkZE3eFK6EIgu8ev
boRJqFtbcsdD1TfRHQr/oOVJrQoqoRZta7FOTs9PXyQ7aZRrHOjE2kHDY4CR dsh8hRWGS0odt+23AAzvI0p0Zw1D5XfoMGFGpUNARS5dFvXdwgZEEcvCXrl6
PbHrrUsemB4KTBCYafGzrLQ/1EoZUYhJE1xaG5CVQ6emTdHXk8LFO9hrACFa +K17F4kF2zqZa/qwYBHydGHrv0rbD32LHTHj4nW/2GIcI0DYTS7Bwir9OiIN
WIV3YccvanHafkxX77u4OC5qK8tTcn1oGycsdC+Y8yjCNhP71Hd4wdnsL34O TvQvV/2+1IrdO6Z7cNHvb7+/0h8eHOx/pTYDwevrT/gh/vj61XaT/z6lsiXW
rNdJmYmuYY+xUv183M8WoCYQkaLcGJmZQADyoFwJ5otX+rNo8QrN4OgSL8Bc nNoAMVsxsM00pGkzXjUdcssADzQGSOpmbjzGVHueKj5gCrmoLxLhQQjLHJT9
2gK1Gi6an+Zg8CjoPCkuJTqkRUlsS3xFvyDzGa4irT1s98xCL+x1OITwAKio WhJOSKdROm5bW8uxg3YLIJ8UjKZ77Lpamq3QjSzKbY9TSoSWJipJVvid2tjW
Y89wqH2Jp4Dr+fWkqjOkBRwnbrpkSrSoHT4HmxGM2cdOjKirX/2gS6s9AdhF vAhw2Bmb7FTKlbHNzoGuTJBd6HJhtoJ3VEpJor4AZAUekFZABj8qPzNUNl7I
5z++7J+9Ffimofy8tWUf7jAQjXoHlgUjGcTuG/PHamejVF029/ffvX3/9Ckd ClKWcrkWE6fev9sTh8/SOcPFXNV7vxlzdBR0d0I0VJpYnN87Lr5Uqn6I8RU3
SLZMuyzRTZQTz42T3LbPC9fOfNUT17Ac0PGYQb9KbeEoDgpAz/QszsyjRhMW 1d0Ru6bYKV15xPhnTbSVHJjtcC5w4eRr0vSRz4s5Hr+oGRl1aAX9iRKA9cOI
RnCKcBn4sdUobxiC00Xsbfpu+Tycmopwp3S0wB16orGYniDKknHiqHcqkO7X A4iU105wFhfsKZbIzsWSwZElJjjKHOPYUPAHKm2L7TyImqapO9dmQjNgHg/v
ITuZ2XJxPkNybu5IDBdAlS6BIleELRAGCsfl4bl4YbX+21Qvm2DgKBrakutc tG3I1DLWiOoeiPaiSs1xDWTTwEaKwBAQsBKIU8GJ0dEUMeNKJNyHzI/MwEAw
v2a1AaM8qQVmxx49CmFQ15bQ1sYUnFBz7lwn906nZkWgOtpC1zIxoo0wSN4g 2WpgtkrlgzvBx1RZqxWxPCx0KTcAg0DRMlKIw1qH45sbGyBFcqK8yNJlw9o4
kUQH1rNd7le3KkcMWFrTyils/UP7s0c6UsWmd1YQvzKctTzwxeMUc7uGhxZD OEL3ImXEpPpXaFFF9Y4qFdW89ybKDmgr29ltzBs1Myp09Vm095Sx7SspL/Id
EOtFRLpBbXTddZzTB7x4X+uti/xzhcNDthf0uJeG7gWDaQfRDBfwgcMs6rYc QuOYKYpQz5t4qFeyEV7ZrhlJLj7eAAPdRBaF+/84oIjiGxaa+xihXfJtvM2V
fAV2VUcjbL6M69pzyKy+eJ56DqI3n4VxjV6IlGE4B1wurs4/P2ebVciDv/wM wkALTfu8bmQULZzqMrB6SuIBzWSRAUf4LvH4bYpT8Q7H3mXyxte6aDJyzIyx
S6jiq/x4cWdVlQCf8d71GAorW8jRcutMxHxwqWFKq1PHOR4ZJYvXSwthdVh0 tmOAwZfUdXhjKfrri8sPvX4gvY1tKyNnadRAJbbPMrG7UxS1aYyWIMexJIAN
HNgfl04kzFOqvkekoFdloV7paDnw3D98fxsySojpbh+RmnE9T6F7tbyMXZhK y56UBKzxkAK9YmIIUc09RoDLSxtcQjyOMy6Pj+Q3PNIaM55ReDZKiDigDlGn
MdZh5GZkAKHYtdjhUhS26Ay20DYJ3YrosOZaiW47oXgWORy3nUbgoOjVzUha pz/EIIyD2hY7rdxrdRixxvjCrkRH5tiCgI2R6ABnpjBzMpqtCFfXSrUb6L6p
pULFOVRsaXKjdosdK+yRVBsrV1JN38IbuM5IWItofpE1jCJDL4sBFGPmcP9N 81zMQr2JtyjYWfKAuIE3/2HC6XkYPcoFVjKsJ/loVxIGtxVUUCsivgVYN7wL
0K6SbB3BWPQ9OkWuPgBc9UALR22i6UBDGbzAEElb4K+4WbqBJm8iSNJzQQe0 Nj/1wquz656kyrgWAuMITBKRbAZ5dgc3kCTMG5LH9rE8YURFZE6WcvHalD2z
3oc7b9/8dL67a50R2QHRdumvIWdtv8zTBg3d57nCtZ+OgM+LSvo3qyWCIAl3 afIntHDakCAh9V5eX747RxEEfix3jfEr5NYyJ6T8LvuiyTyrSxxvgLLY8vIz
xLF0bou3AtxrtaRnXWe39Q27D7gdg+G3VNkfdE25NEGPbiUJejE6XjiEnZdD N2yfn42m4k06cav2UjwmQRN4RCtR45It3CBUFmJI4QP/LviY1+rs+E1l6lWF
p+EbnokPGTh2njBoyLLIwcBIWURWmRQcWiqeAeK5tzOJ63k6mxlEbB3C0Y5L 3e4yuHjUbf0VOdIHKMDxFzUKuetcrbAYXuSWW6OKw8yb+qu5bq3Ia+xI9Ra5
B3PL20dARARaNgDXv8nCY56QVZ8Ly3ZbsQXypL1TfTtVfRRP4LsUode0iMYv gGYLTWG2gBIo7sWJk/ypF/uS5QX15bV++fKCpuVJAVrMiwFSQ/WgWq3TdVk0
A6d3+qw6U2YMYwlGOjEw+YLBlBLpNZ8RWQ2o0+9IA2Jk7HglYClNGTn9L0q1 UqYrXu6caCl7rdNjYpxYy9XddG9H21ERVklOTiQz3LTS9u2W6tZaNVnKfxO3
FNHCNGSlJ2yOxwWajEQXYN0ceXhNqMvmXWJ3ceDl05PPvoTat8tomdOGZAr0 WYP1TKcW1PrvOlXPNq3lk22djQUxsXHTjPvq8eX5dfi3dMC/Av8aD7j134Jb
ytBkcLWfYjD8g7N2ZrS+NdFvBla/nPfDKgY2GtYXoH0Gvrv8naB+0RT74reL U+YzYvewX98z2Dw7f7fFghTnP0hkVlR7V+6+9+o7fFVriA+ACPAcDKcjkp3S
0Ru9HrThJHzHbTB6yWVGak7VCB/5XZrfLAvg8wF3K+jTmQbP4VMTJHyaW9+h 6JETs+4V0iUhgs/NYYLndqLNi+t35+iR/i+YZLN7hKXlDNURMYZbItcpUKEN
vzpuIPUJBtmsBT+Vh85QnyWDhuvpJ9MSmA2zzLM66+ZFx6pgYCPhMQ67T7U4 hjEVJpR6aNw33dTtgkOo5acNFOmPBpQIdIYKFkXjCmUmk6mxLppK+XSay4Eu
Fpp31m/SORG4XRRHtBvupTqHATSikd3lE2Ak+2hessOnBOj4U6cQeiCjZDFb VdmNuCFbRf4C6rrSWI04YOsevUJ17PQ9ceJcVhcy1ZUXxZ2s3cHPWG7D9MT9
trEP+Itda1fpmx/RfnYu/GDojOSKlqi+fapOkbU63d8CteUArNc6PZo4474q my+yhfqAnQS4Stb7NkwI9QZCagMRZo5/6HhkVrLohY5UrRNRg7/BlJG2Pp9o
E1HfHRkXpRlek/KuEOhTT0lORrKBIWO5QStUF9nOm7qNYeiO8FQUkA3n16z0 CDxEm6l9/obn5HTkxWCGHnz29StdiJEaw5JnAOO3Kt3cCsI/wuW/A7H6bst+
UCO0zzo5xgaO5zNLJEzlWjcrezUXOmM2exohRcnzNXvx1/BaYLmGktnTLACJ y+QPPufvUb4cls73Z4q+H5b0Hj5TFK0Wk5kf53c/6u5qlqq0gx8L+7lVmuHz
Sz3OnH5pi0NrD0RUIHbF/UexAn2F9fHm3rLgCRhGJndPSR4fc39vI3JfiOyA YWk+d2yxJs6PBRqHzKgRv4hA/bEo7KCe5ZbokwXKOJ5UXloA9ZIj6SUYJxgl
36xySnB5fH6SgXgiBZl+AcYtUY1b30hSFn3Pqh7K7/iYADnpHzllh6ikZzBo jZHEAHVRp93ggxMvEaQ5M8ImNPyL+/uKp/8B8g+5LeG3fwR90NLhfIN/vHjs
LgQUIhRA0V4Dc414HNCaZebQKIVXttC0LMjeQv/lrlEGqmcjHIANSWDCIUK7 FWkU/+LliOCw/wj4jINvvcP/R1h/8Nkjrvz3ggfnd8970Ek3ef7Uq7ay8lCW
2iQpVY+aZ0y5c1KHkDDQFx0c3FGmwbf6qPm7w8MkJ4gMVWw2nhqTLimLqFYv hwDoMOoz2Oyt+A9dxXMeHJZPPegk7qzLEapNjQDgzdeufB1znj3is3dtcn/K
UDE9B+QXTCtJPe8cnbU2XX9vsjPkfKU3F8+/B4bmrpgRZioSSxWMUKUt46lF aBDCAuB/OgEIr6lTbEyuKeYCUbcyp+i2/0RNSbhaqnBJ4yMpeMPkYt+Rx79z
2Qgim3pE0UyQ2YMDzvqxwta+z8YmvlzGyBlL/RxOfhY7Tov0ndiTZUNi6lef 6/To70/qRe6ZepyCakJqJOooRYxmxChVVKnUEYrtIH3nkeDsQjbnjsLC6uqt
DIO9zViWrkF7J/ik5XhlgAgMemWwAmRod8uCl1ZjS8Uq8Gr7Du9tR9z9fQD7 BZunKCeQFEUCLRPj1ZwS2b4TCSJcJCNPNDa+Zl+f2NUobl7yBpcrqepaRsed
+sl4rwtnZ0AALhzSgGNdYI6QUgIN3o4eTpZrmIDatcqj4EXChk82iavlAj8e fYQdpQMfdI/QWWE8RljUNp0kKkTz1SggV7H2S5NdnpilIjZXyPJo8lRStU34
/ufHx66Y0jnlxIAzmKKe+h2Ny4vvd03H4LPoob85Sykdu0SX1vWS0qX+Fem1 mcTSCLfENx7ILO7IcMhRQf3ajNgesX11eXWOPBcj667fXgdod0m2TG176X86
xHv+4PBpMsqbCHW0lxycHHZ8imEdPnq89o2fuY6YFdGsaos/7o7FaPwt4L9e EtMuOo3dDaMExgZwlr+ewVpwgWcXXO3n/69MpJGLvDfxakOeG87ohOavP6n/
Ugt8ePeB5W0sF0QngtMlnEJKk1rjPX5kzkvsdBvNF3GWC5te4pofZauSJVrJ FXe7bSD0u/LdcxnOS+jGi540S3nqSbuU9UznmfR+PcFf4jsW0AUfLAH6JXDw
bcYlWmhnJYDfjQB3xa8YuqrCulTOxVLuHNtvqzAlJlVHyCwLnCCbncDiuop8 zqCLZ9DVX71oEGIAgMnnX4Dz7SL17269cJDfAibPexI2+cSTz+ODqxihhkMX
uqR4zdCoL+rfEJrGD7mMXEeKuzJ4Gfu5n9Fq6s+9QPhChahcaJljbbLvLbDb 4bC7xXPXnxQyJBXhQXreku+eyzNfiPw2N/NpKA2lTP0/L/LD/0kkQB2Av9FK
00ytrM/UCu9n+zLz6N9rD1mzaBluGM9783Yo0ij7Z40jCACzdz8nQyHRDu7Z PMFiNA0jK1i4rBfFCU9cMDKB5IO4qrwYnlFz6SzJFWiod5pGc9gC1ar+rlb7
DTGK+QGvSANg4G1gga/f9Ar37JFJil6ApP28xXV5cOEOjcCeKiDHIfDwgxDF z2GXwD68AGjNq1IjFkQsXkRUBdP4I8lHFo+NWzfmbt8Oq4+5T1iqeT53IZH6
IfnWwIBdQycux+JqpYtC0entdqCxCorp+u0lMMnnOeyvlifOdTp2nm8ib0jQ amL3d9JiLpEVpqp0un/qloS0NbfnAsAPB1lWoYpaJbh/mo1ydSF9tFv/G/ZN
CIDPek/Ie5yuSJKVjzDrUQzoF2CzO77m1EH3lfMWeh1F5GbtwdNZdbYmj8Ty gtulaaFiFE4KbGmstJ+aLqlLaq1ReNkwpUUWzwZB1hnumowqNfNpG4Kc31uX
BtFyO44VT6vDx+0L3eWUli49BUY7dzML3RVztNBQbHTns+ixKYiemWr0G9OP BodSjmP20VCkFUJdsiPZFSSClrPbyNtiO5B0+g8gN106cpMvnuIRbrV5W07g
DboH8LfhKQdqcx9TiWeirg981n/7QbbjcNiLMl52JVadXK8W6AiLZ8h2ug43 lI6Fcs5HssIoFHcFADg4noU9TdFshxOdeSHrMLIcmtPI/yxrgq3A+ZL/R2r0
rsPW1YCkHgK+HO2R8ZVklRgEst69GkQnwtLgauuDwChD8hhUd/uJhHjimICp FFs2oSjHIiIxucYeHy2pwHCHKZrnlzDXKZYjyMtRF54Mzt2BTOYMcXjbehS3
U+FJ8E/DK9tn6Psi63+AFhsdpv73H+AbkeYHQftGfsLboREpeScacHCoxBeL TuYd091K6YyJTc8Jeh97UnEhVURiHV2p74yN+xA8QDc4Az6KS2N60mBwQcWN
oj7TUdqcIsnrbnv7YF8Mbjd0VXH9vuU5z9IVpBp6RXasKEYVxOFc4Z7Lg2sZ LpXukNR8xX4EVvijzvePy+eeHWf6DJdapnR+IWH4TajCr6d9zXTvP8X+BrF/
h4bnh8QhThcqJAgbKIHWxoZVkEXmVWYD1Z4wWwC6vMuw8WPW4RrQbuvZTD40 lYS7bkwrwTIclp9sltGanmyW0f4p1JP28578v0vq+79N5fk/IMSGadwsyVpT
Pi58d+fgdfw1OrJKT764V0Eev7I1MbtrwCTR8CqXPpAMg7/FBcpF11uOmJDM VN8zRUnxHIkvGuq8eG1BirWDhowxP4r1c+tHZjFpiGUxc6z7UZTxkLqy21J4
DGml7TiYpO4lnH/OglHPojqHfLqb6+XntB99Ki3ki9iwdmjGPrOeoUTEBRlt FAFDeSHWHeIQW4rhikqvsp6uxuC2vTGx3ETz2y4jo97YHhMTrMFEQI7xVsLb
F5dK713HYadRrpmlVbbA/ToGPWPau05CrIechk1MpXc5w5TTSzifJMQqT/0j KK7aWRIl/snIzrZsoJ1yyJzm6m5PKaf7vOacFHIalnk89zbjuhQ0D+GGjlxb
rUm0gVQrSr0DlKXzCkqlArDOPMEjZJuYgRbjvI4KJr7kuKa26cXYVNp+wxR4 x/Iz6oqEh2Q4OTwm1Uy4eVSNy3Ww5VgBKyEnXdvUM2zgWRIAZ0IkKdB7pDB2
rUkBgWCEnianAxeo/sEFM2YCKtb1FH0nrRC25T179qAGRSbOq9PDPlRMmiD9 h/yQQ/IlO/UoqLuTTv2RlS5M5RXOqivz2u4xqm2OaZn4rE5byaORCrPxmHuo
/Pocv+z21JAP87hVc9g5PMa1R6SurgTZwxgG761r5j3BIHyPUk6rJeb/C/t8 1/q0NbRbBkFZhPEDuL9LURwwAjaYHmRftG+MwivQqCiBga1RHE3yaKZlWGrT
YkmlgiRoj+OBRNVgxNlySTqJeIh0aD8xLkiRN7/GftcdKThxzKbnAgPHg4Pd IoF/JPzhujfCf2zYJuU4mohNlLg16gQ/UNDHIqtaFNCKBXJQTUSZQCfJ4ujf
ZA0DF5vXMZPofEaNofjwDZJLbwroQ+YQz73AYfl037udHElc90OzG3hlzdYX 6UATDpCR+u9OoyLRAVk9LFSLssTGcSJBam7bZi6jMcUEoxJ919OyBGVpe/vh
BX7n8vWuqnFCiJ0hfWBqvZPkyqS6F+rtrhWVRUyjda9c3WvT0S/gzk8b1njn 4aEDwAkVJcF3snyyzSm4xTZ8fHx8cBTenvdvO7PRi18pv5QvfmdazhLWaf45
1a5fj64hyOvlOI8yRAkd17YcmDYeOYeaWoTyADg6M57G29/SFmxT8I/J5WsU BZsXuDaEtu8+4RT77V0b6x609sn/UKfYU9x62S+2i46x3ZpnbPclrjE8ARLS
UuOvn1BZ+Oq3j+ifV78lucP/yG+H8tvhIxSOcumq/aV1mA/+Q2+h80J/HdJf urUTeAkwf5sdPfkgbLX9lHHxV/jYdmtONkbMLRcV+cEuQr1bg3p3q9FY2aNw
B/Tf08dPj/HP02P8c7K/z/8cPOZ/jui8xLfgv+PjxxjD8WMeyvGTp/zPyTH+ H5Vv0mHBu1t1Sfg/FrVx4c968P80andrp8FI+jLUXnECvx1qL/lHoyYHqRgy
eXSwv9+6BU86PDp+in8e7fM/jx/zP08P+Z+Tp09bt+Djg8MTHuOxDPXxAf/z xf4krioxPf24vLwf281xSiwDDuX5dlMEnJcpztYrDv7lsDbPEqBrAlEpH+Mb
5An/QyOjW1xDFyQy9MF9trZ+kjCnRJnsK/EAp+DCV3PZEBbAz8XRwInoDLTj 1OPXk/C4Fy3lGmIesSxC197lovQ46Y94j/5BB/gjS1H6Wc4wvI+oh56b5OA1
PG+0BZ6vnCnCoWCRxMtaWgu52hzuuegzUySAC+FhtW/XWXoryeUIGDdex5zN nCyXKnM4/Xd1Alst60FMDW5knRRYke6/Krj8cBb2eqdd3cQU/sY/v37doqLT
JNYcPMx1nwhZnaAdy57cMC3OQmBfkkaqJRCDlkOReyl0yI20Z5MX0aJTq1Hm LF7F6bzigrqpHpMNbzaiyBQGRmmPwtsjvxaEOYEgdtd7KiY8P3cApWYDSpEF
NHTp+OD9ldqYqwnz98N3cCOJSNmVeJ6h/9xs0AmI2JN83DiDVpoG4FfJsgeQ dSCNLV88iE1quQBiw4iByjTSPL++/PD2+2vMDbIlgnRAvx/Xo09ebGtexrXp
PdGMY8y6KK61wRwR46bUbhK+EURsZ6BW6YorWp0rjINe1gIj9H2WhSoE4kZA c2mqL1nQqrzjoaCbUyM5Z1waqHBgIn5yGxtZqBLjidz0DcRNUndMwJETRuhm
rSP7hHzkK6SldczxK2NCVCsfi1q2iBS+hqU62BqxNxH5Fmq0xRsh6HttEOnC d3n2N35fKjRy6nPNMw2fY797Rhc5KBSnUL7T1UYlDtPdV8Gtg2pQBaQJzzog
GJ1p7HNTfLmZYVqE/jL2hIg7Wc0B7iXrCmo6K6dgdVyRNTQLGjA6x6y9V3ZR ZBeUNc29ifHOm9fwKS567zcw5o3js4WuImEKsV5b7OZVSM2QBjHdd/mLS0NM
lYgbjFRtUrtEdcSiOF+tzyHgvYGevdFZlthFV4cx3eeuxz3XVrk9WndsUp3E qga/ybLHCLNlevGSzD2NQFtDSyJGf3MCeWKKE9L+zZwelnLVhwUFUtva+gPp
2CVRp/QyHYeLvmlgmax5SB/Xvtz3YfG1AArIkUGff0sqmatoDTOHpOSL/f4e J17iVzjPGLSPiNKQqa+8rqABeEtDV6D0SEpznFo1TJCeDImMMRxP65WC1YVT
/RwlvLywwXFhtwz3fOeG9NgrhdRSCpB/8uPwucCHTUmrZBNfHDVaayad1WW7 MXcSVR1pu2D2/PiNvs5AZM1Fh9+4QW4VAymTuTmjMhpFcwJFj2512LMhb6eU
RIlJ2Ky0XqzscAJ6br+wFgnJ7+tdaEfywTOwEXhQCyTDMwAN9/kx3mit0q25 8bXlZ2CMLGgAnPrmLgf5UliwLhjD98aviK4LE2JHS5PtDA/H3NHYqL9MbUI3
N9JtM9cZwPWI9DdKeIx29bvSIOT5YMHtPk//UFrDqg5QFdeHSV0J/jhrxpXh LVrXTjpNORdoTnVZuM9rrKOJze7NenGhdLXEcsuprkQzev2d3a+6TcPri3c7
y3A3Hf4JprY6h4xLdKZx96R2A5UQrFVox56yUr1aczbkfEhBQdZwuli74stO x5S4yxfJNlGhB+qpAniC96jwLc0Ih/M9ApkSBqhi6tKaMIRZF1vlOBF4Ekar
R1xmyIuOaJjkjFhOi3aTH/h21aK2f3gzTA4GR/yQF++Gw/MzZ7+0TobxfN4K sFqL2C9ojYwdxBlyv/pXrYqOU/DXatyuEUPQUQziZc7h0Lpeho1yjrheCWWQ
dpvoiiScyaYO+mP/DszLZRNqhzwjj+0S7sMD+ENruhb1oXZZxXqoyCBaCGmt OihLoeS6sbtTFtsWCApskdn6oVMot967Wx5N2kuUmLP5JMSkqkSy8LprL6SE
SmNn6HRT0k69mcyj2TWrXyfFXx3vH8H459B/3oQ+ZtoMALALkmdNpAT5i5Yc OOeYAo/1KlSxkwMO/vL89k14r8pSm8a1a4MCbr3212h7ooAfLLDr3FTMicfO
Zy2oRPuiF/CpiwqAMOyzaMHe6hkZroom/SXZORPnHCCUHz1+hOJ/N+c0kCt2 vnZ1JH9Imxasnkh20KaL4hj+nTtjY5BNgY24FKhLjbOIS2ah3YhdRW7hQ2md
tEyTQyNQQ+crbssOoeYcqdLRUc6/9D81v6oUrdAuYwbpaztcnMGqOYXcQdCu Lbszx6Mr3mH740LKC1Ckk5cV7FM4LS5wjQdNZsV/kQDu+FWbPaHETePVoBEC
ZuRDC68675t7pfm3Xc1M4+SWkJjD1jylnhp19Zq88WMLagyWtT5HmIezzKTC 9ZrpcKtFF9B2Q6ZaAgDyCWUX6oJEls6XTl1Bisuy98BityRYwxpnJ5ri+yxL
zoFEdQWsXPSjRQ51KbfpoWe7DpMwbBnYean55ebhJNU8m7RFpllK+u4gxVYV Uhvl4m84xEQe32gHG87ZOJ+Srdp7kOo+6oRi43LROXB11yllWlYDLk9L3IJz
fzsba6Mypzc+cwZmm0JaWhGsRzx7ey2XV1lDkciTbTOSukLnzP7gwa0e8sJz K5Cy4AU3RwgysSC22OlEotSJ8CiOxORl0qY1vMjkXTLjC+3TlUDg28HCq87g
FEWTP8MyW/EJy5l13ocNjMSVka3VF01WBYmWds8K04ziI9HTWgHNI9KFcFqu mN607RATJDiuzQoavp9MdzEgFy+3FE89kbNeYMJKfn4ahCt32Yr9I2VCqY0T
qb1ORJXSqIx1zaK0zmyrPENMJHBrWEpkyy8SJvTGuhgXmrhUjBFtv6kGoVrz jFKZ3UW0awNHbnD2C8fSxQS8tTmSHx0xTmfPDZAvE9HA+NLYs41Clw5PpJJk
R0RWSpVcyKFTUsCULSW3yU56e0ngg7BNDAWvo+4wKOjyAf9JyYuOfLC+izbJ 4qIWmVhYn1VFtGVvCQXbwTIC8kp8DGxT/UNd/qiDRnRO423XZQkighj8EXM+
8brL0ptCm0g3LWLW/lwzwdaoxRJmaH6Aa6naIgbfl7UKDlKrHk+jLSGlcXqa KKGPeYZTLt0aVDoAUtrNiOP18gwXkVIjDl3sBU5bzeYc5UhlfBbe2TYAhkyi
ciZIbzk31dIOS3afXoiz7/SpveQyWJMPcE4wQtn9N2HQWHtthVFTzgsiciBn HorJV7ppAyXSYEpw2aD4cJ6HI2hp6zojZbEGeakKQsH5qFhBIdV1GHWHETkh
Rz2J/ksVEw6IJGwCC489MXJ8hBCLU1E/051U7KoPrLMcogdVaex3iuPajo26 9IrUrb8/cD1Zrg5bGcbE5Yw34nJDKwXzaY5m1415RBwTPiPBeqNlIwvYPnuW
EYTNojACHzdDl1QBj+ELCmWJrAfAfOCotFOcqxYVBcpYcqTil6tPMy6ObgHQ wWLpTfqGSqEiSURKI7ooUxhM/C6psIdKClUPzKFuFWyc5STJlCUbfYIiueji
+fRTS3SU9IMaW9t1nNS5WPEqPVRdQXRx6ZJh8MqwllKOfV4lixKIN2pUiaKr qUjMKSIES9dm80VN+9VRH1zfHgS9uDB8R5NTgELBdQ1xnNo+JQSDDkPUOSkW
2MdjDcNqA0Lcco1mKdVVWjjvEbftsVfpRNX2hCNUeyM4k7e9AtLQecpVaWnI AZz07A2ncBHRdxIzcRyiUUILsEiai6m/5ws05oLs8nWS6NIwvAUcRA7aJCFj
CNrGnFRqqrFTWZUrNGFutaptIF25NjjU6fkw2Tk4fCphbQ1iiz8L/sY9+uso nxbi+Eojk8F5wiOJgSHVQkqf6TmJ87oChonFrY8k0joNeCIpcJisPpuhS2lk
ipBKeCZAUcHoXWtD7A08EvejMGjOXTCNI2qX2qk4MOXhgAj4I+0nf5De8DqE syVtfQaq/FOV86qOoqOYCzKZmBFT3JEFASErnrCrF4KsPxbK5KRNaZmUEu9x
WFN4JC7eOdw72vXxqQfQqewP9ump2xkPQVvRINZgrJKOzx7+8/V3RDdv+Tkc liEr6Qud3x6nU51PJVIbN/KxTV+oqZCUVjXSuFx2U4EFa3xVEVCLUikucIQu
+KFh+n3kIuxsIPtuJyWkBKz/6ODQ2Lb8rHy7b0tAcp4ePt2rPSXsz2HwSLoS LV0cr0lzE/liQDUfckWKDTlzhlkOnNOWcmMGScWMDNSlNpAurIKq9s86vVHK
+gAvGisGO+2F3e0YxNofEST94+OHViMaxFGbErRR/yJKPHn81HSL/uNH3YQ4 4ZXSma3ziy7Jb3FBfpPb8Yyr0V5xJ37BheBaOBRY/s10focdsa4YYl5eO0Ke
OXSEiAZxHDwSlDh6eiyUoB/+Ekq8KwOO1YiEYlmMnq18ADoG8ahFCV6FL6aE CnlwluFUadEWc5WX8j03dKJn6qZ22qYETj0bI4QLrEzFhMYMTPMmwb9K7hpD
UuFg//DYbQj5RWny9EknTegtoMkfo9ae/V/6K3y6TX9tm3AS+Hmxq02uWN5X d25pn+qeSu4Xul8flt+k6riOoNaEpmKBsFkBy5qIY18Q9WeGdVWpWoIOl+N6
0AVT1Fd+uMYy+ocKH78x+rH9yzYzFXuc1F2z0EoZ03yX4z6c5L1T78KJVVux h3pQchKTPDjHuRnz+fs6ZeFSF6JScLVZUyNLeDCTJknhhv9/XuKmzRtoteqp
2/ZqG2k5zJhi3jogka6ZXmEdpWQWj+d1vyYLqhjXfSStIh8+SCqbWOZFsd7u BFKeSnJfa+m5DA5AWFH2/OQPZyp6/dQWeDhDTXDz9Pz0bMtaB2hqwXfcApZx
tNYQgW/hIkTRfJzuBp9S92TulLVnWt1hLqINQoAskI4M614ALbAtMHXbRg9N jbwRdYEhV6ugOoe0eefRQtfWNB044NhDuQsGm7A04lyXmEn1zXLHWRqGqYNJ
0PNPMvG5TRSUTmsPJAdylzairlxoiUwtryYumkrH2zAhie6eac291A9tTmoa 3ZRFixIBgo6h9HKe2qznFVRlC4LpSoy3K5z/5JgXRigSIEnWo5RSDCgehmqO
JM8RaFeGY7JIzZH12Ix5CH3ks0VYA9VqXPtiB+9GVrLup8Ln+g02SSQvSf5o 4MJijF7oGS+d0/JpTfqqm2oPJvqL9S2pBGUA4EN6xp0Li3rXIdOhvXNAFhXY
BdQuzrOTFxpmw5dhr+C1b4cxwcLvuqTQFwmVh6/5a74NLtuSIIqxgHswiR4v A1y0NAPGyNa8L5hwgsY8abVX7/55mi4aKi65SCx8isz3rpTMthyqjiC3TcxV
zScWIfQdIhUJh1MOnuxrpOOhe+ronidPERWhW4423kIMGlEWxExOEEE5evT4 tWq1bEANxgCMwtQII02PCgWTmQlXZcsRrTU61jeAquv592/C3tUpAbHPv7da
8fFn76mjew4eH1qoZ9M9YHpuJhy4OT6xwT10Ux3fdHjy5OTQWGebG7T7OeVS +sNNKoEn9psqpWJJvoFNW8ul62IkRrXHx7dXN0dHcOfIdtBkK1gFObatGbar
8wIIpNDTXmwupuBtm8FjwLhJ8aarex05hhyrcDgte62jsmHnt5Sxlj714Fn4 MZlMdCBsRvlCDPd8j4dDqjRKRQGNCQmL3rV1SAetGpvJUe1Ir/QTDZsP4pIq
zGEArPKm0fyVB+OvOhFfcyTsz0EobN0fr4W1v3y6v9+hGAS3Hjw+Onzg6yQh gpv4GL19c3y2hqvwXyMx1OpHtVnc0EyeJR1NTV3Zg/r1LFcQJ4JJxYCoQngq
habjCXzZZ8flNcK1cZ08+cy4Dp8ePPB1kjx+/PgLxhXMLbx7TUG0Lw+ODtbI 5b9/ZjQ2Vg+K+xjnUYWla1O3lVPHlALVpUHpYKXajJab9AYdU15fH7ns9SWn
Ed1Kx2+NotG4Do8Pu0iebNI3O9YxILkb18HTDmU2HNfx+kpH4zoAp/wLx+UV jR0fRgVX+tNDD9yq7EtHqM9GSyeugtN4TmZOIyN5df1IHxyZuCcPETrBe4wq
2rVxnTx6mF7H+5/ZX0dH+yefH9ej4GP/Y6Bgtsf15CSYSseth0f7jx74mjfg kYW1NZbb082zAVVJL+DkpAnPOvxsg4CTk3VEpUCwdInX2PGS4C2mplPrDoP7
F6xj97gCLbg9rkddxym49ehg/YJ4XI++ZB27x+WV8PaXh49OPrOOT0/Wzls0 7zCbM4taaVxtuKdr7Kwvtad6FtTUNG/QE7SpJ5jggvTQIKDpYsRrLjPLynzx
ruPHh11HmscF55ZmB5Jggr0MdI89j1SR3CKfPnCqMvrHzuvzf653w8vuvwkL pZq8mIJRNVdUOycmrsS2wbZpKBAnrsep7Vbm0lWVqFKNcGy7Z70rlwY//w6z
IdTPZUk8LpsEydNaUKHAv0FeopdzDmEkyDgKM0B7TmELBsbhqAjCw2KZVgjv E2mVpbVmY/Wor6b9T1hW21R+U80dnVsK5a09ZLR1iMXNGIXbuqyFLpwgy4KL
3jxe+sbzQZrwXyY1XQwg9opZBCGPM+LGiONmFbznUiignqN2DYPqDHmFzhEt QLbSaMSut0ykNQACTKVcqdBAsWPpvjt/vWAlg9G8PgChdDqLULCqWYCbyza6
6yF4HFbHVi1SB3xpgs4nzFHaOLcH9YD/lmqA/TmLhxJd9Rd4af6+WkB4TPyc FZY9EzBVJ/TNvqccEkXcecnya3QtV61wzb7YJ9a0RN8wLLHnGYQ3jGct02Hs
LkkwfXz1+sXLj2bSBAf08Rqrax3fdR7dlradT0iS5LPjenR44MelmoCXth1M YgYGsVFK1JoOHtyqT8QRfakQQ6g6OrY/4FostWI1UwWsmhnzmSqpZh0mPTeU
Onxxl4yPuWHnEz4/rn8+fPTo4KRNMPu2ixxfR6/uJ0Tj4uF33fyvr815NaBj btak4fEbp5k2KCvv+VPTbZy56pr6mGtaTEsPcFOnnCrf6CLotXrz+DI3NQ/e
XP+K2kmypn8E4/pvJG03EUztrQJM5AtY53qO8kN8tLeJiX6ZLfX34KGbHQzJ e1XQz7kq8ebV+x9A7JaxtnTPZrId1F0uS/U5N96AAB32p9Esls4ypwNsCbCB
f688VP68H54e7h8/ddSSP8pRN++Vrgtiw6DzCUatzwyLk9j7l+4ZjrN3uri/ NVgXFTqpAmrrp5MltB8ca4guKhhrqu6LO13U2pSKy9Xf5UgpAUjubc6xsH5R
irNvdJJ/nlOtGXh/b/MuWWOR/Kdt3v29rbtu/rlmRf29jahu9rlmRf29bagN XncFm2/6RoDXtdOsR8fQ8oCqklVpjNSL/ZeS5q2jXnUdXjM7QbiYRUmii9IX
w2rbKn8nU+WU0SHGsywNUgyDoEPPa8Ithqx8XctAZitBRI2zLbX8lruAxEpx bgH8YWYK6xP2UJUyKWbvtAG6U+5ND0Afj5leG0z0ikhK33fbDV6PxBt4G6FH
vReYIRxDfVitN3NDS4ICIMngOWI6jBVDyepuHS5Q0ByiXgPdvnh9fnsoiUk/ PEpDd/28cJjTRq9qSUYXdEQtG2gYfRFS5cYgouNVAFZdINwipK7/TG1uBIDZ
vri0UjDOVmPIBqv596k+QAsdX8Nhzw1m4YEPwYRTo5wku8jzrU8fGvxNq/TK mIyGFGbrRTUzXyEYksTjdviltHiqhOuU1WO9ylT2RnlZ24bIpO9YY+Xyk0Gg
oxD4JnJa2O7yE7gHA5GD7vk4PP148e7ig4OWJLKUBu6bKCppvczQWeQfACJK sF2/ajqxrJAKZzcrC8f4GFUHOjriFtxLgF5C9LfXf+baobCRkO1qfmloK+qs
B5iT0VxWSOpxmEcrj9sotclBM1duE8PhDs6onGcTDt9b++DtoCfuKHNTyUIM QPe31JSrHVwrkGTykonFn6P4rkqxCjDW73TzoZxxpISgiaDWzhVTXN5ceU7x
5vU5OrTOgY3v6AlATsOcMJpC5xsZXiitgBGpXZpB3ghmM502mrAUkIyI7i8o 0a0gJHkut3WVpPwRNSORKw7aI5bzkSIOH3RBQ7k8KVVKZEJi6gCLoEbc8UG3
XJK+DvDj6Y8fXgXUtH46ui3kSNzfDy/7B6SN9o+enqHfsFrgjwdHgyPtPix5 xja6PvW1pLCCklq5z1DHGcDKHuIR9l6wLtVgk0N/Z6akrFcaMZgnVb0oDn2x
kJs3p+1NzpFymT3R8H2yfJnUCyIs55FaMu0CYPCNZF9WrqOv5M/VkjgMnA+O pTtr23aNgLXGm+IsncrEY59229NdtkiCm2AxV+80jTGWmlJrNyX1dxuxhG7A
vKFAdVbWgmZl2fyMeMsP4eQPfL9yTx+XhRw7fkEuCOc2HUnlkGReS4gJRy5g OM+0bjXKHlKuq24haUzobIlKMd793oYXxGXhmkR1PAxd1DFLGituqdbEXaFP
ovAS/KBeAkw9lO6KkDtUnnH/zeUPH7ShpYLRSWY6ltQjMVgVRl43ig2q0NJW f9ZIF1bQNRvWw85CzVo0EdXODOoFYWGEoWKWeumJX0JR1zoyKLybXRhY0/B3
hBtBJeeFZXBL3syaK8N7ESybJvJshF6GKtN+DdzeWaoWDJ6bc1XMPWGdmFw9 FGsEM1CRLnZTcLw5+ti4MG4LRCrsMjSuku+oDnxmouG19EiszDFQ0+FQjjFd
nQIldL/YQxu/V9gAtBLqSdYNQFHxHhsPT86DBUoC7EOjRmo3kU5Bj5Dj6hqa zU7Ng+GWmtX1wTEYHv5IFuRiAGDhfkOOiYNHSJTDZFS6Hd7SdVqrK3JYPHFq
BzFgX34cIxAy32AAGME4CUELc9PHXeo97+1y2vAvMZ6KSza7larG65QuXTqU 7Ua2Rq98qRES9x5TM41ae3jEulCK3ZkqyFVKZ6aLj4eU53e4Hw4wAcTHK1M+
kzmOg6ssA4oZUuZ5oCHrd5NnEC1Bp5EU3hi8ZbS8qrn40qXxMcuWrjUi0ILH V2dbcrW6Ndt/6d65s5Jt/Iil+TBtEq4Xcg2PcGP7C944SsvMAGqFSHVwR62b
Yhm7qafnivf9iBMssxpAA5xZH9Z0cI1WnFvOaY/c+dOnH6wW2AphBHxBz1jQ AnX21KWJ9Qo7SHnZV6IFNZvRyHVPvA5lY+pq2cD9dAk0WRwa2TRm1Rrd2rdd
3431bBKYsHJWXq24iFm6ivAU/Ddup8XjhhssmNfO5Q97H3ZdNyyFquTyJnxj +sFEA9RvvF+0NQIdbsrN6XXEZ0v0aYJxzrkrjavTfeeX59VRlO8vX3/E4uNb
5+8s7h4jB/CBCzx4SatOcE4vvgJ35mlv07a4RTZqARRI6wBAv0h+wat3L964 rBxpBRi4CFdYF9hSUVovCoYZrpNc4tA0kv25aIy2Xz8+3qihZs5fvz6eBOy/
JYz6TN3fYxOgjhf4yhdTZesJBC6XvinKo2KtT2fpXW/tXO/QxIMuOw4YTAtW /XZjiF1CVb6hw5h6JOvE6JRofg5tGlqcfpTfgDlXJaiVP9uoLbwLVDVcF/dt
XadYJIz9+U//pXaNNeCWFGxa9BgxeaPD5/LQzRPbdcP90MIDrMqbrDDWNV0y LvOtgxAVVmZ2+pSRKKhLDFcp4YL4x9KFY6A3b2wuGyKdAvxfNX8ygRcKWzCk
7ydJe/b+hzNNnfcT7AkIiGJxWB2SDDwY3IwTzT4/ML4OQzu1ndBq2GeCw7mO ps6NIe/IQJCTc3OWuq97VC0VYpYOo7b0sMeQiRIAS6/m+Gv3vx/umyxtY5tk
19oJaV1HyvkQAO5puHAcfIILuFuDJGYH5zM2O5cvyVtZ+F1VmRwYUxRjFDqu bVZX+dMV+DUnZGFsSdKiy2t7r1A4XTQ0EVm15zn2UMxM3B+TLslu9ygYxKVX
iKQd+u+x57TBH/J9Nz/hWSLOWy6BXkfdt44XlkqdFtp2LxBYXW0B8jARPUAG 370d7B53Gz7FZXUPDpe+sTuXFZNIrvK6iED9TKkTUq3ccjsouH9L8w0nvOcH
CZoOeoQb7msYwqyw1seF4F1DbjcSLCKG0MxqYwWS4YsSXX67dMV1SfKoz/D4 vCtEgT2uaL5ErOzKjLXcyH8S2GRUONJB2RMxUIuMuD72HtIeT325nG4HXn8D
9VdVuVzUAmheq9xkHOImrx3OvSK18NmOuIKvWdVeH9yQhSvfRfDz49GCJncI Nq+6Fjs3+52CBoWc+4rswo3disQelCjHFrTaFs4WPM+0DcJpgk2Xvd5Zjjiz
5yFIo1YQyrAlCVmHK+BP/MywuYDr0CeNb1YhbY1jr/WODI6xrScPIVp2PWNc ucZytmXbgT1kzmxk6D+B45Tf246EgnJWbiIhyG/IiK+9022JKVQhgct9nzRt
OIlHWRkLe3JosKjFkh2W1uN08pfuLq10WyoALdKaWZCmXDFIekfjKio+s9V0 ZfuvLA2ypNtTawcc7/1Vn/mX+ov4U7jjhTXDB32G0Sa+s+X2g6ABLkBMoh4o
Fr72u/ug8GFzWvQDY25tL6k/UZVa8O7lha4milsTmLpptUPJ7zSvC33toC/v 2I1l+aULfGcblHPs7Awi4hU+FzsPbsIK9KjUUMLr8bC2G4QLvqW+C6bPJiWB
8o5iXGOcfQaxrdYiMdA4tZmAQ/XqUnqCqoXGURimgWTp1oHBMJZ1sp5hadQ6 UoLkZco6nXkdq+Bz7fjl1zNsDzOLURWtWSQ1QbAeAACvC1CvkK3u/cXzGIEa
wqNoHA7ofwp17yZMC/07xKWWIahmsCi1bLMvY1UsbxiHGwMoudMmrD1rJkF2 eDHdYRI2qTCu0x1HEzabk2i/M2ZTK9Ywqy1sIxtSMHTLbiB6He+8Dc3y99Vg
CKPuMCBU7WAjZM9Gxy1KQlY0rABLadFdv/UZLsGFuq45hgeuxlu4Gqu3oc2b 7Lc1NPieZiaeCg0Y1ITWtdzMsI+ZNKox5ps2qcXYX1gMIJrs+4rtmoYn6DLA
IfFMfImNjGUT33fs0Nh/uAHaDTqydYXjNCrBCvQNJVKrRMupGx7KnKYM9hL2 DhkhbsXfiViB8LPw6pbxsd/3I7S22PEeTBcwHY0h+DR1Mdc0NRDnq9wCmjIq
LyT9G3DNXIg1IgPlhisTGd+dljlbU12xd+LN25PtHUJrB40xTDGtpUXfr5nZ mSNwFJRuOCFvLzreldARm2I+kCp3PAyWkbAbcRu44Aa0BOZeBTsaTlm/RB9T
jB43W42DUjCqSKBLuxDuvDfQOK0HftMq2tZkreKok0d/Vg7789WWyBFPiB8f Fd6i4OvdpvDjLdqJuP8UltNTGDMhI1z1NZCCDyw0O7eKjdKYSKwllzqpCOLV
wLl2JGcufu4r62ky1B8jO9O6Z8y1GwpNmcwMEFa60z+8mNo16VV5B1Cj9mg2 Tsodah+nly5SscVb2nMSLZCvYX/vhhPFVTkOSZMsbGI2ayq0LoeLgW4U3ibV
XO+h00KA3o0T+ZYmjgRGgFEFaLXqBQrhpXwnyO4N3ZGuSg/sa7+ZPj2iL3g8 eh25UTcRJCFkrqyUrVuYjIguYD8fEydk1yzL1Q0OamMT+NQXuHTmSrvT0deg
GDgU1p/k+He93QAxuRxNbQqHhcGy2ZRQZp7cyBnY4alUgAHKrpFPwnTKZSEg DEorZb9vVOxPWduYfqtDIBFHM2XoABdD25MJCmBprxogIIUcwlHr+6CZdTug
LlA8uHzWN2LJ0IFL8PDpNX1HTIcB/4FFJZLhqry+UU+LdsaV8SpMqIPmtGi+ XAnijXIZxVJmAzRND2YjAMmwcJJnvv3BdJGwWSCSQubhik75MEZ0pyM8b8ft
fxaQEbVomCtfUykJWm/Zi25stHjgm8+hpi4A2eKKLIOWEsCzT3NBNV0jIHdr tbzc64dSrU0PR5JCTt1u86RFckMYwBaKi3G7wkR2SO6dbfuCSBq2KcoOdxWB
NfkP1xpXF62hGbN0ktRhbT76/dvL74cXH84dnuT78x+H59KSOSrisYwAgcgc FHErG6IHtiuJ5jEowxjrq3Rwqci5y7HapNoIq/2GAPBOYh8crohSGt8MfECk
i89msqyc3qcAUcvFFYqPPNIY8whm/6zYm/YJsAbXttJVMQe4B3cAD5HfDCc6 D8rp0hqjtBcZY/q3TryvWRBP1spPwWb/4rQbooAJG4Tf353jH1ttMXW46QYi
cwnYmoxdhEixTctCO+3mmNpPSq24qFbVB8TOfPug+lkLNV46CCm8l/VS6Xxe Nmx29/HZPRBWF1w9SBMLuqBTojvOImxDeQr/BsL/haxiPpcSJuJ0J7RVuEW/
+JStLenGxoX2bn/rkdXWyKk0Bw8OWril0zbrY436VkW5aAIur2WUWy3aXPhc xHtlmRzb0GRpP1DxoTQuf/btz6LvCaFpa80s2O/sYgrdUiF5xFtDSLy76XXl
ZBQHhj+xZfrK1ypHbZPSDT4AQzHoVmPUTmA8f2SYAgSGhnWHcvtUWl9bAZwc pIvXCa6tIiCDzJA3tx2j7dGONcwZkJi+01proJPVpgEW3zev322JDMeA2OzD
tqVUgLp6qU1uG36rT9OJ4OFGjKsk3UHqUlQS37VgoGsRVe3WLbhpBwbLprrs B1qoN1zcFDJoOqirLZ3+6BGM2rv8dLsOR3uAmz+sOOPNiy17Hk1L4On5PlPN
QjXjdRVMPkkPhKAFtzmdAvrVVnLIDNpagfOj+QjU6Zjz04OKq9FSkUUVTcwV OkuxdahPvQcMed1qgLJ1tWRntI2rbwEF6xD8R3D9DgsA4H9+wIzYi28P4MfF
U7LKMyLudMc17QYnkbvGtuLeI8HPHzECmXK7eJFYiYO81HaIEaXxpfS7BxkN t8Bx6Af/1eW/ugeY8Ewp1/o/kj+89gfMAvcF/tOF/+zC/44Oj/bxx9E+/jje
c9vXdkqGsGJRnZn8g6rMlFzzXHrmsrX1kwKC6hrc6D2047fp+dsKPqkSgKv2 2aEfu4f0Yw/ui/8K/m9//xDXsH9IS9l/dUQ/jvfxx8Huzk7tFRypu7d/hD8O
+EwQy62zqBGrcnrxPAkaXuJksfRnM0wysDA6TniXoon4DopurafZHXe3EWxH dujH4SH9OOrSj+Ojo9or+PFu95jWuM9LPdylH69e0Q9YGbxiGuthNEeI1KfV
erAdKCf4pH/S64uEtq3qQD2xZ+hzUWQNloyEhEM8nWREPEEk0kFAWLFMDXv2 +oE9vuxs01+xjTxCKjyZMULoKIaYzQyUMEHVvIydDlDg9cLoIeQPZy5cFdzZ
fIBBUAae7j470nxFaJ9B41B5ULMjJkVbWJ3vdligwR9mbtrbbgLbLV2UqzJW 0aSQUbdrG57DXmzkGzo1c6qie06CQK95aeXLJCGHe+gMZvp8uaSOGwUwTq7Y
GsgIuy7DLA2N4gnvoOiqqAulgkKwWclpepnofO4gh2OQyFbtVy2chuxLbswb FoVikOlJ3PXskMLWj541yrXfDaRlpmXPLE+LRmbsDtxmy1o3pS9q6eaZuHNQ
tAfmvt8NO/rNGxy0SGqJb0BvOjW8U4FxsbWgw5Q4fumhUmhMsyZDVuob4WRu 9y5P0BW3pvRGWiEOAKxH8bA02iy3acI/ORkE+8cAyMjbLmdimknN0HdeZtLB
3ewYgYG8oOADAq6XcHqgIK/kgSnAuxIMkWsgJxEByhHX0LIzGxXIQKyGP9lV y/bespsgt0qBU5JjRhvOyPen2465ltIsFVGAbQiYiUsGIesAdEGpuxPag9E8
fHfB+ih+7BoCywRKb16rNs7gF9DH2ZDkel6x5chSNT8Cz8gFMluCR9vAj9Si VPJy04IxhDO03YQyxAzf9ogxJ6Kw+XjAhhixRnCbEaaLRi228Tk2KVKX0HGN
1CZbPGz26jt8P/V2B8/1QAVBvNH6nz/wXB8AkotFNpCgulPfy4itL6kpwk+R ZWQGYduzaAIYA2rTvhrz+1DhmIAilDidr40ZV8/LSJSLHRCkbBC4WGrEQzGW
66lnZBecAY1MMAwqAxDWOStsqkigk3DzJeXKvbBnuFaQ5sjevCrVs2FNfrv7 XRtNQagBY/tXmZ07Tf1dBc1naF+kkBeM+zQoWjTgqGxiaKLAI5hM1mEckOJe
SkRjVNhZvzECAoGKTCHkBQnvg91WW0e7AOhCrjQyVhpwyAtlRu5EaNveWhmM B00emY8OTnB639m0Fan/o1CUvwKJzORbu9FTnJhITgLbOQQTzOlgndtCNpli
EK7y9wku7jLAQYLlPoMFFTXmNoHuaqidHhpqKgFGni0w3Ksk7Bn8BB1YorCy FuXI0HPqNJpyxi/3wgm+77/mEoXjaMjqPVtpJCMScyujGaOLF5yFyArnRbIO
blbWXMWFkmoFnff6bEuA5aosSUSwB/ZqWYXSlSUFC4meii4GT1cW3EJzlsOn RdDH+g8SIpHx27QswEi6eLq2EZpPU4zmp5JX1E5Rk8aRAoWBg/LpsmHYsDLd
DbiBH5ltR8LCWboetCKS51wcH/CVYDiu7FtHtRJgDdgQaIsB4VJBqMAWUQ/H dUyPbvsi+w8Bqz94JT7v0Ug/i/6e6eagDTWcTLtLMSPY6yxRZ7qiFXUwpN9Q
spK21PRkqBW1C3g7xuIgZD2WgRTxqJXmxWnMKCLrvdB2nxEpZQH9Y+G7QW86 yxbDkKYSjeHo0iwRk3ZIqJAuiVkuYrVErvD9YIeTKilkrp6XqPMDvVxYOnP0
5CHkHMXb2bbP/Hbd3o3I9QfunPZ5mkFSgi9sGiS9i2UKfRi8ylohgxCtNvHs FnLEjA7uARl8hAWgMCJUniSh/fZ9P9jt7NEgZx/6/fOeUVxqF0NTfMIE/RpL
VxT1XzwDTt5EdpGANGpOQspzFiw5gasX9mfOHa7cWzJDHiTnMP6QpgGuhpGH isCaQZvu2QqZf0batXAMLa7ZTCMJtT7Eqk26961LKmzotNwp0ITmDFmdZbJp
j/VUE8S0SdQvQ7orMzySiqJF3kgTR27DVhaGbhp07iU9iDPLcSBT2WYIWSBu teP9DsinWkGm1WyJui97onXu7+yh1k/xD3Hpmpcz8t25ccOanzgRnDo8UPf5
xAWJAk+2NpKbLFsopn/grWjKcibMV/hkMWkr4YKZYT5hDr2zQjAvbw1rzfJA ZNELJqA752Wq4ap73nFdyQ3pL9Iy+hJs9tgsh9X7Dw4Puhg1oLccOVxFXywt
WH9pNfNjFXbM7a44pFn4dqFhUEEB89kR6IokQ/Bya8MeuAqrnJ3J4iYwGBx+ xmEXdl3/M73PGliasaF2TB0SvLDWSdaWnBvAMSKPNjXFuBh0xjFD23HwFVRZ
H1/E7QHpm55Djw3mLavBDJw1JgdlLikfag3VWdQdLDUcdwhf5V4wMPIxbSmI VXufjd3NTKlN2yblpzRcKxP3qN5SWzS6Yonb2LUZWTnlQ+P4LCQdRi3jNFBT
2tClpB5A1+gZnL6UZsO+aSmTT7daezuyohSpAOEEeEMLLA1HmCcBLJ+umQLE lK7JuWUcHzVwiDW5Dg+52YUbiaKPgcyWEkOvbZsgl6tRnWFqNUnmdoKMRerX
sJZR0/HUJtwhVwpfyU8U70KyE3U7HQH1bDYz5801bf9ZRgKKlxUdGUTJhxf8 V2NpVdrejZ8Z7bIOIUkQcc7D372etnT7cXk2bL0jTn41ZuxbW0xvXegqOVAk
PetVXfq9uArQDLWrXTEKsHsM0wNiMmZxcGTNlHVSTdreY5KsB7JiAOQ7zjAR /NVNBWdrMF9ZY3pYQUd0vmN7OT9qtEiBs9SbPWnByL8T7f9V3bctt5EkWb7j
eDG5BaJPLs5rrTk3lI61sLiD8XcbGmtcjmmIWgdc9jWBZ7vbG7StbgbjEYYz K9KghyHMAFIkJerSsyWjKKqkllSiSNZlraanLAEkyWyBSDQSEJul0fPsPuzL
G3rLvN1qsu1bcd5oZozBRcFnTXbGpL5mcKgQ23m49/bi7XkC/yQSrqR5ulSZ /sE+72fM7I/sl6wfv0R4JBKkSuqutmWZlUggMzIyLh5+OX5cEyIUTaUzEXRc
S6oTmWnmGZJ+ZlgUZmF3HoSTR2iD6EVj8KEDN41o6DqAaPtEzBGgJb1gSN4M U3rDCVVJbVjWNKeVVcC9LgvEQ5xTw1ChDa+IxzSnqhjnywSoypDW35kGoBoD
iLzM09IbxYE7062Tg+lMFWIu1Ju4nZzOR1YbLmIHDkhk/0/3733bvP/0KYxN gPCtpFqFaEPrQQFDthKEl2315pzAA2GrGPpdS4asS0iL4IBxxbMOVFwINMn2
eOR+QzWRLpuLBWlttW/JqAjqgeHk56ygVNxmt2bV1nkf1UtqAHikR6Ab0WIh uiry9+xwNpy1G8s67mser5XB4gPmxJwAF5J0RvJ9IFPlNlIjnVDjLH6gsXsW
gHe4ZtsPQfC/RAws8kwQK0VvFgQmh1TbnhAbsFU2LzUIpLhisfanvki+gJ8K 1USYJUuuYqrlLe0+vRB7/8QnLR25STmNjIgf7/jQstY39TFTRk6Bl6acqhMx
p9/Ummk5hmzrx3DXULOimX4QsId0Yi10syZMONeEN8MkkjMCfD1hz5Yp5ZTd fqcHRaDJ4Z4A+0tfwFlPohwfIbwSVNRbqsTDsW0bZyDRzwHrQuyYBhhCZuQM
bQtEsgJWGxQNg8U3Md6AsFGBYa0je9shgYNcpK6wKzHZS9qkdh5o4WZB0ojG 27cZJg398ZU70Z8YQkPtemE74gumKiJZLRBjAhHqoEfPG8OaD7mmMmPK0qer
f9zb+ly1VS3n6I4DxctQvmQnh1hM650dNT1KNq4IS26pEUbEsJPvrktEEOBl czNN6W/QX0ZMrqE/BbtQY6mHOt/6MpZ2TY2qY4gurgJ4CI/00BsRA+U8m1Wg
0+0xpdldt/HdRcVs25RINlsqMBwD+tcCWNoIdJEP2lqinAwnV0Hin8b+Ohna aFIbS/ReZVgfaUhWa0BzgjKqjs3P82nwJXH9O3uUvqhaonCLap2eYAA3p4BB
YEv490tJqnjB6FXOd/m9Gi/v1aDZegsVLWVKhRG/WHfmHho5w1pN2CEZqShv gkw+wYI4CoambSeZp2r7zC0/G4oxl7nX8tuBZAASa//wJNvY3nnIIe4Q0Rb3
Tt9eDpOfvoNlzMhLcHVquZyGBh0D6raUTDh75VEIookhHtGRvWe0jBqIp1W5 FtyPW/S/3QRWLZEax/2D7ofy0lgdaBP3I0vqkouPm4isC0RaZCNZ45sZu4be
LWe3gkhkunRpqJ2Sq8Vpdxda4F6wPxcqEU7ii+zWtbl7Jyl+9dZWK4LrmR3H xa31mifCU6ahSVy8sbO124uhqhtI1uwHK3U/LI2bGNqoEytsbFnLZzf//PY7
O4Nc3V6QqNtZiKFu3UAyBQV+IYgVn8drRbYTkelq8gtNT5EhT3TIvGEFpVCT kps78R22Y9fw+gMAEzbWDHuvdSQkL25wf3vH5Lj8roJ8YFNAJz81frZVx5Gw
atE3CbotMwUu7XcwexflB6RKjgVVX9QgeWKjUVxJHlTtYlJx46MgR1kQlQxq nx3XJF0JDYEnjVWFjebE9lo6sfIjJ8vg3r2bZiPpxG5zJB7tfNlIPNh7aNrG
O5tOS2142hjY1k42uBr0aCu8Pu8Rjd+fS3h8ki6aaNEtIax0oFH9cHpZcZtX YO9++0A82gkDkXTinmsSI7H78J6MBP3yJSPxXeVE1kLOLD6cSXKLJGrpxP3G
ZWERwtMgvdjF0BWD7Aqanfqu6yy60zIFGUlVahxdBjJR5Y0sYQijK8qBy+R0 SPAsfPZI6Chs3925FxaE/KFj8vBB65jQUzAm/8ashO0HSVJ3ffDXwTVu6NL/
ktqDs9IA+S1ZdcXJGdaVSNsiq4s3TuSdlVf5mCQ6N2/0joOQbuyyWU7E3sDM ArMDB5bU32yHjgHKXIly0XX5uRr1GOxoAYu1cZLuX7uZsElIc5JjzidazhUW
TBHNNJSYd6+/otav582N+9f1PKSpanS+GiiOaHBE5CxMoiTjqzPFsM4l06CE ehwhYlj8Rt2Dv6u23MDudRfwHZZZqdzdpPNfIWRiPT16uA2j7syh0sYGxJiu
V9og8yRu7AWqBN97sX9+LUky7E6t2R+z9K7Whq7aVBcvSh1sssCe4Wncp4Xh 1pyvNWgQC4rJyys+p73MuqSDmYdlpU1LxyzleMNBQGZJC+7csSV0hWGxa6+t
XtV5vesSLnuubUVneiiu00FLruCduBokOIWlIGYSAi139aBpIUijsYalQxso AL/YkJ2g3TOpWboWWsiD3K3lKoM0NVycuAQNNKBJdLJMlEFAEqrWw5s2s6cI
bvfL6f/brj446Cq47aOPdF7F2Wl9BlNdcAcYC1eiNE75/xu7liW3jSu6n69A uKu0sYNIrZPVOI25C2MAtDGkxgO3MIMjMhGS0awrZhphgpvrjqN4jPyb5YaH
eZHEVaQqsuNIViqLeXg0Y1nyWLSldQ8JzsADAiyAkIuaytrlhT/C3xLnv3LP mM9GOdWQG7508bHVb0/SAfPftR1Bn3Wi3HzN13zrLutIQMU2+UdIiD5PzSc+
fXTfBsE4K5U4JNBAd9++j3Pu0aaEqYcxn+Tx1oLF6exkRjmMZupHNvN463CE P+g7RC0yDq1sP7irUY+b7qmTex48RISEbtldewtJZ0RcED95hGjK7v29vXu3
OD3WD2RFKs0fW36vDBuNWngaEqJVFHf5GJ6Q1J56vF6b6myl2x0e4DBxdiDa 3lMn92zv7VjYZ909kHjhTTiIc++Rde6mm+r0pp1HDx5xHKdNDjTrCpaSBwTa
kzV+iwUNSWYNWtGk7fIENhyC3SawGVYwVZq5Ppp1MLzELuEeBfuiw4MTKM20 Lu92n65PLuFlW8CBwFxf6aKr+y1oQ45bBH6hrcZWWbPyG5pYQ5m6cS/cshlA
80osqicMSHWAEYUwBnH0OG29jHmZOPlRMhVm7a3kxcyfiUJLTmlyDBYWH56F Db6uN1+5Mb5qR/yWLWE/2/6kDT9RBWt++fDu3RatwN26vbe7c8PXWUbaTEsL
w2sTZJaMoqxit8SRS+CO3vdI+shB0ZRZwngZwG0Yeq1cZUrxGV77EM1kK0Ew fNmt/Yrq4Eq/Hj24pV87D7dv+DrL9vb2PqNf7t383SvaoX25vbu9MhzJrbT9
jdZYFeU+zfbxKRq7O+HOqeefkDLJbr3a35bdgh5Ya8/51xYBOcDHR/5XvoVN VkY06dfOvZ22Ic/WKZst8+iGPPRr+2GLJuv7dW91ppN+bUNSfmG/oja70q9H
lg573Qc1zPQybEvRM43Lah2WO1upIj+qydcMCI9BrlBz5g1tNuq46qeU1zEs 928er3t3b1lfu7t3H93er/vu4/ir0y6b/XrwyL1Ky607u3fv3/A1L8DPmMf2
+uP5PWCIj4/fyA1skLCtoiOpHZG7UuC5HA4oHpjPsbgeVDZkJSJj/n4JIJ6n fjkVuNmv+23byd26u716Qdqv+58zj+39ihp488ud+49umceHj1b2W9Kve3s7
HGwcrxVe/FSGYv/9DP+Vgr599Dkjv8zQp5q3lAwpzMo3inw89pExTqmOjjof bVua+9XIbioaNepC3eQADtzh4ApHpAUsMLnu5MMhsg8cwc1PplGZPyoUT5wX
TJu7wP2mGXDBNYC8LaW6BjAxGzpS06TC6GEPpzqrNwUcKOw1fjevUNuB02rg SvGmWF8F4OExed2xkszZ27m5E7sb1Fzd68KvyDVBxIGHvLqEzE2xjnS8wuQH
Mf7xJk1OY4afd3NiAAYgRsW95jMCGpssPFYLfddhdhOO4UDEgXvs/SNffSYa W8tWJCDJPiA/wHmKmc1FWnaXuVqGNzeHc7TZnG+Hk6juZL+9kdU+ZR/v+AQU
HzooEEoNCBKBfK3tIM3ULYi7ZXCI4QaMmdQnkKr0akhucoL6RmKKkZssGuGd 9SbayAXMDvDpmuWiDOAO+Rk1iMBi4/NNPMi2H3Rh1zOO+yV0MRYzNtKF8OjR
3VkvZCteslhiJU2d0O6MO/9bgkcb/gYOCQUrtEFBBaZMrovPspmeaQ92GSqH MoCXPBT7yxSSEG1J/Y0WqylT4KHm4yBOIdkY6pJrJoqoOlbOUROoYZI1Xtqm
VtuOZfCkVtXRCkE364hyrbqx1ZbFyBhwYW854SgRPfbWi6kxTWqfKs/MGHZR LdG0Yv6Hvo+Hgq19txtVrL+nhmU/B2lXkqu+wPv1+ypYfp/EdzqiM/+XF6+e
JTDKtBVzGcoiZwiakEeaDS+nXIlaLpkU+9pQR5OTT5FkrZ6M0mNs6LhQgT6J Pf/FrEUn+/ZWTpGGZFw9/pqKTGsLWZbd2q/7O9uxX6pkRUWm5fzzD25Tn9KD
ddtC14C7m8OF4rtMJPTTZvQSqGH0NYRkDfg/TyCvAPZP5J30Yk1cy/MDRlAz prWF2/v10879+9uPmgNm37YNx28br/YWkn5x99tu/scrylHDaunXP1Dxy1ZU
bKRGwXJavZe+NMeZ56ctBAa/5rKNQkiXyuax6Hp6/FKm0kH6hK2guugsYX0C O9evv5Mis27A1JSdMlfw7aJzFQp+kxztrxOin2em/h4ydL3vJvv/VYbKz/HJ
9qH6F8UlVvQsU2/QWRIRtX4LL9ZgYvFZ+RWRzeGO9ZKsj5Go6wEbBy5qIt2K /s7dew/DaMmPStT1a6XtgtTmam3BRuuWbnGuwOAotBEke2vo4DdJ9rXBh9sl
HOZVOdZSGaFPqkx7pVdgm835THI/elMVQ9/dR01iXzGzsq1kdGdJf9k/blZj 1Yrt/HtbztmKiOSfpuX8exvO7fJzxUD9ve3TdvG5YqD+3ubpmm41zcDfyQrc
Yu36tlnBOAKcwc3bWuZmoEEw9gHgJFYPdISlHbtyOix+10jOWm0mvQhNmOdj Z5qS0aTIHZTTRWz6URNuCGSV65ptM7kWBt0U1ao5zlwLKFWK66jx1xKcvlmt
gCDdoWZlXoxLlFO71GGVJHLNOm7D6E3EnNVQfuqgH9KMBR+s+TEACcOu3XDx N3NDs64cLalrR0yHkTJ2WXJzYKFypWLqFQ5+xi0YSDMpdG5oxuwHjR6hHMyr
ZuI7+6g3eHLyxtYyn1wdO3HRZI5MdTzSUBxeaoP9P14NFXYXYtcCX4xvvIJH ww87PUGMff/syJLzGEXIVCMBJWMMDhGMBVZaanoClJZClD1bdW4jLmgkflKo
jQxGJxYvySUmsa/JwbvdoCJobH4iDtCspslemBkfRct0vn9NpqmHtI+czpc+ 3IqSr2fz/DxySsSaoso6EPAjXMmFhpHu+eVk/5eX3708DfynNJyVsUdnyn5b
HIU1kjglacxn6iiW/EGJA2lTLVqxIhPLj2gXzZQIjlEImd25FtcivDrL9rOh LwvUJWLiIdr4DBcMuJ08En0PryO3qCSOu4LeXGSKg088mJfFmPEUNpjdUKde
bMIH4UNxgXT+Yz7Yg0XWlCbZeRCQOifOkCiOXHu7L/y1X3gEUdip08s+q/9a C8jouxSe5Xv1JUN1j03r4O4DkO162B69Q+sjmQYrn4PIVIt5YnwTMtj8bKGY
HwEwX9V1tYVHcD50H5BCo81Vzq9oMmmmZoUJEPP2/qHhrMtiJ1UXbXG/VmYl MjdmNOrxgmlIotAO/rL//ekLN5xWkkvXk+wl853sbe5u7kLx+fjx5GiwTXrt
dyVf4ip9pCbqj1+WHQOJxj85Q9i+bVHD59+RU0mmJ8yKtwNZmiAbXOYxHz17 YPfhQag7L2DV9Qvb1jUz94eFlbxBzGeosnpGY8tYXwM8z1BXYhF4vgTeWAuq
inJGwfFvwtQLiz6CJp36ajfE6Xev8K5ub4/+VsinAKbVmfwVu2UclV2vHbbL G4wtHOtE4vCkqjmuNrRMC6ZV5rsZioPvr0OzKNzKe5XBt6VUSrD3EGCNIK0N
LStGfjqMSkpUI2rHU4wqpTOJXAXVzYT1DVRfy5EALJvUJeNssiK/dAhWoFYs reS7LGy3cC28U9dC0yuycfRu67RnnMwnKm8+3jl6d6pRZyVNlOwBzGqkyrBE
vGULLUp9IFc01DS2kqwHzgv6tF9XmizIf+SojnyGsBEhN1nikAxmmrFJMvVG mbJeKIet8pdbjnTCyl1ODWUvaKYVN0j0QBjGKfGKeA/FvNDKL4v5slaeDuOA
OubO6BtRxPZl2BZnqvL1P3nCzl0n5/3mCGJSGBcmGhzfucq8dKVUw+VsZJyX ZwCRuTasnltIeVQmi/YHRxrtY+V1QDGyvkChQN6L51h/+OUiqaXAlG/qNeD3
OJP7xEnlsEMr4zFkR0FoVW5Fx09yV6E/wuSVLjfjWJZXvCI1/Z2VdsfhWFpc NHTK3AWQ29B2iwu+x+zwlCmTZQd9tJwKa40n1yxNlw/pEby2q7MF/5Ey5ARI
sIi0I6YYrYV1RKATdLeDNK60s1ZE5CThVh+8UvVW0B0572LMhlmhzGBPVmBU 4AfJO73I6dJl4K25xHYIyX8g3ENaA3fUHxvh5ZnvTemGGGid0vEMl+c1p8YG
h7n0Xcl/PkKaXg1apLsbapGzccnWvC53eX2zENY8SPNf/B2keSgcnF/7A/zx rCXLb6l/JYehaxbT2D56fYkw8/IfMgy2qEEEwdkPPu+G0+hS/D+2tBSDjpCQ
kT5AbHmVKg+RDD8uY7SmT+KAdCnDcYSCKoRIDTsp0I4cD8Sw42JtlGWQnWvs 6xmWgkIPHjySLHKpQMSdZDa7alKdXyskb+s0lMNTRlROIOMvdPscpGWkZP/c
5FLhLkpQiggItGsA2XoTqxTkxgWoYqeKThwi4yobp6hg0FosRhVFBSS1FXzz cEEkh2lkYl7SeJxDvnKvuzSrHwD5nYJy1OqB0B+Cy3jx3bPXYQaSgnMfP2IO
waGQnICpdxU1boSE7DKKEtUc4GHTWxYBF/KDaw6QIu/G4cNWEJJnbLw+TDpk kSUNHu+XZyqYMxyenFyolKJKy382ya/6K9tyg8SDK7cVyOk0JTiU/wYI75/q
81zpJMemVyYiil4o5buMN8sdozA09Vt4hOixpPDguRObExeUvmQhuF1bUmQq UGAH/kghQEatITsvtPOcfrv+tXqhs6cN2sl59b6Ymtw5W7LgpqPy4PjdgSYn
mQkEJLODTNUhYYuFtGkVqCjofOn8Z7650rFmCaSevTzWuhBQmGrfwbZGnqab xNfrC8WKMp1Yopd023VuwtA93zGB4GFYqSP7NuuNQp2Gdggu4pUaYpomkzOW
hTTrhviUhmwzg5wfAaQzQlpSS3qq6Tuty7tAMyLMy96MSdUMviY+MQBddZEs BKxJC07Bx5bmVPhGl0guwcmMdcnZYPJUPqfO54WsbdMHU15Dzi+l1XgQynoC
oryGlb8Sx5NWzZ14bjYq7M0FBDKI+O7JT5n3W7grDgah85RaQ2ZKkTffxZ+O Pb3+/sdZ53EmTlrOKF+txmDFbgycnk+l0qY/Y9rqRJQe2u9YVly10UgXxAVN
OUuRhSAvQByLEXGc6wMUwZXzTd3PDf2HpNsG3OqPfAPoSPdwmpSjxydCJHDS PWcNa2mcUt/W62YF0amnq19MaqvZKIhp0GTyw6U2dsg6QL5LLGtwPq+Ws1o4
F0TemFdvvqNcTD1miiHECfXIFCEHoInz5d48EO5DfecIYKNWmkJQt+SYTA3g 8ms94pjaelHWofyBst6sSoCYAaxVfrgWE1MIyFHNzaPwVBlY8z31p+ZjSrcF
T/aK7P04FUsfwGYolKgcLRi6o4UnAWFw0m5qTcsG6l33HEeMy7VRcokkG6sw 1K3dFeYtbtOXnAjlOKXc1bUfWhOuKzVj3Za16eQuJLOuO4rTUNGUpQWxw4Y6
LlLb7TFOP/VicVA5KbFZB7ZPGTQY2woxfJLMdVlvNVTHO4ovSMJ1LW9VTay+ i9Q2rLC8HuXjr1hdmjm4VGpjAMX50Ms5A5N0hEXIUbllqelrxFT69p3Cuy0o
SfnZvTqBhjB9w3Y8LWQlPR17YzOUrwTtIctw6qWl6p8yveA2MqyFHnoVZcHJ vTd0u7G89GAQDVhqKNSqsGKNMPk1djPzHc9XQijQ+sYiQgNJWpvG4RI7FmHI
fdUOLXGMmbelDfVWkVeYrZaRCHj+LuOOceiUo3Ns+xKa2bSjhl2pG/LczWKS oJoH75sVqBDGgv2e2HlRjx/JlFhFwDwpHeKJR3Y26T8MVHwxmtEfEGdaek5W
WN0ocPf/WmDGc9XEwPHbj4WYY2lKGVfZmzkgnvEB7FSFIqgUE/AhdMqHOudq N/i1rKfPk0l8iDCHOzpQcQ1dWGFWTITMA2YqYhatOhBtyOJM9lWC1lYKMUdA
AIVJrgMqfIpqJ5DohnFXwCZfXAky03VtVYyDqX1yI6f+QHU1BopkTx9URPuQ NWtPfLtZGnB6c6iNEjnP8RDOYuuvqeFo5EXjmJskXVkn34PUMzHvl0WzPkuh
qR7BgnQrQYwzNjgDK7neWOLuLMO2h6vlZRj8Za0CZsfgGplDPeLUoLn4287E NW28krCfJK85JUIHqZHcFnSISINP7ww54quTkk4Mwm9OYRuS7fCeMzq5NgBN
EjzZpWTaMP9ciScHs51LKNJJCmrFnFuT5vVj4yRjxtbPzyYFS+G5BdQRGITm c7GiTmLtpGu6L6ve07LbEofipspiLQU4fy3MlIuc66qwV8LrRee0lIthmpNN
KE70xqptJdurF/09KZ3GiCU4nLcNHC+hMe4ynGvrx8CeJyZ/4NUB57ha7w1c DbxGtjzNPm68rOVqrQrjzzhv465rnrzJ1k9bH8VkSL/EJnRxPZj9ZaACZlEg
Eld5pRqQ8RTKzVk6jLLjLY+OLC/O51IePdMrv+fH07UghdiEitCFIVT41Xgm a7umhWZ1Vy61Fg69MCn+GFY0kd8ylVos60V1BRaoZmfWXB/Z5jy789r3+AO9
N2WQ7GezL5JvNrpE1uzJCRj4Swko5PTN6UE1/PuMDgBMRtPKN3MkMl/hUhVZ N5CeoO+Kn5pPxxNyxSqv7evZ1Oe9XSiYP8rObmvaGEU5R09V+MAOwuerqY0s
3uqR/ifgakQK6+TklAHX5G22XNTSpkzj9MWiFAiUj+lmxWdoemQBCW2sr+nB LrkmO4jlc0mLA7XfQj7xoNLlVGhtoDtwRnGswFOgfp6USaDHDMJIhdIAp3zc
5zd0KFXbbVmcDhvyWfCn68XZm+LLZ8+fPnv6/Iu/fv78b88UO/0tmY3C4sdF ARI4L+v36tvQUtbSX6VZDdymFniPbYEpUvOoORk4lzyp1RrbKKZIMwOR+BQa
WJfFX779bvEp2hmoeBv9Fz3PuAUIrahmrsbW5N0kWqrkKPc8yxyNoYY3Kmvv 7wwkNiHz1FUaQZmDvBRW2JUB5DLLdobDm8UpVysc13weCXS6Qcl58PbN0duT
sifU0QDq8OeebOcP1zcMh8DLesktNCi8wafz9y9pNJbhZohgJcKNLrWU6A3c l6eHNxJyHh9+f7LuChZuLhHKov1CSjoSn8p4OQ+6nvJrLWfnSOCK7MYsL/go
jcuhH3EDuhfaecIXxtycLoF6r8uV7Oz+5PGFkAvK1T8/WVP4WX7yr/F0a1IB YN3dNE7wXYQCtSET3FFHXIF/Rf4yyvEiINMVpT71dMSLhgm23y49xZgzMy3J
IT9sGxNkAMMi36FCbxkgzjAdN2Go6QhZr2lFc76reeDXdEFffs/5skv0Q4Bt +I3BroNYaap+3Kg/ILWmlB3NavK0tudb6XSkJB+TFYQNoRtYi5/DbXtV+W3n
uJjR3+ky76u7O87PLgCWDPT0FDCQ6ZyfDxSkkm8zo6s2bV+8Iv+O7NED+hOc 90De1ElZi/6gx7poBQG0Miwto+9ShF5ibDvDnEQ0fRUTvpMKW/kaG92YINo1
0SQu8JM1/eKcotZZ8bqsl/fQSDwtsZ/oS5ehfmiLBVgWHx9oa1/QEbqio4hW HbUNuDoEgLng0aFuXYGygLknYxqh7M6l5NGGJLN1bhV+asTgJOx6Q6amkioz
dtNyDHdFu6b46uNH8mFLus8Zkq0QZoajtFi2u13xtoVRuAJUpqLF03GeC+Om dSXqSayBsalzkeQ+1w1O80C/y7a4rEK103UW7KySihrF3IVexSnkxq+2vE0W
9X9JZonW/Iy+hA1Mz7ivKwofX2N3n1X9fbul/4S6+s9voXg3/P5r1VS//zwr 19q2NM1boM5HDOt3aWrDpVKzKhlbyEhl9WdI4uyKiQGMkqMMJazF/UZKAH/E
/v0LYP3v9s1SRnVLI2prYBwvKpq9d7R+roa7VmR4aYTk3L0LyIshQLW0kFKY BG4qHtNJYoUOh6dWP01GGl9WZyRseBiN2D0myAqwWum8Duw0hHefR3LFsxiF
eR905YdKswUS8rKrdt04F0/8KjDPW+A+OWMk3jHdJy0IrSI10eRpHcevBZrm UKfzozKq6hy813toxXep/a6Sd+qRgVxH2RMko+siqbmsR4N4hoRMMAsnM7+C
Vx198OonOjsfyGQ/VE9O/guh4D18vIYBAA== EbpBgtFuwqOUkCVW0QxTfVZccZEkocakdm0/hVNQynC9epnRqlV1qC8mDH0u
Oq3xutGhEhhjxwWNnXA6aSdwuPEB60s/ncJkqJwjesB+rphWO2DKPeRr1Oxq
yVEAWl+36xNa+MMivHY3vEC3oZdyGsu1xhp8eXWYot4QHvMCSq5KKpEqrwab
kgwLLET9C/vY90GCVnWcNP8asiy5BLerA072OS1MYaMwb60rtdU470FdGnTy
VnUmxM1cpTJxzFKjkq1Nr03GqySFwgncuDkIAiPKQZ4MDrh+xtA/Ya8pnV3A
qxICkRNHx8kIVEPOQ2ZnM/K4wREOf29Im29jRlIC3hUWmzE04LJWzZwZRKCb
s63Jh7vYdWTMmvOA3ygEKRsHj5QQwnZlVUOLtXG32ese2RHZGe2ajWwPLpRI
4ypBz/XNxviMXCxHA51TV+pvGbLmL0lY+C31NumgC1eDxg2YRJbJG+uS9TtV
I1AyfBGVk/UJ3/24GKEvcs5tCVzmeaW+DCvp3V6cJOmikqzGZVGnEFYeIOSW
LZUKqoYRV1tNRMcXIhfbQM5TPhmrzs3yVeSTUjWWUh7E3YaHLB2XFKz4Ccyp
kdd47EAPiedBcfWaiqMZtBmGT5UOe2aQQTGfJGSsi5VVXfGy5JpaGD09XQmA
nFcVHRHsdj1fzv3pyicFHxJ9PbqYrl5lcIMOWzZfV6Lm4OBE/NSdFsHqjdQf
yXnOBANOrrjuhFx57dW10JPA6EDtFZwuc5wqMF7U27GcSwV6ahlqRR2C0kGw
BAbeSAghuG612eJxmgqKFYAvCmv4kZT5i63CjYMSh4AYlBxk2+jaZ3G9dnt+
sP7M9fduHzEclBALa7u40eUjhT50T1Jrg4dh1NC+4UkU5V98BOG4ScwoYblU
+EDOryxkfML2L8LP/Dyc7rhkcbyZHcJWBAADQg09983GQRPOuXFSkkUKbDPB
lB5Es3IhpUC5mF81NWZYV7yZtCDGjGM75rLIECxBWIizOIXgbaUn74tipiUR
nONiUVUTkb0iJqfjpgoutCPmBp6O+6YQXFYfjK7OIB6svzRqQrIGu2KxBiPV
qc283aTuALsGQ4app4C3LRN9h/OSvcjiXDBGIX4qX8S1JumbfiDgda8vk8Jy
nPWmwAcv2Aw1ieoiKTaXGxs+TmAVYbAyyhGtLJy33smkPqhQ8hsCv5Li07EE
Lg+irrjmqmR1KdED/AvwuhaGHw4Djx2/4ZhnTpl2WNOoaY9qNXYvmfwTuUFx
SRhTLFxbQ1DHTSbq3SL997KYFHRG4d4aNS0aGS2aLIFZ5gh1HCB2e7FYSpQg
HgLJUOliGXXCMtrc3EwmsstOMBaanNfyAREZlm9SquRJp3MgwpLr9HzldkAT
t+yIWzYEWli3Jz57M3BBoa/cD2jjb7El0M5v3xUhw+d3mROFxCQzE2ZF47gr
s+RgIZeBxm5VfrVMEa7kFr5gasJT0IBNTe93nBpOmlpfbSuWMM264lGqBV7Q
NQ+TcU3URce2fP1ECkWalmx+yNra4BOV9KluCp2In3S0NDY+KhajZvmt4AcX
6g0Gcigpbq6Mjl7JxkRb0VZ9iU00Q8JFinkFUjQhsfDUVTa5ST1QhSrJk2XR
cfkRHwlDV64uKoQOqjnvYKWUPKPpumiy4YtG2TQhAQFbKpuerHxeT3AfsDOc
QZQamzXomnSq1FMjNognoAXpo39/w8/FcnUJj6gF+LD283lQTpi6GPa1LDtm
mZDhQ/cCk9jRu4OB6lGbmUXVVBmzdhcV2pjmHwTdwtrw4M80fTWIex2yKKiE
SmYKHc+/ycsz5yFy3Wb/sbN0xw4IliPDL2pcaEbo+DWf8M4dhqQey7C2eK7E
MY5y8VgkpEHmnjQAqZ19pvHDhuNiBk4dtfUfzDVMu4gzdnGwzQteXIY3Cvmo
3AKbTi4u67gNhG6wCcgKFX6C0IMcqEbURSUGqQYKH+22B0a66kA3/ddI6H1U
KHpkzWr7g8QxLIJmfJIIzV7QXNQXSlMWqz6cbL15+eYwQxwOOOEf2U8aV9XQ
R0mk6itmhffKVaTo5i5aL2iRbp6TwI+x8fAGSa/10YmwT3R+0Jf1XWeicysJ
o55V0dO7+TeRVJ3AGkwj/i8fj2NV4X/55EVOLOdj/GZSgnw2430bqlZrVRXn
DozvrHyVAGRw+CrQlrEvANaMiTEyjlHHcTYTJlxc041dEGpQsW5mZSFU1uIM
Em7GwGDffCHqN5JjLysFPyjlqKtGoYWcajml1ceE2NeZ1SENOpVNINfBgPMg
edVToX3KxS+GMkYLnyKlUGvjK5T9AepdOcQNphucON0I8j3TkCXMQq4gs0hp
h8QuEH72OnEjh+ogGC+ywjlAttUc6doHnWektMwM2RAeMuD04vnyskYQ9tYz
7isOOA7Efu3h9pUnWzjWWGA/FwjgMz6EQhjurXrijtU713kDf0PO4+SBLKkb
iMtplcxzOebYWmJvQ895vf/m6CT7sZqzV/hbRnchXwBMjAjiaZK3AmCCFGr3
ApoCFx0jMjyKaoyEz1eipp0proym6EM1+SAEheYlqozTW1DCjPt+qYw3U45U
QpHGdnxWfAhVgr8TjHnd0AuPrMTjh7K4UqsVhtZFIUE1rDASH8qrI1zQcMtt
sPztvN5/ddinZ86LXldtHf3KNHdcwR04qI4P0/Gse90nDR1QeXVfVqdA3Y8k
jUR0X3mrhYKPBIeuRvAYoCpWWVy2jHAmWm2N4uys0kLv/ABMo3bU3uH4sKdK
Sz7OZ4tkLg1hXAVqyMHIDXQx/VDOq6nBW7xh9I94o7ahR1uN0f/bvC0rVA1I
XDxF+dVc1lLfpSy1pqRqENxpO47qwBOlspy/UDZlUcMC8dM08/0d6zZgiSjM
2JomhDKd8AXyYcP8UYHaOaQu0Wo/BTE8GZk0ib3fPotfvCjD3PUEq/p1i3Lf
ZVQFsKKy4Z7D2FQEQF0kd1o+BHP6CwtEyLWi0XotU+sLOogiGtJWglIYywRQ
B/kpxfycca1WHLOvJ4IEytOMpUl1Xo42eQn7AIwfOg58Lcfit8WbmWFcKDyr
bF8Xzinmjt7ZX0aDi/rSD6l4xe5EwGYKC2FYyYHPFOl0TlvzKOpSoJsVQvvG
3ixAvKjACZyxn4IcVjJBqnkzCwPQfl3sOOf0OXko3yF8u2hMvSbQfhQB0AtZ
JbFyWmsODK7TTvOhwRyEtFUE4YOZoHPLV/xoq4PYKGWC4m6Wu9Ra4VqSXcSu
tfINrb3jXSwBY7m1z0kkXGDCKhcgHCtuTDVqYy0N1htDw4JhnvdDKI2zEv7M
+gUGHXo3BxnrJcmWUoPwFiMt8kt1+vI0xKwdnqAJv5dmMzHUWUGcf3HjkOk4
1MrnOBOaZbzAavhxpW5kQjgcQCESEFwqjIw2C1eYhYUgJVgEwEAaTjUT2sdx
hYQN0hHWhnEMirqIeSICK449FfQMYzcHiMQ6+K2meeRiVHDgfxQCW2HV0TBd
cD4aJNqxBBZtdYRCn27lNLOhxF4cF8UMJsIc5qkGZWUFu+WNcAyXlblA2EzO
jmmRRNxHORI4EdQTk9YeZtpgSEhbRYzbMpBMEOP3B15Kw6WsrAVCUTw5Mk0L
YwWJrFfXw2J+Qi+shWfTy05yBFE/fuR/5SrkVUadUjfBBBJ6lM+wjfkk0zV1
lo8WtkwXMM4tfp1k+qGTY4D2eDObfLqhTj2bcugWfXlw8cmgiK/lGdZPiFap
fg6vKpucminFR1dYB1qyruU5EaRuERqAYSHp32jK1TYyR+KfO/hTOmMf7TJw
3sR6hAkKyoqM+HQzyMdNSww9FEBZg9ijXbLmXOiEQa2Mm0jpz1UPwGa6pPMz
TiNkHG/SAE3zO5+t0Gt1DJm5oVY3zT/38fZtGa2RJCXQzYZhPpFZI6YCnwio
686lbifCZuJymyL0c6V0GFM5/yFdb0ABS5QFVa8FNoOy1NzWbCk1fMxDIK4l
g1pawrWrISzUVdH+ihlRIeXWcrbN6OW9PLciHAb4Un20FAJRUOtyySnzHWqp
Ca5WAN1QENeXgKJAgknj+CyZ7r4WAJL+shU/m3P5ZcH4zGmZoJZKSAkq503x
LCuS0+MkM92VK+XDIhFanPI7jVz98uKc3icVsYxGxlBwDAG2Y8KlD/OaEhVk
dFEWGkUrHYPYeZVPgqRJ50l8opsN5yvLNwZ4gJN7UlWoqcW1daA18VNagBBx
RyILALm4AolML4P9P0Ve8yZKeyGrOeTT1iJMXMGdlUzn6fJSsB1cyrX2NddN
Veb5qTLJGTxjuIum4Yw0S9kcOe39l6pG2kkfNRL4PB0hXBuLtSJq7zmWdT/x
+OssSe3eegbF1fD44V15iEjwcL0kgTkEP4erNxA6LpXs5mPSkcdFs4xfA7Vb
JmX/as0gsDnvi3tRHyqaryxWRtUkSCODu0kUvJ/JoVSlZQUTbM4mNPYKIcR8
DFArcwVXnLaKahTYB4Dhzo1pLiZiL1h9027xWDOro6Ja4kBo1C7tA+ogr9ZK
T0FMkYbDmlrFl5B850CM+u+8iBhwJb6rOWrXTZvFxqzSBpCcy0V1ybCXlmuu
Q5nrTuc7W8t8fM1ZFQxysyGvmWG9WGhy1+cshBIbC4ZqhgvDYJdQoOEam4uw
iwW6Y4nZ1n67jaCld1nyhFwLE5gGjzMx3jCN6Xz/YxqYeu5tTwiirwqm3RBJ
MzSS2OKPV2JoXxxAy1YsT6exGXDXsYUMrzPftqtqKGcia7isoPrL6oAXFvIE
MStUa/h+ys6Vk4XAULR40pnSQXCBGzoMPhR14FPQm78t5gyvbt7yFGb4rALC
ke+jTpJcyfvZ8ZLESC67V2Yq7SSrgnIAQZmf5m3jErQAPcvrcrEME+xG6nxS
DdfeK4wZQOtPkrKqrHiJmfX14UwrLc6mqOS9MUPPJR0XU6m+M8/PLfuDwfMM
Ps4c8NGBQyMMKVlNoYYcHD/LCfWsIMGAo4A+rc9KNf3TmxzYgo8H1ntJDRbL
Ism8STiBkprg9WOa6nJsb5B9m8+yp1o7lvN7nNpNSvjRmmQRSTzVgYwjqwUY
5oVsPjneGOPOpBrKlMGGgyICg5GNiOG4mEkBaPE15fUafpFN0aYaBigvac1P
CQ9dBIYBtqHi6lGC4Daejcw4nuj8WywmxUALn2geSCsNiL5zKcclsziwp8Ry
O/uZ8pX4dE2GZZlWPi/46zVULuOlxm/PlxMphej8oxayff7y6ER4e0Dbc38P
tD0g3cj5cdkBcoReTscg9L/ONo4OXvb8gfzxI30C+/BFDFoF0p5mBKyyancu
oyC6JjyZBtnFIb8V9mYzhB+Kd8mmNLaUQuG9i4tYC5Ctn+m0AvnLZYhkkfqV
1wslpBIL3brCiSRTV3bLUomwDCWRNkcKTiX5XCtiPR7ebWMSKiMKKYrz/rFb
ZzX/J46mlP0j/XXCzqGQc+wQ8WOywXLOBdSXiSdk6tZszS+ulW4B4VDAFp1v
GgMJup/We6HJgS9S06EGrkCxqI5YbGo/W9tsG5daZR0ZH5wZbaW/Yi6VEFNY
lNLGlhPoTEfjh2sqej8m5SWDxwXRBASv9ZIhOAMZhZuFOOuW4SLksn1LsVuT
gMcZYeIJ0gNLx3RSnOc0I0IvUZsYKafLwlMJrHZAV13IptU8zrFvie1AC/S3
vDeLE1bFchggsNQuSNMY1DMoHA4co/MUaa6T4uJH78KtzYTtkHUpAyA6Q4MJ
B558MryKweWkHliyAxxNl2CL+ZXbH1UI0g+vjZ6AT4HAUUEXLGfjXI/JdEM5
U7iZJA/LJJ80JA5Md3Vxj65Nt+BqJecu973BCi6EO+bSkpkBmNJGyIbHFT73
dmcCTcJ5HxT2GyJEAsxhV1vbkpb9UzsiQMcJkNbPS8tqWl8lwTQWZ2mmJUZ2
OJcbIIeGkcn2OEciMCRytghJ62IyUwsbYxQGSKxsjUOV0xAmE4SCGzoBDXG2
qm14WseaFL5uxPqIMwkOSFZh26DFMJ1mwkMhZKgTvbSel6KYKm9c6GOiSSk3
8DhQKiSrpZrfMJZhwzjc0to5tm05ho1cDpeLQvfjgZtFXWasW0qa0mctMKP4
UHt+/eM1DT969C2IpAnmycisJObz+esqT4YcGkzAh3yu6d8H7LufPvZk7gek
OpQLyQGbMhgPxQ6evZBUFEdArzAYJbYRbkkjZZA6zJxtZkYeidP3MneLVTae
kBVBj5IMOU6FSmBsjuZTtJpRPquhY/liXb5ZC1bZKXgGh5+ecCrQnO1sR2IB
ipCROMgw/xxKJ82yGoiRMRfP0ZgzAIaqkPu+sW8wYSRKjyaF0eG9BfeTMzLR
ZXTTiJWzUrZXLUWbJcgZrJHc5bdZxzEIU+NtgVZtlFPsBsDkc81ixo6XZ9eG
PwqrvNSKbOEQSsVZPIuS0y21fMynzcfSM2Cxi8GLYjK55GD4Bb+ergUJmUZY
gy4MIQcaN2fyssjFaTm9zqJq1mgioaB0Za58U4IU2v9ufyVufZrkPwJUMa3k
ytzwuB0AsKRU37Ee5RixY6uU2unsc24Z6ZkVR5+UHrLpeuieFIKL8zZcP9sB
/6JIsC421R/ppQdHdCCVs1mR7S8vSV2phOKIbx/w7Rydwd58SwIjxI5P8rMi
23j77qQHqlmt9Et/goCV+c1oLU0HKmatFrAYSKUc4p5QIgVMqMgdCMoPfmn/
gtoboBH+qSap+f3LowaEjOwXfDr48VvqjbmkGTZaSp1vB62OCZ3MDuqwsHgA
PQuc5FCCG5guLrbIkP1OJ+9lz//ry2yQFqQZz/OzxWBFRRrc3Y5pTfOC3dmi
63XkDoZHpHfsbGYn6h69YPtLnw3v25xPPFGkxp18RBIEC2dy/ST7rqU4Dh4t
C3zczA34uVWl+1MnpV/+Y/Uf/5vUgRc5lKGnpDa8gQY0+vX6Pf26Ke6hn0gi
kSnZz7rPWSZOikYjakSRBviGVPwDfVS3r9CTKdYU42X6ASM0eIbR6TcaWj/I
tNz3spNiRocZIrQ7KBzauPmfLxaLWf14aws4AlqCwOoyOmWzmp9v0Vbdulhc
TrYaz2g04h75TQOW9vPRuwG9X3MEZWh+2rxlEP9I9vLkqsAo7qtOPW609Lca
v7YlR+N3N3s7WlQ6eve/avTanoDhGvZYY/n++DWLVbaf1b6PBQjT9Q6fGHu6
vMeoQy24TcIt8sH089OXrw7/5LaI4GbA48K0RpO6eIJ9qwQidVF0cIf3Ayr5
ID8hbqkr9NCio7GvMyi9eDBa6Ww8JdXj+UQRyOyMC2oFtd57nNkgDulEY58h
j95mmoynL9HFPzTJPPJ0D6On/jLiO77x2Rw/v3h38Kcs69I/6y+3pZptyMg0
hqy39smr3f2Ch496GHWbEyP6EE9sc7ZVIIcvYj2pRdUx9AaLN1rvWEp9hdM0
4I2aZu+q14c88mHRgYEDPj0pmMtgSc3l2mwgeNH4pAAJZoZ8b8Dnr6ulwlmm
152QRMaa+nwe8m20ztb+CLdNirGohnXn42NJxi/G/6V7ltOS7H5qHDfNWx7z
qfMjL3c8W+10aLGqr/K+Y2jxE7jD66qfzeQtzMtGV8mRAwUNBnaFRc1OFfFk
582TpnlipCqNusThsob+zpwXQKOTfVyCEZY7RGrHUU6j/KI6O6NZB13fcPVF
qgDKISV5OZ/mSlVI50kl/XmmyXRP6RQ96QJXSq/aYX+t5MxPjRb9hte3tuu/
x4txM/n0PSs7z+j6HzlWFd+gT99TSz+W5+ccFj1BGkxOOgxJFUhItHCwnBTU
Gh0CR/m0qrNXOdmoU7IN6Xp+ddx2RncdFJOSzo5iMrooUdO+gE5cs8x+nk/e
V9kJuCF+fU/nzTOyhMe0uklBnVbsiX1Bym92+OuvtNpx3jxFqDPX0+lkVC04
j++4gnr/AujUkpRBRI/kDUijeE4GBu2oPl0EVZze9npSXlF/MJtPy/qimnFX
3uST8v/8rzz7Yfmf/4Om5z//vZ/9x38HKcEP19OR9G1I/aomSGV5VtJZ9gPt
0hfL84pnm9oti0n2Q86o7W8LIBosgKOpkuxhl30aAs0eRP2bZjY9OzHFH0m3
dLP8STJEbJbpW5voTwJ7+hin2z7xk26fNafept2+b06+fc5LIDZiC8E+aS6H
0KlkRdinzXVhnyerIzw5rpHwfKwUXibhTr9Y/PvHJWOfJgsn9D8un/BRcwXZ
F34dxTey1RQ+8WvqU8SifYxLS9bVJy2d3r60Giur83LqvIHiggO1ZIXkMRZt
JtbyKMcVJzQN1rEidfz6lBX3ak6fvboq88V7MvDfY8yaxAGrApQ5W5Sr6Z/J
1vpGHAOAz8KPO9OYSll37GlPDJb/4vTNaymK9ew5Zz1ZIlxe+wYCjJ/3TrVc
kDXf78izzHlD9/zr0BwlSDAzNCy7D1XkurKbG1HBKs86eJ90/PBC/IQ+zioO
9F0quaUqE1k1HRn5L/CiNY5jMFCL6nf8/OCnN683e5gzQ4MgFqc9IOm/868f
9+59wr8j/mNje+fh//1v/3PU29rhT/futaR+r6b4dJkcrgbjyGsyt5YkZbqB
KF5VnWoKLvnOyeKaevrtEqdS0LCurq42qfFBQUpMNWe9qcZ157hsC6ttZ+tO
ac/4ZaLP+KbTop1Er4bAS4w7M/te/e9GQ6lJIsH521HmcWPBnMF1VCPLQJ7m
uLC9+hT0Jh9W6Oj5GzjmjGWyG/yqXQfMMdXQUVRYWisUF0Y2XBVDENl04qAV
w01AqGhEeMTo7y3YLnd3tu/dfbRz7/7DLT++QCltnlcftvDLwLinBpNyCJId
+VRwlzQag7qANjpwumQ9kF0+KCOVfX2H3bTb33TAFaJ8JBdmRDDyE9xXFsKb
kO5Z5sbkasyVORlJ58tqSbKlexpHh6GNGi9nimtqra9YVvWNBlcle+Vo3V+T
EUMzvbpk910ZXHFiJO4L9bcWf6UjZxz3bLR0QLJkMsTtnw47m72VEwvhoFzs
m17rFUy27b42lnYWg8nXHWflATMN3MpVlW0wM5vuafZH9hpWX3fluZ1Gz7rZ
BgcoINnZUgjv1ePcA6HF6NKldKUQpqfVhK/yiPuxkev58sCC1h9Kxs5EhlWI
jFh/BdMEu9fVZ8Nt1KXVKX4jfO9TuMXUgb5wdBFPRJkGzYtVI36zf9BV7inu
zBNUkOq+QfUIsingRsdxz6CuDbq2ByKJN5Jn1Gkwux4ASmMXMaIxMaKbSYZJ
ooND2SiHk6PHUOyT8SEw1pi6fkT2I2NKgyXeeF0hsixyuPbqazqL4U1HG4k7
dIPJjoMP13/Xk9Mf2wYSMmnDhccC9lEyTQzg08+Gk2r0Pv55kdcXgU9fVG8a
rVp4OPqOxBK0BA0QfzMRBkqF2shsVoZlnCwKNon2D/efdaVmBUSB1qRu2Kwr
pwIb3CJIxPWc0oQcvTrMfgYV9fbDu3/SPAkNlTfIaxFO6Wevnj2vA9WGY9Xm
+FSoBCItRLOc83c28AI9VwTGez6+riP7SUcOGx2xSgBI4m3tSGecbiZ2gqzu
ppt9PM3020M5DmPaiRFTLqdajYWPtmP2Ld2TCgbIdX+cHQicgNp4MzqcgBqA
zLF3B0itUwwWqYt8cwsWS9e6+HPwbkVcXDQjmCdbVpG9IQp7L+VIiZth8QH/
3OHqXrSlrSrC7uYeJoNmLHuwu7OTbXTxq9NwUIwm1ZYgqztxUTd2udU5ELCW
JjepV4ULDiDrYU1th86pVrM6/Ctdwh8f+rTLjdPDw7rXeYGNS42/HTLw6hg4
oMvsZDkErQEvldM5WEw3Xrw9PjmV66lRlZNNBmyRky8gKDvrElw7NyCx2oiF
Ck6qafeOCvLI69VRnZajshNOneW0xOVNl4gXDCKmOPNPCNyF6JGGGfJtgFdl
qgQeBfkTmELu9f8DzGTvsRf3AQA=
--> -->
</rfc> </rfc>
 End of changes. 239 change blocks. 
2394 lines changed or deleted 2674 lines changed or added

This html diff was produced by rfcdiff 1.48.