<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pquip-pqt-hybrid-terminology-01" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <front>
    <title abbrev="PQ/T Hybrid Terminology">Terminology for Post-Quantum Traditional Hybrid Schemes</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-01"/>
    <author fullname="Florence Driscoll">
      <organization>UK National Cyber Security Centre</organization>
      <address>
        <email>florence.d@ncsc.gov.uk</email>
      </address>
    </author>
    <date year="2023" month="October" day="20"/>
    <area>SEC</area>
    <workgroup>PQUIP</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 111?>

<t>One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms.  This document defines terminology for such schemes.  It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.</t>
    </abstract>
    <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-pqt-hybrid-terminology/"/>.
      </t>
      <t>
      </t>
    </note>
  </front>
  <middle>
    <?line 116?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The mathematical problems of integer factorisation and discrete logarithms over finite fields or elliptic curves underpin most of the asymmetric algorithms used for key establishment and digital signatures on the internet.  These problems, and hence the algorithms based on them, will be vulnerable to attacks using Shor's Algorithm on a sufficiently large general-purpose quantum computer, known as a Cryptographically Relevant Quantum Computer (CRQC).  It is difficult to predict when, or if, such a device will exist.  However, it is necessary to anticipate and prepare to defend against such a development.  Data encrypted today (2023) with an algorithm vulnerable to a quantum computer could be stored for decryption by a future attacker with a CRQC.  Signing algorithms in products that are expected to be in use for many years are also at risk if a CRQC is developed during the operational lifetime of that product.</t>
      <t>Preparing for the potential development of a CRQC requires modifying established (standardised) protocols to use asymmetric algorithms that are perceived to be secure against quantum computers as well as today's classical computers.  These algorithms are called post-quantum, while algorithms based on integer factorisation, finite-field discrete logarithms or elliptic-curve discrete logarithms are called traditional cryptographic algorithms. In this document "traditional algorithm" is also used to refer to this class of algorithms.</t>
      <t>During the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that use both algorithm types.  A designer may choose to combine a post-quantum algorithm with a traditional algorithm to add protection against an attacker with a CRQC to the security properties provided by the traditional algorithm.  They may also choose to implement a post-quantum algorithm alongside a traditional algorithm for ease of migration from an ecosystem where only traditional algorithms are implemented and used, to one that only uses post-quantum algorithms. Examples of solutions that could use both types of algorithm include, but are not limited to, <xref target="RFC9370"/>, <xref target="I-D.ietf-tls-hybrid-design"/>, <xref target="I-D.ietf-lamps-pq-composite-kem"/>, and <xref target="I-D.ietf-lamps-cert-binding-for-multi-auth"/>.
Schemes that combine post-quantum and traditional algorithms for key establishment or digital signatures are often called hybrids. For example:</t>
      <ul spacing="normal">
        <li>
          <t>NIST defines hybrid key establishment to be a "scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes" <xref target="NIST_PQC_FAQ"/>;</t>
        </li>
        <li>
          <t>ETSI defines hybrid key exchanges to be "constructions that combine a traditional key exchange ... with a post-quantum key exchange ... into a single key exchange" <xref target="ETSI_TS103774"/>.</t>
        </li>
      </ul>
      <t>The word "hybrid" is also used in cryptography to describe encryption schemes that combine asymmetric and symmetric algorithms <xref target="RFC4949"/>, so using it in the post-quantum context overloads it and risks misunderstandings.  However, this terminology is well-established amongst the post-quantum cryptography (PQC) community. Therefore, an attempt to move away from its use for PQC could lead to multiple definitions for the same concept, resulting in confusion and lack of clarity.</t>
      <t>This document provides language for constructions that combine traditional and post-quantum algorithms.   Specific solutions for enabling use of multiple asymmetric algorithms in cryptographic schemes may be more general than this, allowing the use of solely traditional or solely post-quantum algorithms.  However, where relevant, we focus on post-quantum traditional combinations as these are the motivation for the wider work in the IETF.  This document is intended as a reference terminology guide for other documents to add clarity and consistency across different protocols, standards, and organisations.  Additionally, this document aims to reduce misunderstanding about use of the word "hybrid" as well as defining a shared language for different types of post-quantum traditional hybrid constructions.</t>
      <t>In this document, a "cryptographic algorithm" is defined, as in <xref target="NIST_SP_800-152"/>, to be a "well-defined computational procedure that takes variable inputs, often including a cryptographic key, and produces an output".  Examples include RSA, ECDH, ML-KEM (formerly known as Kyber) and ML-DSA (formerly known as Dilithium).   The expression "cryptographic scheme" is used to refer to a construction that uses a cryptographic algorithm or a group of cryptographic algorithms to achieve a particular cryptographic outcome, e.g., key agreement.  A cryptographic scheme may be made up of a number of functions. For example, a Key Encapsulation Mechanism (KEM) is a cryptographic scheme consisting of three functions: Key Generation, Encapsulation, and Decapsulation.  A cryptographic protocol incorporates one or more cryptographic schemes.  For example, TLS <xref target="RFC8446"/> is a cryptographic protocol that includes schemes for key agreement, record layer encryption, and server authentication.</t>
    </section>
    <section anchor="primitives">
      <name>Primitives</name>
      <t>This section introduces terminology related to cryptographic algorithms and to hybrid constructions for cryptographic schemes.</t>
      <dl>
        <dt><strong>Traditional Cryptographic Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms.
</t>
          <t>Where there is little risk of confusion traditional cryptographic algorithms can also be referred to as traditional algorithms for brevity.  Traditional algorithms can also be called classical or convential algorithms.</t>
        </dd>
        <dt><strong>Post-Quantum Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers.
</t>
          <t>Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms.</t>
        </dd>
        <dt><strong>Component Algorithm</strong>:</dt>
        <dd>
          <t>Each cryptographic algorithm that forms part of a cryptographic scheme.</t>
        </dd>
        <dt><strong>Single-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme with one component algorithm.
</t>
          <t>A single-algorithm scheme could use either a traditional algorithm or a post-quantum algorithm.</t>
        </dd>
        <dt><strong>Multi-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme that incorporates more than one component algorithm, where the component algorithms have the same cryptographic purpose.
</t>
          <t>For example, a multi-algorithm scheme may include multiple signature algorithms or multiple Public Key Encryption (PKE) algorithms.  Component algorithms could be all traditional, all post-quantum, or a mixture of the two.</t>
        </dd>
        <dt><strong>Post-Quantum Traditional (PQ/T) Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Key Encapsulation Mechanism (KEM)</strong>:</dt>
        <dd>
          <t>A multi-algorithm KEM made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Public Key Encryption (PKE)</strong>:</dt>
        <dd>
          <t>A multi-algorithm PKE scheme made up of two or more component PKE algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Digital Signature</strong>:</dt>
        <dd>
          <t>A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures are all examples of PQ/T hybrid schemes.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Combiner</strong>:</dt>
        <dd>
          <t>A method that takes two or more component algorithms and combines them to form a PQ/T hybrid scheme.</t>
        </dd>
        <dt><strong>PQ/PQ Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where all components are post-quantum algorithms.
</t>
          <t>The definitions for types of PQ/T hybrid schemes can adapted to define types of PQ/PQ hybrid schemes, which are multi-algorithm schemes where all component algorithms are Post-Quantum algorithms.</t>
        </dd>
      </dl>
      <t>In cases where there is little chance of confusion between other types of hybrid cryptography e.g., as defined in <xref target="RFC4949"/>, and where the component algorithms of a multi-algorithm scheme could be either post-quantum or traditional, it may be appropriate to use the phrase "hybrid scheme" without PQ/T or PQ/PQ preceding it.</t>
    </section>
    <section anchor="cryptographic-elements">
      <name>Cryptographic Elements</name>
      <t>This section introduces terminology related to cryptographic elements and their inclusion in hybrid schemes.</t>
      <dl>
        <dt><strong>Cryptographic Element</strong>:</dt>
        <dd>
          <t>Any data type (private or public) that contains an input or output value for a cryptographic algorithm or for a function making up a cryptographic algorithm.
</t>
          <t>Types of cryptographic elements include public keys, private keys, plaintexts, ciphertexts, shared secrets, and signature values.</t>
        </dd>
        <dt><strong>Component Cryptographic Element</strong>:</dt>
        <dd>
          <t>A cryptographic element of a component algorithm in a multi-algorithm scheme.
</t>
          <t>For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client's keyshare contains two component public keys, one for a post-quantum algorithm and one for a traditional algorithm.</t>
        </dd>
        <dt><strong>Composite Cryptographic Element</strong>:</dt>
        <dd>
          <t>A cryptographic element that incorporates multiple component cryptographic elements of the same type in a multi-algorithm scheme.
</t>
          <t>For example, a composite cryptographic public key is made up of two component public keys.</t>
        </dd>
        <dt><strong>Cryptographic Element Combiner</strong>:</dt>
        <dd>
          <t>A method that takes two or more component cryptographic elements of the same type and combines them to form a composite cryptographic element.
</t>
          <t>A cryptographic element combiner could be concatenation, such as where two component public keys are concatenated to form a composite public key as in <xref target="I-D.ietf-tls-hybrid-design"/>, or something more involved such as the dualPRF defined in <xref target="BINDEL"/>.</t>
        </dd>
      </dl>
    </section>
    <section anchor="protocols">
      <name>Protocols</name>
      <t>This section introduces terminology related to the use of post-quantum and traditional algorithms together in protocols.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Protocol</strong>:</dt>
        <dd>
          <t>A protocol that uses two or more component algorithms providing the same cryptographic functionality, where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>For example, a PQ/T hybrid protocol providing confidentiality could use a PQ/T hybrid KEM such as in <xref target="I-D.ietf-tls-hybrid-design"/>, or it could combine the output of a post-quantum KEM and a traditional KEM at the protocol level to generate a single shared secret, such as in <xref target="RFC9370"/>.  Similarly, a PQ/T hybrid protocol providing authentication could use a PQ/T hybrid digital signature scheme, or it could include both post-quantum and traditional single-algorithm digital signature schemes.</t>
        </dd>
        <dt><strong>Composite PQ/T Hybrid Protocol</strong>:</dt>
        <dd>
          <t>A protocol that incorporates one or more PQ/T hybrid schemes in such a way that the protocol fields and message flow are the same as those in a version of the protocol that uses single-algorithm schemes.
</t>
          <t>In a composite PQ/T hybrid protocol, changes are primarily made to the formats of the cryptographic elements, while the protocol fields and message flow remain largely unchanged.  In implementations, most changes are likely to be made to the cryptographic libraries, with minimal changes to the protocol libraries.</t>
        </dd>
        <dt><strong>Non-composite PQ/T Hybrid Protocol</strong>:</dt>
        <dd>
          <t>A protocol that incorporates multiple single-algorithm schemes of the same type, where at least one uses a post-quantum algorithm and at least one uses a traditional algorithm, in such a way that the formats of the component cryptographic elements are the same as when they are used as part of single-algorithm schemes.
</t>
          <t>In a non-composite PQ/T hybrid protocol, changes are primarily made to the protocol fields, the message flow, or both, while changes to cryptographic elements are minimised.  In implementations, most changes are likely to be made to the protocol libraries, with minimal changes to the cryptographic libraries.</t>
        </dd>
      </dl>
      <t>It is possible for a PQ/T hybrid protocol to be designed that is neither entirely composite nor entirely non-composite.  For example, in a protocol that offers both confidentiality and authentication, the key establishment could be done in a composite manner while the authentication is done in a non-composite manner.</t>
    </section>
    <section anchor="properties">
      <name>Properties</name>
      <t>This section describes properties that may be desired from or achieved by a PQ/T hybrid scheme or PQ/T hybrid protocol.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Confidentiality</strong>:</dt>
        <dd>
          <t>The property that confidentiality is achieved by a PQ/T hybrid scheme or PQ/T hybrid protocol as long as at least one component algorithm that aims to provide this property remains secure.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Authentication</strong>:</dt>
        <dd>
          <t>The property that authentication is achieved by a PQ/T hybrid scheme or a PQ/T hybrid protocol as long as at least one component algorithm that aims to provide this property remains secure.</t>
        </dd>
      </dl>
      <t>The security properties of a PQ/T hybrid scheme or protocol depend on the security of its component algorithms, the choice of PQ/T hybrid combiner, and the capability of an attacker. Changes to the security of a component algorithm can impact the security properties of a PQ/T hybrid scheme providing hybrid confidentiality or hybrid authentication.  For example, if the post-quantum component algorithm of a PQ/T hybrid scheme is broken, the scheme will remain secure against an attacker with a classical computer, but will be vulnerable to an attacker with a CRQC.</t>
      <t>PQ/T hybrid protocols that offer both confidentiality and authentication do not necessarily offer both hybrid confidentiality and hybrid authentication.  For example, <xref target="I-D.ietf-tls-hybrid-design"/> provides hybrid confidentiality but does not address hybrid authentication.  Therefore, if the design in <xref target="I-D.ietf-tls-hybrid-design"/> is used with X.509 certificates as defined in <xref target="RFC5280"/> only authentication with a single algorithm is achieved.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Interoperability</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties share support for at least one component algorithm.
</t>
          <t>For example, a PQ/T hybrid digital signature might achieve hybrid interoperability if the signature can be verified by either verifying the traditional or the post-quantum component, such as the approach defined in section 7.2.2 of <xref target="ITU-T-X509-2019"/>.  In this example a verifier that has migrated to support post-quantum algorithms is required to verify only the post-quantum signature, while a verifier that has not migrated will verify only the traditional signature.</t>
        </dd>
      </dl>
      <t>In the case of a protocol that aims to achieve both authentication and confidentiality, PQ/T hybrid interoperability requires that at least one component authentication algorithm and at least one component algorithm for confidentiality is supported by both parties.</t>
      <t>It is not possible for a PQ/T hybrid scheme to achieve both PQ/T hybrid interoperability and PQ/T hybrid confidentiality without additional functionality at a protocol level.  For PQ/T hybrid interoperability a scheme needs to work whenever one component algorithm is supported by both parties, while to achieve PQ/T hybrid confidentiality all component algorithms need to be used.  However, both properties can be achieved in a PQ/T hybrid protocol by building in downgrade protection external to the cryptographic schemes.  For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client uses the TLS supported groups extension to advertise support for a PQ/T hybrid scheme and the server can select this group if it supports the scheme.  This is protected using TLS's existing downgrade protection, so achieves PQ/T hybrid confidentiality, but the connection can still be made if either the client or server does not support the PQ/T hybrid scheme, so PQ/T hybrid interoperability is achieved.</t>
      <t>The same is true for PQ/T hybrid interoperability and PQ/T hybrid authentication.  It is not possible to achieve both with a PQ/T hybrid scheme alone, but it is possible with a PQ/T hybrid protocol that has appropriate downgrade protection.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Backwards Compatibility</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties support the traditional component algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Forwards Compatibility</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties support the post-quantum component algorithm.</t>
        </dd>
        <dt><strong>Weak Non-Separability</strong>:</dt>
        <dd>
          <t>A property of a hybrid digital signature that guarantees that an adversary cannot remove either component signature without leaving some evidence behind.
</t>
          <t>Weak non-separability does not necessarily prevent an attacker from creating a valid traditional-only or post-quantum-only signature from a PQ/T hybrid signature, rather it means that a verifier would be able to identify that the resulting signature had been derived from a PQ/T hybrid signature.</t>
        </dd>
        <dt><strong>Strong Non-Separability</strong>:</dt>
        <dd>
          <t>A property of a hybrid digital signature that guarantees that an adversary cannot create a valid single-algorithm signature from a hybrid signature.
</t>
          <t>In the context of PQ/T hybrid signatures this means that an attacker cannot take a PQ/T hybrid digital signature and generate a post-quantum or traditional signature that will verify correctly.</t>
        </dd>
        <dt><strong>Simultaneous Verification</strong>:</dt>
        <dd>
          <t>A property of a hybrid digital signature where all component algorithms must be verified before the verifier returns a result and finishes the verification process.
</t>
          <t>In the context of PQ/T hybrid signatures this means that both the post-quantum and traditional component signatures much be verified before the verifier returns a result.</t>
        </dd>
      </dl>
      <t>Weak non-separability, strong non-separability and simultaneous verification are related concepts, with strong non-separability being a stronger property than weak non-separability and simultaneous verification being a stronger property still.  These concepts are introduced, explored in more detail and examples provided in <xref target="BINDELHALE"/>.</t>
    </section>
    <section anchor="certificates">
      <name>Certificates</name>
      <t>This section introduces terminology related to the use of certificates in hybrid schemes.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Certificate</strong>:</dt>
        <dd>
          <t>A digital certificate that contains public keys for two or more component algorithms where at least one is a traditional algorithm and at least one is a post-quantum algorithm.
</t>
          <t>A PQ/T hybrid certificate could be used to facilitate a PQ/T hybrid authentication protocol.  However, a PQ/T hybrid authentication protocol does not need to use a PQ/T hybrid certificate; separate certificates could be used for individual component algorithms.</t>
          <t>The component public keys in a PQ/T hybrid certificate could be included as a composite public key or as individual component public keys.</t>
        </dd>
      </dl>
      <t>The use of a PQ/T hybrid certificate does not necessarily achieve hybrid authentication of the identity of the sender; this is determined by properties of the chain of trust. For example, an end-entity certificate that contains a composite public key, but which is signed using a single-algorithm digital signature scheme could be used to provide hybrid authentication of the source of a message, but would not achieve hybrid authentication of the identity of the sender.</t>
      <dl>
        <dt><strong>Post-Quantum Certificate</strong>:</dt>
        <dd>
          <t>A digital certificate that contains a single public key for a post-quantum digital signature algorithm.</t>
        </dd>
        <dt><strong>Traditional Certificate</strong>:</dt>
        <dd>
          <t>A digital certificate that contains a single public key for a traditional digital signature algorithm.
</t>
          <t>X.509 certificates as defined in <xref target="RFC5280"/> could be either traditional or post-quantum certificates depending on the algorithm in the Subject Public Key Info.  For example, a certificate containing a ML-DSA public key, as defined in <xref target="I-D.ietf-lamps-dilithium-certificates"/>, would be a post-quantum certificate.</t>
        </dd>
        <dt><strong>Post-Quantum Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain where each certificate includes a public key for a post-quantum algorithm and is signed using a post-quantum digital signature scheme.</t>
        </dd>
        <dt><strong>Traditional Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain where all certificates includes a public key for a traditional algorithm and is signed using a traditional digital signature scheme.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain where all certificates are PQ/T hybrid certificates and each certificate is signed with two or more component algorithms where at least one is a traditional algorithm and at least one is a post-quantum algorithm.</t>
        </dd>
      </dl>
      <t>A PQ/T hybrid certificate chain is one way of achieving hybrid authentication of the identity of a sender in a protocol, but is not the only way. An alternative is to incorporate both a post-quantum certificate chain and a traditional certificate chain in a protocol.</t>
      <t>It would be possible to construct a certificate chain containing a mixture of post-quantum certificates, traditional certificates and PQ/T hybrid certificates. For example, a post-quantum end-entity certificate could be signed by a traditional intermediate certificate, which in turn could be signed by a traditional root. The security properties of a certificate chain that mixes post-quantum and traditional algorithms would need to be analysed on a case-by-case basis.</t>
    </section>
    <section anchor="algorithm-specification">
      <name>Algorithm Specification</name>
      <t>This section introduces terminology for specifying the component algorithms used in PQ/T hybrid schemes or PQ/T hybrid protocols.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Scheme Identifier</strong>:</dt>
        <dd>
          <t>A single code point that specifies all component algorithms used in a PQ/T hybrid scheme.</t>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document defines security-relevant terminology to be used in documents specifying PQ/T hybrid protocols and schemes.  However, the document itself does not have a security impact on Internet protocols.  The security considerations for each PQ/T hybrid protocol are specific to that protocol and should be discussed in the relevant specification documents.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="BINDEL" target="https://doi.org/10.1007/978-3-030-25510-7_12">
        <front>
          <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="J." surname="Brendel" fullname="Jacqueline Brendel">
            <organization/>
          </author>
          <author initials="M." surname="Fischlin" fullname="Marc Fischlin">
            <organization/>
          </author>
          <author initials="B." surname="Goncalves" fullname="Brian Goncalves">
            <organization/>
          </author>
          <author initials="D." surname="Stebila" fullname="Douglas Stebila">
            <organization/>
          </author>
          <date year="2019" month="July"/>
        </front>
        <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
        <refcontent>Post-Quantum Cryptography pp.206-226</refcontent>
      </reference>
      <reference anchor="BINDELHALE" target="https://eprint.iacr.org/2023/423.pdf">
        <front>
          <title>A Note on Hybrid Signature Schemes</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="B." surname="Hale" fullname="Britta Hale">
            <organization/>
          </author>
          <date year="2023" month="July" day="23"/>
        </front>
        <refcontent>Cryptology ePrint Archive, Paper 2023/423</refcontent>
      </reference>
      <reference anchor="ETSI_TS103774" target="https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf">
        <front>
          <title>CYBER; Quantum-safe Hybrid Key Exchanges</title>
          <author>
            <organization>ETSI TS 103 744 V1.1.1</organization>
          </author>
          <date year="2020" month="December"/>
        </front>
      </reference>
      <reference anchor="ITU-T-X509-2019" target="https://www.itu.int/rec/T-REC-X.509-201910-I">
        <front>
          <title>ITU-T X.509 The Directory - Public-key and attribute certificate frameworks</title>
          <author>
            <organization>ITU-T</organization>
          </author>
          <date year="2019" month="January"/>
        </front>
      </reference>
      <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs">
        <front>
          <title>Post-Quantum Cryptography FAQs</title>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2022" month="July" day="05"/>
        </front>
      </reference>
      <reference anchor="NIST_SP_800-152" target="https://doi.org/10.6028/NIST.SP.800-152">
        <front>
          <title>NIST SP 800-152 A Profile for U. S. Federal Cryptographic Key Management Systems</title>
          <author initials="E. B." surname="Barker" fullname="Elaine B. Barker">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="M." surname="Smid" fullname="Miles Smid">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="D." surname="Branstad" fullname="Dannis Branstad">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2015" month="October"/>
        </front>
      </reference>
      <reference anchor="I-D.ietf-lamps-dilithium-certificates">
        <front>
          <title>Internet X.509 Public Key Infrastructure: Algorithm Identifiers for Dilithium</title>
          <author fullname="Jake Massimo" initials="J." surname="Massimo">
            <organization>AWS</organization>
          </author>
          <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
            <organization>AWS</organization>
          </author>
          <author fullname="Sean Turner" initials="S." surname="Turner">
            <organization>sn3rd</organization>
          </author>
          <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
            <organization>Cloudflare</organization>
          </author>
          <date day="7" month="August" year="2023"/>
          <abstract>
            <t>   Digital signatures are used within X.509 certificates, Certificate
   Revocation Lists (CRLs), and to sign messages.  This document
   describes the conventions for using Dilithium quantum-resistant
   signatures in Internet X.509 certificates and certificate revocation
   lists.  The conventions for the associated post-quantum signatures,
   subject public keys, and private key are also described.

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

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-multi-auth-01"/>
      </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</organization>
          </author>
          <date day="7" month="September" year="2023"/>
          <abstract>
            <t>   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

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

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

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

   This document defines the structure CompositeCiphertextValue which is
   a sequence of the respective ciphertexts for each component
   algorithm.  Explicit pairings of algorithms are defined which should
   meet most Internet needs.  For the purpose of combining KEMs, the
   combiner function from [I-D.ounsworth-cfrg-kem-combiners] is used.

   This document is intended to be coupled with the composite keys
   structure define in [I-D.ounsworth-pq-composite-keys] and the CMS
   KEMRecipientInfo mechanism in [I-D.housley-lamps-cms-kemri].

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-kem-00"/>
      </reference>
      <reference anchor="RFC4949">
        <front>
          <title>Internet Security Glossary, Version 2</title>
          <author fullname="R. Shirey" initials="R." surname="Shirey"/>
          <date month="August" year="2007"/>
          <abstract>
            <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="FYI" value="36"/>
        <seriesInfo name="RFC" value="4949"/>
        <seriesInfo name="DOI" value="10.17487/RFC4949"/>
      </reference>
      <reference anchor="RFC5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author fullname="D. Cooper" initials="D." surname="Cooper"/>
          <author fullname="S. Santesson" initials="S." surname="Santesson"/>
          <author fullname="S. Farrell" initials="S." surname="Farrell"/>
          <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
          <author fullname="R. Housley" initials="R." surname="Housley"/>
          <author fullname="W. Polk" initials="W." surname="Polk"/>
          <date month="May" year="2008"/>
          <abstract>
            <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5280"/>
        <seriesInfo name="DOI" value="10.17487/RFC5280"/>
      </reference>
      <reference anchor="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </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-Morchon"/>
          <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 multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.</t>
            <t>This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9370"/>
        <seriesInfo name="DOI" value="10.17487/RFC9370"/>
      </reference>
    </references>
    <?line 320?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document is the product of numerous fruitful discussions in the IETF PQUIP group.  Thank you in particular to Mike Ounsworth, John Gray, Tim Hollebeek, Wang Guilin, Paul Hoffman and Sofía Celi for their contributions.</t>
      <t>This document is inspired by many others from the IETF and elsewhere. In particular, many of the definitions in the Properties section are drawn from <xref target="BINDELHALE"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81d73LcNpL/7iq/A0r7Ye3UcCTLdhwrdVWnSHKiJHZkS9ns
fXJhSMwMThxyTJAjz6b8SPcU92LXfwASIMEZ2cnu3norlmYIoP+h+9eNBp0k
ycMHta5zdSIOblS10kWZl4utmJeVuCpNnbxtZFE3K3FTyUzXuixkLn7Yziqd
iet0qVbKHDx8IGezSm1giqu3hzfua286eCSVtVqU1fZE6GJePnzw8EFWpoVc
wcJZJed1olU9T9YfGr2G/9bJkiZJ6m6S5OjJwwemma20MUBHvV3D2MuLm1cP
HxTNaqaqE5gTVoG/0rIwqjCNORF11aiHD4C2p0BmpeSJuL44e/jgrqxuF1XZ
rE/E1dtfL68ePrhVW/gwgykLWLRQdXKOdMFYVTQ4qRDhACGYhN9gKl0sxPf4
LX68kjo/Ecu6XpuTw0P8TVbpUm/UFHmcltXiED84nFXlnVGH6w/pIQ7Dzz57
GP6RTb0skXuR4DxCzJs8Z9G+ystKFakS55U2aZnn/ADMJQv9D4n6PBG//iTe
SKvasy0IUlyrtKl0vRVnqqgrxYMU8zW3U06z/yxSk04X5Wba3CIdqNhqBTNt
WFzfXb45v/j5hEfXslqouuMvKzWx9ORo+uTo6MXhyxffJE+To6dHyfHz50+O
khfvnxzbkWye1qp+UltxUaRybZqciBavVboEbszKCFlk4hSkAVRrNDj7+Ed8
YGHZ6KRF/0vcDwIME+zlzVR8p4tM5d3nLMo3upC9r/pjf4SxIJvI4B9l+qFR
uS5U/4n+HK+n4hWoagnP9id5DeoffNkf/91UfF+CfPKNMv0Jvqu0LIZf96c4
n4rrWs3A/voTnJfNIpcm/LpSc9hvNcj8JHQZZ9V2XZeLSq6XW7FeT4+Pvk6O
j7/mUUZVWhk0mVYV579cnoj99kB7XBwfPXmZHL1Au3OW9sPpzxcj1qbWlS7q
qZZpRVZ3fHT89PDZ8dPpOpsHVnYq3pS1EmBWzsnpRSHrplLO3UWsqBVg3IJG
7CccBXr7QeYqHAMKq2vpfeHLmsVL3lpdIXvilP3FRFzJNexix2QotmOQ6osE
P8XPL26uL9/fXD85evrixbMR4d3d3U1VbXi/AvmwRHWIH7yvzSGOPDp6j3+9
fEm/PXt2ePRkSv9///XRYW3e86eboyf4Zz2Q+dl/fXfx7lthzSYxcq6C3W63
b0zyIEV0ZifEh7i5BvN5KmAt8bcnU/jT4/woYRu6vPk1uUn+/vzoZYJmtINt
XTdTkOxhpdLDm+TdxVny96kbBkZ5GfBB0wp6QNwswedqGFZDzAMir5pZrtME
ggw5KVnXlZ41YGmpqmo9J28l5hVoHSPTTlZpmeFWIGbfXF7fvL96e/b+1enb
EbZSU6VTcJc1eu7Dq6r8byDSHK5x536wKki9nXs4lx9MwOf4JodVd5LehpnL
wsBkyH85B28CIpFVxv77Bty5BSGPkJ3HPSUeo/kePXfciusr8c0RaPb58f5I
8/XR8TeHOGp6fTW1owLWejOCOwABzXWuCBD9Co4R3LPKVIWhsuNcp2Spr2Uh
F+AjYCteb02tViPC6LvVi1xSZADHIatbVXXfs8JdXAWv5EnnZzkrK4n2NTrx
a6AcvPVKZ3/alOeyAOMBzyRBhfLPmPfPsownz5MnR+zVLpNzAk1JLldrk2Q6
1/VSo2F3u82cRJ7E75MZOGkAdAmwkqyavNYJKjB8vM6Ng6gZhLFFEZtt/SFJ
yxXsLF0r2Poreubdq7NnL5+9dD8/P/7myP38zbNnX7ufX4JbPWF8lySJkDNT
VzKtBX/0C5iLNGvYuSgmADyAc0EhBNBFXQp/NwuZA/AGAQBA0oVIA7NdV2Vd
AjCErwzNk6mNyss1GTFMzTwKw7EPnpA1TJKW1RoVqsSsrJe91UBTtZcsSLNd
rRS4u9QjZCrAQ8KKkAM0tFSm5rAFYIFeDmKadOlWh0GXNdKpMQJmgO6A05kS
jYEfAZVIDI+K8S5QMRHLcq0QC28n+CQmBBDGMTcA7wdPsStOAWYj1AVoUBqg
SM9pjroTzUQYZ4cTGsLw2ZDJmqlTEeyyDOP0wwd/wRyiKrMmxScePsBgAJsC
mJCIS3OcepaDe0AJIzMLiNZzibHCzkrLZAD1KgVCBmlIq8Byg4/qQmO40CqH
rQFSUnmu1zC1ANgOwE40IJ1qDcpegWachUQVwcJDSWNoUsAoxCmzJJ0wDQtd
A8XGwSCD2Ain0zZNIlUqo1qmWEZLUgOt2y02k7gaT7CaiDud56jATZMX4FJh
NOoJYqNMb5EyzKquwXP+1YhTNwmOlmAWc9jFGqjMtyJHhy8WCufIk3UDtgnk
OHvEHQjupJqI26K8K9hQAt8twULEO5WrDYwQbWCz48Sjs3dvzx63xocGolNw
C7TPKpVp2IR3wO4ENaHnE7ZZiTtJgwiISfURA64QP5R3sL+AFk1zFSpVxkhA
CMg3Ji16jbsKBQhTryFhxW9gcygEDQsIE6DPbn63U2HmcwlAEWSOjNHOyCS4
SYR7j4EE2KSA/FtN9CU+EBb80OQZ6saAUVoLyRTNjuY5g/0CaSbhYtYXjOFl
BIoLCELgjAoMvc+at4X1JMif+ohurN3M8AyYJK23ksVWbJWsDD0oc4PGIWCP
3IKc7UqkEpYEzJFB2gprotnB75ULKrmeq1qvFG8FWTsyaO9ekaBxGC6KQ9cl
ImwNA3ve0C5ZqQ+Nxq2wKsEatji03TlAxCPnLjRY+2PPxQKHyFt8I7YCAbpT
BRjbScRgMq5a7fdVZdCi78AD4N+kdtgu4NSMIVfTPtbuU29NXA7NH9byfTjs
zCVintjOjbqriXVJCbmkuOPqvFRCXir6lEeQH0PCmOWHkUv0JX4gOQhij3vy
AM2EDIj8HQiWQgX+QMNJXqThbm60jfPOnrwAO6/KVUDfeMSd4NgK3f8WdYm7
1oDpoDiksyOiG23PsxQ0BrQViq/dvsWKE2ryVDDqUBXNnC5LdHlABqh7hlhS
jhDkNmlUSuQLsozoUCnHIWt16D0i+5wFaG0UoygMXSPGgs0BP240RmlwFlaA
wyXZKrfEBemnY0Wv1jnLZpQZmZfFwsAioxyhWBXYLup2pRfsEViBwJJKS0NA
HR04aqWASBCdiE2zJQkBB3hkNCbCFmWhWGc0A3xsxgxiCvmsxGnI3EyZN4Qi
eDR73VbvpO3AKhF75U0GKT4kj0RSUdbg3laaPehE/P67BY+fPuEv44C1930c
seJDyOjgwR1A+dMn2DrXPmB0RrkbJ3aijsMRjEBDNIIyKOfgr53fYCZBzq9Q
9SxrAtJfcXbnkKZFtsN12OtKccCw02JeRA3MB5sQRpK7EolalYQqQWoFDPcc
OYIco7DS1nNgsGYSrmkR7gEI2k/hP336Fumm4kaMblcZsTQfILatK4adPdmH
G8QfLabTqdvTgYYGD4HvR7CAuAyig/81Eh6UksgIGPliVV0cMNk9PxymI1vG
OhAVNDBjsQzK2sSMyY+iYErRmEqbAbMttGNaFL05Yq/CBnqPXSqsfawJYuel
BGStGQMj4IBYrw3BagruMI3x4RwFET930RyTEx8XyBV6qzqysi+DR6D7x8jl
qoGQup2if4RgBUY2sV5YrdZkpSugVMg78Jzkz3RtWugEc1hnkitJ8Y72J2wF
tiPNFuIAj4HUHvlP1bqeQFgy+DBKqsBP541xKUkOEQBN3yZNVsd+/LVe38Cj
xaKRC6Znh2EGPqDIxv0mQEpAipi9e26T/HuBIgZyG+vnHatxoDXIgZ152RhN
+9lmE0gqIwwQfp6Xdw4N2KWAENULGZi08qfjnLR2w2GnsrkH/I7iShtKsoLh
ARrq3BCBv5phHXscIL/WGxvmrHrvQCEV7sNbZ/h4bDbIwf3MupdO+6a9aDDg
4twlYpt2vHHwoc2oMbv2s+0vzbAB72SOe0rmA7KlXhlGdADp1WCfCjkrm9op
rB44JA8989bAIcIsJaY9gRF3hLeBeVRH1ksHdk+7pQ9YJxhpRvDtASc36PcB
ZkgyXQ4QXo0SXVsbssjn2BEW+rscCISdgoQqG9BqeQssbEBTlAXqAh4F4XMo
ZZTBkhiErolNTzGDwgAMsbCpYfQB6KnFNhaniHfXpxNxcXb+w0S8/jn56eK1
eIQVQvCw2y4f/wkPHR/TtPDQ+fVp7KFzV8TDVJzq65A5gqsi33QQ29EkvgHe
l4FSWqRtBqx2oIvAOh3+ku8bSUZo8nSp1YbgtwQUnDawFXoDQFigGHDmarqY
TiiKykWllM3jT6POqfVNEmTKZEjBp97487wprIn5qAdNa8dxqXgE6nhskU1s
Tbt30Qxo5wCR3UonNPX35CY5BQyWYSM5V95HEeacA/BLiobAdIurYp4aZgrY
vPn5mkM9FlA/fYqx1K7kKphonaZ1/Q5xtprAKJiin8jlVlUeGGHGjKqwECe7
s2ZkkGt/VxXCcU0HrORgjc2ltC0K9sqc4P2lrX+MmhaB5TLqVTi+RsVEqPcr
v3MjPLNoi2pffQUI+UScFn7IHNsN9ysFiHuVAsRoKWDKlfzfKEByDg2iBBdQ
g7eiEhBuxRac3KdaABlCweBzptgfVCx2jKHjmQi2thAQC3pgRqa1SUhXf2Hw
s7H1pF554auvgrO0L9OHy09mKkffM1I2CquqO4tIseIRa+Nq5FghIgF3lAge
WmMopvztg3/EO5DFmcuhBoK4AL+6m3+MF4acLvvG2Iawy1xT+pJ0FWXOVZ3M
476Q8iN0TG2i59UwWDinNjFKOtJaR+rSeqUJMo1VKyjQxGGjJf41pdmfR3v/
0MawayVoO8KSQ6YIlyJfQxYqN8pLHUJfyxV4K5ZeQLJ1gr6IML45zNDi9zbN
91fGyOAe4FN1F+Rcuvjo6qeLxyHgPovx0Na4wWJ9hRDU7xVESTMr/ZGocUdu
d2VsF/te4hE2xD0OG+ZaZY2IgiUPKoPUDU9v4hriIDdWF6MWA28CejhegLMc
eI17ezHDKAeI7zyIEi2Q0EOeFiLs/vNY22Ewo0zBl52V7uENn/138XZui2Nt
x9IoR4My2r35G47813EL4Qe5tRgIrAjSFf8TkD2DM//DkYqhpDO5rg7rDwnR
ky/hMy5ZVJ1gVb0sMz+hiouth+Rs6YMydyq6Y/QC3odUdERcvf0iL5LnfmmS
jpdGqhIs4ptlpELkst2IlDj0Z9IeOtpsNRgClIdj6HgJjzArNUK9iZHfL8YH
TrfHyCWWg007Tx8/ojdLVYggZ6q+U5D7clGjZcBBbr9Ex5mbbHNzzsu9UiMq
eU8AJZQyors2MFm4EKgMFeLHKl23h0trPH2BhL5W7qiRSo3LCg9ADgIlHBCi
wcIIKZVKhqgpyKhTlXGV1OYzYc5wwQcgfzS3UXYazmyWSlcc/g1PFt+LUUpa
rLzFTiBJmhOPQAwblAOeqpHPf+yqjkWNgBjLFlTzwCe4fiE2Mm+40rOzFMAP
uEQYhE/d3+A1R0e5veVsakQUDv8wwZiPwlZxjNjfsFMMq9Twc6rXYBz2F1uv
AnVAHmWLaJ2TJs6GMHunPONUWnQdwyPFqEHHkCBtmd2nU7R3cmzy+Ksh/peS
+3dYg+hqO0ICoWE0me8A01xjbB/aFWHP3HHYF0krAr0ddu1IHzEHizIJYJNR
f6aErZqI9j5Ad7JCn9gL+lGR7tqAXx4W78v4rpg5xqOdrc3N4vqxs3r9LngK
AooqbDGDe23aODImH2Et0w5ljzeg0JO7K+bu3gF0loDSRA9DwtPFpswxyXeE
Uc9eI/Ord6/CcMQ98fYcDqtSttb+2Y7bO+647wEuCFpR5OKOH144Bsftd63l
hGU6KsvuRVR84uQOZiL5qHPVEqL/dvLPh6m9Xeijppa/jmhEIDrj+hCemnTF
AtkHvK3S72c62jUUtEdt2BbFsY7ceMAxpWXIa8AbfWqPLB3tOTZFoWXwIRn2
q7kz4SAMTUJ6274Eag5b4fUmPMzZK6CwyDoqn7GkJhSFi7H7+1YHxZyxBcwg
UnyGiY8WvmNYG8Roe//w0Jfdq68Y2xCKnKywrxDPrfLyrj0apL1BPgNbbCic
bFRlXDuDP1W3/0aKWi5huCwCFxfT5US4NgXKPyq9kpXOtxx4rIPhtvHW98cj
g+tLuxfTFd5XK7g5FHtyCiYimxLNbScPHzFOuFPWpzPXt3S0W7bnLpbUkLZc
zyqJV5kmXCMEDwr85cLrzAg3j3veWs2bskjSP2w5Xsksrq1BUI36QXsOdl9P
aB+P+sLJmLX2Nb0PDfSNF1tt8YMtfeN6v13l9z7WWgxF/gUW2zNAhqu+BZLj
QT/jzNYziR28kgFh5+gfNtShze220RHD5oSajhhAZEbPcoebo46b6bDtiVl7
OlHYXBY9eYX0dhooSu/jQDn9gz5yWeE2KPFM3rA/74dSMtggerCWhj1fLfzL
KMKHPm0lC4SIne/pRSQ6zXfDQuPioR0Es72RPQzmep6M3z5J3NnMnptGM+7z
QdHzMXPGfdjDUGHz+YFyojWtQGbW2dyw+SAt2zZxDmSLKOgLqcD9io2b1GSy
r8zN3XS2xcM2F3EHRUsfe3pjT7wiPJ4G+hplcajW+3A4sg3++TzejPTdErSL
09pSl6m1KtxNjG4WvI5SmyjMtun4stRcOPMXcFnUxFVzRCrXcqZzO6fXPDwV
Z6HT8deOFxawwgheEC8/jbUaj7Hcgcju5DywYpCJ/aZ3lN93PPNYv+CQ1jFC
8Hi2Km+VdUDtoWKeO5zSP64d9lsPj2W5C3jkFk28YZtvPEQM1nju9L7eFNwe
9R+7aywYIr0JRmROt4PuI/TdKU7XaTiyDsomK+F7JFFmGfYKjS7sNVlaXfM6
+1OttsmIpMy3f/1rhrE6MV76g5HULN4TqdWVzafC4z7rjSIejt5ZQTdeeNeB
jxMjTu5zHDVuvRn7rFzVXHVAVdOluq7BnybmjEryhuRSnWnWAFD5bsM+J7g/
dx7mXyu9WNZtz5V9TPdE4fTZDbNcQeoDOmLnbsEJfbT1bnz4XZ3jDmASVGOo
DI8NC57WXaR/MT2eHqOXAJsKL6FTWuyaA60EOD9DIiuW8VIae4uBSzNOwKPX
PY27Y0KPM3v2lkOfm1Y+7e2fyOK4lVoCyPH05wxTaDvlVLStj4oOZmz9IUBy
LgA6ffLVl3B32JZSf5+Hh4AD7bd3tXiNESvsrTKe8sScvm1w7sMjqxw2MH93
eIAa5bkDVLsGjp5QdjLcPwHtU+bOfWTbUhsWyAQ5ibDYYz3z7nUdtYVSGSmS
Go4xXcNe5119DKOSahP+TgC7WBs9LkSSvMvCfgc2L9dBCescWuRHoD7qHJHW
RueZbZTPyrsCNkam/OtT6iNekuUbYsMUa6Sd8bOORmyRFH7HLshOktSuaoiA
wthb4TLbIJem55ljJueAnG10RKkYSFMJg4HGuBlWI1x0cxkP2bjWckawNd/v
5M4zoPKvhu/D4q8xqdFVDasAs0vhjH+4igB5FoucSK0tJqJ0GMi0/t0TG5bW
mbcWIzih4FNDkRBVO3dAP0TfuKoF3g2pGncz4zP27gCmRLxG3zlYABHTKSQk
9uaYDtP5yJjQN6Pv94+XY2qLwJLvAH/e0fsbsDgKTLTo5N8KTjw99+5VRFFJ
yBNs1f/fLO1LUixPvyl5K7D6eI3Xn2XAxmnHBAXqUQRGlCwaGA+m3AbZgj0N
XWwHltBcIcvB20p2H3ZUdVO5uASxdoOeAQ++hEKGsVVjppa6wG0lBLUFI/FY
ajEe8d1O9hOSdaU2/DaDLiGiOkpaKVnzHYcNuJOg+p8QninD1gv+sKOYb5GG
+u1AVCX5BAwAk5Lu0pOHqe7a7kO7i9mxzb1SaXcRq1t0KXGQwqJRRZfEd1Hh
Ol7rCksR/zJlk2RVK9dhTbYvwijdFg6r7mLePM6l4Zjki9nTtaUJz6H3JhTo
f71DrR19N32x+Fg4LSt88VO+bRuOsTwvC1U2RvyN9B9Uou6tgD1NUasGQGqQ
2FBGSzJsza5SMFXBt7vQuohn7PcyS4sjNh6FfGvImD+qEL7O3HdO/SO3iFtA
riCV+lyuiN6ok8CrZrQbBt6DW2Y8VQWCkHxPjxIfe1PSldPHJpwpe5eMvldV
EBkg04/6sN1UjE9JkKd9x4OjkG+tuyP+bIJ3pnJ6oQe9HKbCMkctNd+8bBsi
20DjNRLgy/WomQBfuURtYV6N44/0FAS1krHOr6Bi3Q1oN5DbK/7b1MJ+L79Z
g5oa97UVjLUJxDv3410CO1r5sSclgLYe5e1phLu8NpcpWgd7pXGA2NX5vQTn
XgP80MlLDg/YPQq/FWyz4fvrTI9wFDO+IQBsqYnDK7/rNN5XM0i/onKyp/r2
2mq04QYTHRMnp9/ndNMZ5/jaUazRK0X1hG1PPDnOs7PnFAuvq37LPpMufPKm
4XQ4rHJzDR7rxfhL1eBLhcKSGeScRZbYFca3Q1xKtqBM3bm4n/kIjxM3ef+O
iKEBu0ONnYIxZVOlVuz2INUSRNNRGffLBRy7qvFlrqStznrmFek23NErH7uZ
9yeT4rupfZSAR/+sunW/P7lXKA0TEH9KPnaiC6WMJIL2Ufzgupnh+yj9ixr4
TsF+iUT2/ACJg63U3iD2jbrPyf3eDyiw0NKh9FG29hgWHnjpDuoFdNNO5kCj
6Iqb92V7R1XusbMwCA237R6jDC4ajFjkPXkgZBqG83EexuPokIXdxty/KhFD
Cl/Kgey1YoVfImga6K2lnsDhvxtn7EAZxLfmtjNs0UHHS/7VOzDd72Gl9a9h
c4YtM3GIpL5DzJ1hlSndas2pLIqXpKk4Vg7fKTm+3yzhw17FCHM+Sa7s3m5p
v4TWXqnuuxaaJ3Aw3i3AUU83GSPMDOvz3peD6/vBAiOBvXtVH5sd9Sr4y1OZ
caUy3cNr7h4Oul7InvZPVJVlTe+jGT+EH8qO+1j0x8Erscbbh22874r2Eh7Y
2lvnkg6Qktk2oYOkmTTa2AYb71qsfVOMdC/g3J+d0NtGaVh7ABjdr+7FRbEG
zZG6XiyL4Vtc4pKLPrrtnm+vEcPqWF4ttbtGwMShpEcrAI620atkf/Fe7Y9v
d8js2xtM/zU+7m1TTtGJe0dNIDPv/at0AuJeBOPJMd5rQFlue/rhvUZJea+j
qY3K5x3QpivHsjM92xMCGnX/YoMncBGaaRowa98Kly7jVVg6unavGqJkVdbe
t0j6su0X0yZtjBUA1+ysnIxvgp1srBouT9+c7lEBn7fyk9J7gwy+a3Ym01tr
8ym+ISVX2cJey/r9hN8LorL/OJjL3KiDT/2Z7at+7UswcePCEFVhtWFeNbqe
N7ljjMTlvTSI//ELPv8hIcviVmzLhjr9u1eegNRe61slfmkKc1dW2AP5Y7ks
xPeVBDx2o1eg8zxXM6VuJ+I3if96RgMgrMBX18PiP5Tz+Uqyj78u5//7PxJi
ea7dC400nbfyG9RbsUTeZWTWdPI92/KrROlmn7Fvb3T8UAwHKVEYpvdJdmxM
7DjXENJdi7QS6Tr6Wu+CxpNV8s6+ZLBXPnnwfwq8RJBxZQAA

-->

</rfc>
