<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-driscoll-pqt-hybrid-terminology-01" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.1 -->
  <front>
    <title abbrev="PQ/T Hybrid Terminology">Terminology for Post-Quantum Traditional Hybrid Schemes</title>
    <seriesInfo name="Internet-Draft" value="draft-driscoll-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="2022" month="October" day="20"/>
    <area>SEC</area>
    <workgroup>TBD</workgroup>
    <keyword>Internet-Draft</keyword>
    <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 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-driscoll-pqt-hybrid-terminology/"/>.
      </t>
      <t>
      </t>
    </note>
  </front>
  <middle>
    <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 defend against this possibility.  Data encrypted today with an algorithm vulnerable to a quantum computer could be stored for decryption by a future attacker with a CRQC.  Signing algorithms that are expected to be in use for many years are also at risk if a CRQC is developed during the operational lifetime of the algorithm.</t>
      <t>Preparing for the potential development of a CRQC requires modifying standardised protocols to use asymmetric algorithms that are believed 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 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 types of algorithm.  Most post-quantum algorithms are less well studied than traditional asymmetric algorithms, so 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.  A designer 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 which uses post-quantum algorithms. Work on solutions that could use both types of algorithm includes <xref target="I-D.ietf-ipsecme-ikev2-multiple-ke"/>, <xref target="I-D.ietf-tls-hybrid-design"/>, <xref target="I-D.ounsworth-pq-composite-sigs"/>, <xref target="I-D.becker-guthrie-noncomposite-hybrid-auth"/>.
Schemes that combine post-quantum and traditional algorithms for key establishment or digital signatures are often called hybrids. For example, NIST define 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"/> and ETSI define 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"/>.  The word hybrid is also used in cryptography to describe encryption schemes that combine asymmetric and symmetric algorithms <xref target="RFC9180"/>, so using it in the post-quantum context overloads it and risks misunderstandings.  However, this terminology is well-established amongst the post-quantum cryptography community so an attempt to move away from its use 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 in fact be more general than this, allowing the use of solely traditional, or solely post-quantum algorithms.  However, where relevant, we focus on combinations of post-quantum and traditional algorithms as these are the motivation for the wider work in the IETF.  It is intended as a terminology guide for other documents to add clarity and consistency across different protocols, standards, and organisations.  Additionally, it 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, CRYSTALS-Kyber and CRYSTALS-Dilithium.   The expression "cryptographic scheme" is used to mean a construction that uses an algorithm or a group of 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 is a cryptographic protocol which 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, as well as to hybrid constructions for cryptographic schemes.</t>
      <dl>
        <dt><strong>Traditional Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms.</t>
        </dd>
        <dt><strong>Post-Quantum Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm that is believed to be secure against quantum computers as well as classical computers.</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 with more than one component algorithm.
</t>
          <t>In a multi-algorithm scheme all component algorithms are of the same type, e.g. all are signature algorithms or all are PKE algorithms.</t>
        </dd>
        <dt><strong>Post-Quantum/Traditional (PQ/T) Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme made up of two or more component 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 Key Encapsulation Mechanism</strong>:</dt>
        <dd>
          <t>A Key Encapsulation Mechanism (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</strong>:</dt>
        <dd>
          <t>A Public Key Encryption (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 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 cryptographic scheme made up of two or more component algorithms 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 in the natural way.</t>
        </dd>
      </dl>
    </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>
        </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, such as in <xref target="I-D.ietf-ipsecme-ikev2-multiple-ke"/>.  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>NOTE: A PQ/T hybrid protocol could be 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="functionality">
      <name>Functionality</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 encryption algorithm 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 authentication algorithm remains secure.</t>
        </dd>
      </dl>
      <t>EDNOTE 1: It may be useful to distinguish between source authentication (i.e. authentication of the sender of a particular message) and identity authentication (i.e. authentication of the identity of the sender).</t>
      <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 a post-quantum component algorithm is broken, the PQ/T hybrid scheme is likely to continue to achieve confidentiality against a classical attacker, but will be vulnerable to a quantum attacker.</t>
      <t>Note that PQ/T hybrid protocols that offer both confidentiality and authentication do not necessarily offer both PQ/T hybrid confidentiality and PQ/T hybrid authentication.  For example, <xref target="I-D.ietf-tls-hybrid-design"/> provides PQ/T hybrid confidentiality but does not address  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 support 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 in the OR modes described in <xref target="I-D.ounsworth-pq-composite-sigs"/>.</t>
          <t>In the case of a PQ/T hybrid protocol which aims to achieve both authentication and confidentiality then at least one component algorithm for each type of scheme must be 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.  For PQ/T hybrid interoperability the scheme needs to work with any one of the component algorithms, while to achieve PQ/T hybrid confidentiality all component algorithms need to be used.  However, it is possible for a PQ/T hybrid protocol to achieve PQ/T hybrid interoperability and PQ/T hybrid confidentiality by building in downgrade protection at the protocol level.  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 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, but it is possible with a PQ/T hybrid protocol that has appropriate downgrade protection.</t>
        </dd>
      </dl>
      <t>EDNOTE 2: Other properties may be desired from a PQ/T Hybrid scheme e.g. backwards compatibility, crypt agility.  Should these be defined here?</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>
          <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 as defined in <xref target="I-D.ounsworth-pq-composite-keys"/> 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>
        </dd>
      </dl>
      <t>TODO 1: Terminology for certificate chains and PKI.</t>
      <t>TODO 2: Terminology for algorithm specification.</t>
    </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 documents.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <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="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="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.becker-guthrie-noncomposite-hybrid-auth" target="https://www.ietf.org/archive/id/draft-becker-guthrie-noncomposite-hybrid-auth-00.txt">
        <front>
          <title>Non-Composite Hybrid Authentication in PKIX and Applications to Internet Protocols</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="22" month="March" year="2022"/>
          <abstract>
            <t>   The advent of cryptographically relevant quantum computers (CRQC)
   will threaten the public key cryptography that is currently in use in
   today's secure internet protocol infrastructure.  To address this,
   organizations such as the National Institute of Standards and
   Technology (NIST) will standardize new post-quantum cryptography
   (PQC) that is resistant to attacks by both classical and quantum
   computers.  After PQC algorithms are standardized, the widespread
   implementation of this cryptography will be contingent upon adapting
   current protocols to accommodate PQC.  Hybrid solutions are one way
   to facilitate the transition between traditional and PQ algorithms:
   they use both a traditional and a PQ algorithm in order to perform
   encryption or authentication, with the guarantee that the given
   security property will still hold in the case that one algorithm
   fails.  Hybrid solutions can be constructed in many ways, and the
   cryptographic community has already begun to explore this space.
   This document introduces non-composite hybrid authentication, which
   requires updates at the protocol level and limits impact to the
   certificate-issuing infrastructure.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-becker-guthrie-noncomposite-hybrid-auth-00"/>
      </reference>
      <reference anchor="I-D.ietf-tls-hybrid-design" target="https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.txt">
        <front>
          <title>Hybrid key exchange in TLS 1.3</title>
          <author fullname="Douglas Stebila" initials="D." surname="Stebila">
            <organization>University of Waterloo</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization>Cisco Systems</organization>
          </author>
          <author fullname="Shay Gueron" initials="S." surname="Gueron">
            <organization>University of Haifa and Amazon Web Services</organization>
          </author>
          <date day="28" month="August" year="2022"/>
          <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-05"/>
      </reference>
      <reference anchor="I-D.ietf-ipsecme-ikev2-multiple-ke" target="https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-multiple-ke-07.txt">
        <front>
          <title>Multiple Key Exchanges in IKEv2</title>
          <author fullname="C. Tjhai" initials="C." surname="Tjhai">
            <organization>Post-Quantum</organization>
          </author>
          <author fullname="M. Tomlinson" initials="M." surname="Tomlinson">
            <organization>Post-Quantum</organization>
          </author>
          <author fullname="G. Bartlett" initials="G." surname="Bartlett">
            <organization>Quantum Secret</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization>Cisco Systems</organization>
          </author>
          <author fullname="Daniel Van Geest" initials="D." surname="Van Geest">
            <organization>ISARA Corporation</organization>
          </author>
          <author fullname="Oscar Garcia-Morchon" initials="O." surname="Garcia-Morchon">
            <organization>Philips</organization>
          </author>
          <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
            <organization>ELVIS-PLUS</organization>
          </author>
          <date day="6" month="October" year="2022"/>
          <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.  The primary application of this feature in IKEv2 is the
   ability to perform one or more post-quantum key exchanges in
   conjunction with the classical (Elliptic Curve) Diffie-Hellman key
   exchange, so that the resulting shared key is resistant against
   quantum computer attacks.  Another possible application is the
   ability to combine several key exchanges in situations when no single
   key exchange algorithm is trusted by both initiator and responder.

   This document updates RFC7296 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="Internet-Draft" value="draft-ietf-ipsecme-ikev2-multiple-ke-07"/>
      </reference>
      <reference anchor="I-D.ounsworth-pq-composite-keys" target="https://www.ietf.org/archive/id/draft-ounsworth-pq-composite-keys-02.txt">
        <front>
          <title>Composite Public and Private Keys For Use In Internet PKI</title>
          <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="Massimiliano Pala" initials="M." surname="Pala">
            <organization>CableLabs</organization>
          </author>
          <author fullname="Jan Klaußner" initials="J." surname="Klaußner">
            <organization>D-Trust GmbH</organization>
          </author>
          <date day="8" month="June" year="2022"/>
          <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 implementors 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.  For digital signatures, this is
   referred to as "dual", and for encryption key establishment this as
   reffered to as "hybrid".  This document, and its companions, defines
   a specific instantiation of the dual and 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.

   EDNOTE: the terms "dual" and "hybrid" are currently in flux.  We
   anticipate an Informational draft to normalize terminology, and will
   update this draft accordingly.

   This document defines the structures CompositePublicKey and
   CompositePrivateKey, which are sequences of the respective structure
   for each component algorithm.  The generic composite variant is
   defined which allows arbitrary combinations of key types to be placed
   in the CompositePublicKey and CompositePrivateKey structures without
   needing the combination to be pre-registered or pre-agreed.  The
   explicit variant is also defined which allows for a set of algorithm
   identifier OIDs to be registered together as an explicit composite
   algorithm and assigned an OID.

   This document is intended to be coupled with corresponding documents
   that define the structure and semantics of composite signatures and
   encryption, such as [draft-ounsworth-pq-composite-sigs-05] and draft-
   ounsworth-pq-composite-kem (yet to be published).

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ounsworth-pq-composite-keys-02"/>
      </reference>
      <reference anchor="I-D.ounsworth-pq-composite-sigs" target="https://www.ietf.org/archive/id/draft-ounsworth-pq-composite-sigs-07.txt">
        <front>
          <title>Composite Signatures For Use In Internet PKI</title>
          <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="Massimiliano Pala" initials="M." surname="Pala">
            <organization>CableLabs</organization>
          </author>
          <date day="8" month="June" year="2022"/>
          <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 cryptanalysis, 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 implementer 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.  For digital signatures, this is
   referred to as "dual", and for encryption key establishment this as
   referred to as "hybrid".  This document, and its companions, defines
   a specific instantiation of the dual and 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.

   EDNOTE: the terms "dual" and "hybrid" are currently in flux.  We
   anticipate an Informational draft to normalize terminology, and will
   update this draft accordingly.

   This document defines the structures CompositeSignatureValue, and
   CompositeParams, which are sequences of the respective structure for
   each component algorithm.  The generic composite variant is defined
   which allows arbitrary combinations of signature algorithms to be
   used in the CompositeSignatureValue and CompositeParams structures
   without needing the combination to be pre-registered or pre-agreed.
   The explicit variant is also defined which allows for a set of
   signature algorithm identifier OIDs to be registered together as an
   explicit composite signature algorithm and assigned an OID.

   This document is intended to be coupled with corresponding documents
   that define the structure and semantics of composite public and
   private keys and encryption [I-D.draft-ounsworth-pq-composite-keys-
   01], however may also be used with non-composite keys, such as when a
   protocol combines multiple certificates into a single cryptographic
   operation.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ounsworth-pq-composite-sigs-07"/>
      </reference>
      <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/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">
            <organization/>
          </author>
          <author fullname="S. Santesson" initials="S." surname="Santesson">
            <organization/>
          </author>
          <author fullname="S. Farrell" initials="S." surname="Farrell">
            <organization/>
          </author>
          <author fullname="S. Boeyen" initials="S." surname="Boeyen">
            <organization/>
          </author>
          <author fullname="R. Housley" initials="R." surname="Housley">
            <organization/>
          </author>
          <author fullname="W. Polk" initials="W." surname="Polk">
            <organization/>
          </author>
          <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="RFC9180" target="https://www.rfc-editor.org/info/rfc9180">
        <front>
          <title>Hybrid Public Key Encryption</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes">
            <organization/>
          </author>
          <author fullname="K. Bhargavan" initials="K." surname="Bhargavan">
            <organization/>
          </author>
          <author fullname="B. Lipp" initials="B." surname="Lipp">
            <organization/>
          </author>
          <author fullname="C. Wood" initials="C." surname="Wood">
            <organization/>
          </author>
          <date month="February" year="2022"/>
          <abstract>
            <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
            <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9180"/>
        <seriesInfo name="DOI" value="10.17487/RFC9180"/>
      </reference>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8VcbXPbRpL+rir9hyndh7VTBEUpcRwzdXUnS/JG69iWTe3d
7SfXEBiSswIBGgNI4br83/fpnhlgAAKU7GT34lRZIjEz/d5P9zQcRdHhQanL
VE3F0Y0q1jrL03y5FYu8ENe5KaP3lczKai1uCpnoUueZTMUv23mhEzGLV2qt
zNHhgZzPC3WHLa7fH9/4r4Pt8EgsS7XMi+1U6GyRHx4cHiR5nMk1Dk4KuSij
pNAmztM02nwqoxVvEZXNFtHk5PDAVPO1NgZUlNsNVl5d3rw6PMiq9VwVU+yI
M/BXnGdGZaYyU1EWlTo8AGXfg8hCyamYXZ4fHtznxe2yyKvNVNy8vDg8uFVb
fJRgwwxHZqqMLogmrFRZRVsKET4uhD3e/bKWOq1/kUW8cr/QH1mVq5xoExF9
K8SiSlPL9qs0L1QWK3HhOLcP5MVSZvofkmQ9FX99Ld5KJ/bzLdgUMxVXhS63
4lxlZaHsImVpWLgtx8l/Z7GJx8v8blzdEh0k9GKNne4sOy+v3l5c/jq1q0tZ
LFU5Fauy3Jjp8XGS6zHIOD6ZjE8mk+fHL57/FH0fTb6fRKfPnp1MoucfT07d
Sms6TuOv1VZcZrHcmCplosUbFa/AjVkbIbNEnEEaoFqTMbjHf6MHlo6NRlr8
X+R/EDAaaPPtWLzUWaLS5nMryrc6k52vumv/grWQTc/iv8j4U6VSnanuE909
3ozFK6hqhWe7m7yB3ne+7K5/ORZ/ziGf9E6Z7gYvCy2z3a+7W1yMxaxUc53K
7gYXebVMpWl/XagFvKGEzKdtdz4vtpsyXxZys9qKzWZ8OvkxOj390a4yqtDK
kMnUqrh4dzUVD9sDe6A4nZy8iCbP6aPLm9nVx5vZyeT7589/GDC3+/v7sSqN
tTmIHzZaHNMHH0tzTCsnk4/014sX/NsPPxxPTsb8/8cfJ8el+Wg/vZuc0J/N
eJMsWtZ5/reXlx9+Fo71yMiFalmsM0HTb4PkkFPmQ9zMIILvBc4S/3Myxp82
06eTyMrh7dXs5uP1+/OPr87eD/AcmyIewzFK8tHj6yL/u4rB7YZ09MkRGgc6
Ol7IT6bF1bA6cepeXuqAcpUZbFaVSuQL2A08VBaJ9dQbOK5LBU+InacdVk+h
32jyzHMrZtfipwn4f3b6cEz5cXL60zGtGs+ux25Vi7XOjuJMQEALnSpOS3+F
C8ARVaIKCooN5zpmfb6RmVwiMWWlmG1NqdYDwug60GUqOQYgUMjiVhXN9yy1
Kx9BEdYC6fwq53khS2S2wY3fgHL45Vonf9iWFzKD8SBoSKhQ/hH7/lGWcfIs
OplQxhHiKroYz1UMUUZLyB4xJcoQ3/I1rFyXyid50svUP69VuYjK1PgvE8Sh
Zdb+Wm+Mitcq0rfq7jRaV2mpN6mKblX9WF5lBgm9XAFMRM2BSPPmoWdwnH3m
w6vzZ6c/TfzPL074Z/sniiIh56YsZFwK+9E7mI40G3gxiQxpDtgDymHIJMpc
hJ4tZAoopMsV0qLORNwy4U2RlzngAL4yvE+i7lSab9igsbUVjDAWfOEJWWKT
OC82pFwl5nm56pwGrZUBfJNmu16rssBhDSFjIW5WOBGorOKjErWAO+CADio0
Vbzyp2PRVUl0asoxCXI6OCXoVShBKAzxDXBkyxTEqWTYIuMiNzhHLxaqoINq
hkfCeEsb8RILhQwbpRl7wcOPklRZqf8HIbYiT6qYnjk8uIG8YPggThLKSGnz
eYoQQJIjIpdAUAtoDVzbffmgBIm7UBAeuJROMfkdPaozGAX+UinMH9yrNNUb
bC0AwpCmRQWuiw2UuIbEveZ7BSwqA/mQBGGGQoHVearNimVtaVjqEhSTvcsS
EsR5GW+nHShlFSmjaqaslFYMIvnc5rC5pNPsBuuRuNdpKuZK3FVphrCJ1aQp
WZYyviXKdLYUM0THPxlx5jeh1RLqXix0rEFluhUpBXWxVLQHgHoFmwM53s7I
iRAyipG4zfJ7LEbAaMdnmWKTDypVd1gh6uTl1okn5x/enz+tjYpMRMdwb/af
QiUaznUPdkekCb0YWVuU5CEaImAm1W+UVIX4Jb+H34AWzXtlKlbGyGJLe8G0
Ya1CLhHwobWS7B6cGA3gBBPF6gtZShgyeyZbdSK32B+eBZBWi7krzh1J4Icq
TUjwBhbn1J8o3pZsbw53QEVA2nbKwBp7jCBZgJIZzIG0E+iWXR7VDHileGO9
bk52QjbGZ6xlthVbJQvDD8rUkLYFjP4WgnO7s4xtcMEeCaoKnEN2hN8LnwlS
vVClXqvatj0d7I/XhdpIXken0vebnNCmxspO3HJnFupTpcm41zn0u6Wl3us1
mWwT/sAUsdPvTLUM5sCLOMjLwFB1pGrVdhViyCjv4cT0N2sVFo/IBN1TtKgf
q10tOJJOIwsmIoPwCudaETTpc77eiDNyUSXiqNIfe5pAE3Gg6X0qIKgV3puY
Tiq6aPQaZKRFka9bq/akKCwtKKxuScDkbQYKJBql1ybrmCwg0B4piPTH+Yjq
ZY7BjfkI8YZC5tChxBxgk9OWKatEE59A6g/nMgSG3BG6hH8y6fEqp1gFNqHk
OQE9OXC2d8BembKfJ9ZMVWwTiLM1igw9PkwrSPjG1+1YCv8qUWHRj3ea0iYC
gVPQ7pGQ1FmbF3bnhiG9BvyxeWSIJZnm2dLgqEG+SHsKdktKWuul9X9rJmBM
xblhLE3xl5SfIZD3Gx1rriYJvFGOotw3IlpzCB7+grCNj8yQ9sfif/PiljzI
5GnF6d8alI2ne8yKoFBaQVri8+eHAeOXL6PwuR3c2Xy/By02Dz0S7H75Asec
hfjNm+R+2NaIuB9FUG7ZBRGkjnyBoOxjhaUEMn5FKv9NkqpGtuaymM9DzN0T
bIyV4sjiPwc+Kc1bDqzRUKa4z4mcdc5AEDLIsDyI2oRKjKJGRwf94syofaaD
mkefP4dl9ZcvLB8uy3uo9iW9o/iIwGhZWJTYkXnbIcLV4/HY+XFLL51HEOMp
2BCEQhYIvwTJrfYH9M5pRVCv0ZNL0iN3ZnTYLgYcVkHg1+DBoRESsOmznTAS
QjK9WfPzZ1fJkM3yoZQaCCFlLnkHfHLj6LeSgXCaS+BfbZEqoQjkb20Y/HL2
xjYmBF0MqcLKQdtA3uiWAsOaglLZc3IoA/C3rjIKnBTUOcaq9YZtcQ3ShLxH
ROQ4pUsG2S5IpEoyKPDubs1EWwvwaMWgmiZGY7UpR8hmhh4mkWT06aIyvkJI
EdfJsF0Vw5m1XS+5WG7waLas5NICsT2G1/LtLBmOhQCBwHkaWDgIhxyvM5Il
yK1c3Pas9mOmnVLT2xHlFHxJKIW8hb3WgXyXccEpio00ze89lnBHgiDVTgUM
zt3HwyzVlmLzSeFqAvxOcosrLn6CoMJR/rHhUTJmIfRmQw04KvWdy2hO8/fQ
VUGeeOuNny4TdgtaLmJCS15WlEZpm5yAUW0AxkODutClojcsgr+18EX+Tzyb
6ZYrGqnXfB5qigqVT9cXhZznVel1VPqQc2RjzlEIgq1X0BJhVpJqlJb9NtTW
uTbUwnGoARfRWibPjnJlLagW1YhSSNsUa+0d2aqEIjoQg2SrtaE/6AhS+Kpz
EccVt8IheF+8QMIxJFS4TFXKW7BwB/VwyaYzPAqJ2+xogYOVxE5OsmrZcKeB
ciqSXFVi9RGUc2lTqPHQQ3yYnY3E5fnFLyMAwL/Nbs5+nUWv+e6GNqk/uqBi
c6UrAnicFlDOIQJxyDnqc1QWDecJCmuKYmFL2DXmNu0qlZE631+1oJI12HhF
5RPlOAlMimpbFh32wSmkCoigxssxJzi5LBSjO4amfaT6amEtIQ93rrD3dPTz
osqcebRBiNx3hSSevL5889TBjb4znbORCtnqQWRz0pS3/jNHNVuFtY8h1Vyo
4JMe3rzDhv02w5C2xjp98RU7tbi8+XXWx0W9u8XHNZD1UdqDvlr6lLBi8utU
blURAARrrUYV1MKSzZ0bcWW7ZteFXmu6DDQujRlXzGjXTus0/hCfpWs0DPit
GbVL695oYFNir4yIru++C2+Z60bUd99NDw+m4iwL89oAGY+svcWjam8xWHs7
clt3MN9Gr4fQv6OP0de/sPSde+i9Q9wlHH8/TXSFYDgqWO/tU5s7ZsbYN2o6
h7a48XLo91aG1uQ7dX3Q6S2R/1lUHTWk1a7u60ClOQsPlbUc+/phiCP+DYGm
b6GdHZ7h0X4urihOMzTb5QMJvW+lr9oajErZ10VgWkNf1zVeuI74dd9fv77s
9oLaFnscetsTGt142h7t2C+EILb3lnshWRblwaqAyqlPDoFxBBxqV1B3dufh
/u6I4ysYPNmTQ2qOHs4zD7KHp/7fWLyuAPxjz4UL+zVzvd9Cw68vnz5aeW3r
+fdyd+G6GDNv4TVnO/2NR/Ozu/Lfx50QzJ3LiLAbJMvwE8japuzww4FWjuQ7
Doc4wW24pJ1LQ4me25qzqAWJrLTKkxAWP+jDtp7hfbi+4l4oZQnwvktFQ8T1
+39xVAljqBXSUN1plXGz6mkG+OqmR54iJjidSHcV5PtN4RLw2FnjikpWHbR4
L7cOerUHFi5tm/T3wjDltrFV8UrpwuJHYzfrN5BeSmrwsqUrfclciiebgupn
xrkbDi5PfS8jKwmhUMHB5RQ9YUsj1FlpZYvILnhopWf7gMfp0P8tdzQ2w6u8
Gr38B0ThyzFLMEFnuJ1nxP1GIx/U5MLPsd7AnNwvrhSGOgD8XFHeRA7mbBdj
7ZVnP5UOWu0aNyltCDWEB1Nv+ZsO7s4NmKZ71JAzINkuMHmQWNEt8+q+eLcG
qnVFMbUTCxq6ApXus+VvD3uPZXxfTBzi0e1WY9x+/bhdgytkalNCUZkrZOzd
tw+Cg/Kxt4T1Uhs8digM5O5bLvtvRbjHR9IkZ2Xh6ewuT6mA8YTx7Eol0+sP
r3xDx+5sZ0/5FsTWoq4N9tUxMOhDPrY1CEErLhhASd1/6wNY7rvacurqvGmy
PJifbEvYd0xtr7mlbB/1JI0djP71MKTjhWGuq/lriKYOuE7sbT41NJuiS3YB
Ta30x5mO9jd5dS+cpg5s2uCI2OKYgTbx2uKNP3WXB572lEYORgPE7LkF5DmL
tU5lQf3VBwXTbqkMymUIrLZF4NPUw3NbO8Xw0AFmJ0N8hWkP9rb6kBEk7GZw
6BbGhtVQIW5wijhZ0/wNdZXT/L5uzLNPcKygu2xOI3eqMP4WMdyq8buBpoAJ
6+24zXpHl8j27n6Q0WKh17LQ6dYmHBdY7AhlHfP7M4If/ngU0wVN6Wd2iAqH
wfeZiGTMNNdX5u6+gwfKQjJTGG66df2hkNI2aameF5Lmt0euTQGcu6beUHMj
2vYZ/7wzmrd5FsW/23BqMDGkrJ7uRk/4s83sRwdA93hvCBwNGWtX0Q+BgK7t
0kQafbDlb7g/L5vG2WOMNdsV+TcYbMf+RvbmKzBAjjsUZrzVBiaxh1c2IJrN
6rXT0VcY6q7N7bfRAcNm0b19d3PJvY6+UF1jpsy1BylaF0RUI+YsDz5uaaDb
r+ew1Lb1nG7FjI3Z3TTJVtnKEFYVu+MUNZkJZ+923FrLjOBfE186WYfv0/yy
tgXZpQ5evQoxRgdi+eECEw4lMYPu/sbOeiX2fp0KNXtdlNjJxd2MQM/0aaS3
JdESmwsqN9ZMiJZtXWK2xEsg5xupIL+kQSi+1A3jRuPzwZRF47I2cBvXlO/h
5aylmkFWdjX4GE4G4MjDvHSO28vP5QU5lDiZ0v23Uz5C2aLiycDEXqtVMFx8
Ud4rRZNZVRHvWOUTPYb/dD70oZ5u1AsH8JrbRheinrLjWE2TFz1+33pN65yn
bkajf/KOieiXdy3hRG1oTNhNYde70CQ5QmMf4reOHq9yGkfuNJPqgs61aEQs
N9IOHDM1zfTgWJy342B4dH+3gDpUCMw0wDE0azjEcQNrmxu7lsNBJO6bzlVi
N0zuAPfevgaiZpHfKhcUewjCE00GoQaTzioV3lXvBFw/gBnchHlZjsQcNcXA
+Ht9rVZLnjNLXrp5gT6/M0ECeGz8R6BGhC7rIXTK3MEGbSvZ3Sz8fr8K9pde
zYjSvhNJXkmOh4himSQ0kiB2z70hsAboZBVv31OhYx6uAOspBk79/zd+Nnkh
YjLSBb8XauqpFN8vcG/iYCWPnXZk60b03Pxdy9B8dO2J2PyiL8+5WxdEzBYD
QftrEgz54dzG4FSVthlCOqe3frfNuC9vbAs+ab3TVBtA53IwlD++kN8tCtd6
uSpr7/Fzhx0BeC02yxwvqMegGZuiHJrij7bBVHmNtuuXAPqiQKswp8fefaC3
AJSpcUjSWM/egdsGPNtAantAA4nSjlP4iSkvBpZ+N0Nmu+5ADzyoFTc9HduJ
ZIb97jajMjxS59RrpRgq3nNiX1LJS/ceSuob5z2212UifGRHq9340WHPBZC9
W7BV2KMzpRKWIs/NufdhtrZL0K2ewqzoQGxD+N6QN3QnTqe7qqKy5UjnJZ89
smvgez8RXys41mOl08RNiyb5fYZCJVGtNwP62lPtmP2IcMliTekNLNd2xO80
QtTYFM92GWxZqsy49w1lckcx1dS2N2xQHpC4gSHye4MKMHZvRtnJMU2ox+9l
AqPwLw5q41lXiRssBpV/MvaNLPq1T0b2VQ2rkL15ySZya2KobqyAmdTSJXeu
NEGmC1KB2KhZbXmrE5sXSsMHU7LXJLoZxd4kchuApp0Ld9v1VWa1k1d7IkHX
4V3G29WklVHHF3qebteyK6ogNpT0Ck1XY31qCmuE06l4xxIOwGVfuShbzSNn
azzBMgfYuucXisnPwbkVzsgW/MBz/jW82YorZDvMO1c1LCDs8V/uOjVADr/n
AqGFQIZuTFv1a7NgZzwh2KxzTxrezPC987dOzgz0uPrvBPYMQIlODyUkve5P
+KHThYxJNfSd3GPGTdkfhOhHLWgc1Af73bZ6QOHP0DUSKdMa6q9NOMlZZ4kG
9qpkf24J/Ln/Fo27LA/KyfXy3dR47/UaBWHTT073VtPSU/WBm/D0QGRNedFB
e19TOP9swz6PYVu/sbClXUvaQpf62fRLUdFLt21UmglsF7kThj1i+BqyVQQ8
8Fo/8iQXenZ01jCMrfOQfPzVya7NO9C+X5KuGcJ6cv0MV3nydlxKfbtGbCfj
3cU76s90/5WmliGu3DAGzRRdNctOd5cFDWn3ckk4H9z8I0M0U524mWnTfefF
/xsBvt8Q+fc4WgG3gWwWKfn3JezBXEf0V9o8dVHPUAcvF6mGBF0CqywaJ1hJ
nmavOyCuK+IGguk1+uDe12Vw/2zcYrYB9f39N7IZ/14O5xJZBt8S6au6v6tN
XBknACK/llMtDSf4q7O3Zw8InfJ1ltsnZfCWBf3bCJRZ7UZnMb2En6pk6eaL
Pk/t/L1K/vNoIVOjjr7U9iHrh9XhwT8B/h6dRBRMAAA=

-->

</rfc>
