<?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.26 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-driscoll-pqt-hybrid-terminology-02" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <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-02"/>
    <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="March" day="07"/>
    <area>SEC</area>
    <workgroup>PQUIP</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 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-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 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 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="I-D.ietf-ipsecme-ikev2-multiple-ke"/>, <xref target="I-D.ietf-tls-hybrid-design"/>, <xref target="I-D.ounsworth-pq-composite-sigs"/>, 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>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"/>;</li>
        <li>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"/>.</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, CRYSTALS-Kyber and CRYSTALS-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 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 attacks using 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 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>
    </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="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>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="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 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>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 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 in the OR modes described in <xref target="I-D.ounsworth-pq-composite-sigs"/>.</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>
      <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>
        </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 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>
      <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 Dilithium 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>
      <t>EDNOTE 3: Do we want a definition of multi-cert authentication or something similar?</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>
      <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.ietf-lamps-dilithium-certificates">
        <front>
          <title>Internet X.509 Public Key Infrastructure: Algorithm Identifiers for Dilithium</title>
          <author fullname="Jake Massimo" initials="J." surname="Massimo">
            <organization>AWS</organization>
          </author>
          <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
            <organization>AWS</organization>
          </author>
          <author fullname="Sean Turner" initials="S." surname="Turner">
            <organization>sn3rd</organization>
          </author>
          <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
            <organization>Cloudflare</organization>
          </author>
          <date day="6" month="February" year="2023"/>
          <abstract>
            <t>   Digital signatures are used within X.509 certificates, Certificate
   Revocation Lists (CRLs), and to sign messages.  This document
   describes the conventions for using Dilithium quantum-resistant
   signatures in Internet X.509 certificates and certificate revocation
   lists.  The conventions for the associated post-quantum signatures,
   subject public keys, and private key are also described.

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

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

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

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-06"/>
      </reference>
      <reference anchor="I-D.ietf-ipsecme-ikev2-multiple-ke">
        <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="1" month="December" 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 (EC)DH key exchange, so
   that the resulting shared key is resistant against quantum computer
   attacks.  Since there is currently no post-quantum key exchange that
   is as well-studied as (EC)DH, performing multiple key exchanges with
   different post-quantum algorithms along with the well-established
   classical key exchange algorithms addresses this concern, since the
   overall security is at least as strong as each individual primitive.

   Another possible application for this extension 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 utilizes the IKE_INTERMEDIATE exchange, by means of
   which 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 up (during rekeys or creating additional Child SAs).

   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-12"/>
      </reference>
      <reference anchor="I-D.ounsworth-pq-composite-keys">
        <front>
          <title>Composite Public and Private Keys For Use In Internet PKI</title>
          <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="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="22" month="October" 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 using either a Post-Quantum /
   Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or
   combinations thereof.  This document, and its companions, defines a
   specific instantiation of hybrid paradigm called "composite" where
   multiple cryptographic algorithms are combined to form a single key,
   signature, or key encapsulation mechanism (KEM) such that they can be
   treated as a single atomic object at the protocol level.

   This document defines the structures CompositePublicKey and
   CompositePrivateKey, which are sequences of the respective structure
   for each component algorithm.  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 alxso 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 [I-D.ounsworth-pq-composite-sigs] and
   [I-D.ounsworth-pq-composite-kem].

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ounsworth-pq-composite-keys-03"/>
      </reference>
      <reference anchor="I-D.ounsworth-pq-composite-sigs">
        <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="RFC4949">
        <front>
          <title>Internet Security Glossary, Version 2</title>
          <author fullname="R. Shirey" initials="R." surname="Shirey">
            <organization/>
          </author>
          <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">
            <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="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization/>
          </author>
          <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>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8VcbXPbtpb+npn8B4zvhyYdUZadpG3c2dl1baf1bZM4sbu7
91MGIiEJa4pUCNKOtpP/vucFIAESlJy0d+/enWksEcB5P885OFSSJI8f1brO
1Yk4uFHVWhdlXi63YlFW4qo0dfKukUXdrMVNJTNd67KQufhlO690Jq7TlVor
c/D4kZzPK3UHW1y9O7xxX3vbwSOprNWyrLYnQheL8vGjx4+yMi3kGg7OKrmo
k6zSJi3zPNl8rJMVbZHU3RbJ7PjxI9PM19oYoKLebmDl5cXNq8ePimY9V9UJ
7AhnwH/SsjCqMI05EXXVqMePgLJnQGSl5Im4vjh7/Oi+rG6XVdlsTsTVu98v
rx4/ulVb+DCDLQs4tFB1co5UwVpVNLipEOECIZiE/4KtdLEUP+O3+PFa6vxE
rOp6Y04OD/EvWaUrfaemWtWLaVktD/GDw3lV3ht1uPmYHuIy/OyLl+H/ZFOv
SuReJLiPEIsmz1mwr/KyUkWqxLmVLT8Ae8lC/69EbZ6I338Vb6RV7NkWBCmu
VdpUut6KM1XUleJFivla2C2n2X8UqUmny/Ju2twiHajWag073bG4frp8c37x
2wmvrmW1VHXHX1ZqYuloNj2azb4/fPn9D8mzZPZslhy/eHE0S77/cHRsV7Jx
Wpv6VW3FRZHKjWlyIlq8VukKuDFrI2SRiVOQBlCt0dzs45/wgaVlo5MW/V/i
/iHALMFe3kzFT7rIVN59zqJ8owvZ+6q/9u+wFmQTWfx3mX5sVK4L1X+iv8fr
qXgFqlrBs/1NXoP6B1/21/80FT+XIJ/8Tpn+Bj9VWhbDr/tbnE/Fda3mYH/9
Dc7LZplLE35dqQX4Ww0yPwkDxlm13dTlspKb1VZsNtPj2XfJ8fF3vMqoSiuD
JtOq4vzt5YnYbw/k4+J4dvQymX2PH13cXF9+uLk+mj37/vvnI+Z2f38/VbVh
mwPxg41Wh/jBh9oc4srZ7AP+5+VL+uv588PZ0ZT+/8N3s8PafOBP72ZH+L/N
dJMtAus8+8dPF+9/FJb1xMiFCizWmqCJ2yA65AnxIW6uQQTPBJwl/vNoCv8L
mT6eJSyHN5fXNx+u3p19eHX6boTn1FTpFByjRh89vKrK/1EpcLtBHX20hKae
jg4X8qMJuBpXJ5y6k5c2oFwWBjZraiXKBdgNeKisMvbUG3Bcm2yeIDtPe6we
g36T2QvHrbi+Ej/MgP8Xx/tjynez4x8OcdX0+mpqVwWs9XYUpwIEtNC5osT3
O7gAOKLKVIVBseNcp6TP17KQS0h9RS2ut6ZW6xFh9B3oIpcUAyBQyOpWVd33
JLVLF0EhrHnS+U3Oy0rWkDtHN34NlINfrnX2l215LgswHggaElQo/4p9/yrL
OHqRHM0w4whxmZxTekxyud6YJNO5rlcaDVtVtV5QFjAnkSfx+2QO4RxSdwKs
JOsmr3WCCgwfr3PjwEgGAWtZhF/rjVHpWiX6Vt0d8yabXCW3qn2sbAoDyKJe
Aa5J0nIN/qdrfGJr9j0Dx/Ez71+dPX/5/KX794vjH2bu3z88f/7dCQOBJEmE
nJu6kmkt+KO3YG3SbMDxUcqQGQEQgT4Jx4m6FH4wEDIHfAbyg0yqC5EGVr+p
yroEBAFfGdonU3cqLzfkA7A1i0gYRoTwhKxhk7SsNmgPSszLetU7DRRde5hS
mu16reoKDusImQpxs4ITASo2dFSmFuBBcEAPqpomXbnTYdFljXRqTEsZwADg
dK5EY+CfkL4k5izFwAiomIhVuVEImrYTfBKRY6UEgkgInvDUlmhNAY8hJpJp
VRqgSC9oj7oTzUQYZ8YTWsI4y5DFm6lTEThplivWz98QblZl1qT4zONHNyBZ
8CpgQyKEyXHzeQ7xBWWM7CwBni1AvyAf3pcOygAVVArEDPKQVoXlHT6qCzAk
+I/KwbdATirP9Qa2FoDwAAOIBuRTbUDda9CNs5GoKlh8KGswXaGA1XmuzYq0
wjQsdQ0Uo4/IGiQI5xW0nbaImpSpjGqZYimtSBF0bnfYXOJpvMF6Iu51nqMK
75q8gJgMq1FTsq5leouUIQC/htD7jRGnbhNcLcEwFhAGNFCZb0WOGUMsFe4B
dUYD1gnkOItEx4N4VE3EbVHeF2wqQfCXYCPivcrVHawQbWa068STs/fvzp62
5ocmolMICeRplco0uOE9sDtBTejFhK1Woi9pEAExqT5hxhbil/IePAxo0bRX
oVJljKy2xDfiW71Bv0IBwtYbqG3wG3APsHghl5BnQJ/d/s5XYedzWUswcvJv
8o1MQpyFhPvsKZAAbgogsdVEX+IDYcE/mjxD3RgwSmshmaLd0Tzn4DFQkaBB
WH3BGj5GoLiAoGuwGFRgGH827BY2liB/6hMGstad4RkwSTpvLYut2CpZGXpQ
5gaNQ4CP3IKc7UmkEpYE7JFBhQNnotnB35XLSrleqFqvFbuCrB0Z5L1XJGhc
hofi0k2JwFfDwl48tEdW6mOj0RXWJVjDFpe2ngNEPHEBQ4O1P/WCLHCIvMUd
sRUI0J0qgLJOIgbrNtVqv68qgxZ9DxEA/0tqB3eBsAb1NIaa9rHWT70z8Tg0
fzjLj+LgmSsETTHPjYariQ1JCYWkeODqolRCUSr6lEdQkEW61IEaO++07CW+
RVWug1XjmXCCaysMyluUMPqSAYUikdJpl3SOFuHpD1WEGqS813kTtgxQvqeC
wYSqaOd0VWIgAjJACXOEiHKEIOc6UZ7JQ7OM6FApZwdrC+jTEe/DFSgc4yp+
WLpB6AQmC/+805g9wYWtAIdHsq1siQtyu44VvQYkxOlhjBmZl8XSwCGjHKFY
FVgU+tRaL9lPWYHAkkpLQ/gbwypqpYD4HDcHMpiWJAQCECcxpVHOLwvFOqMd
4GMzZhBTKOYkbkMp2ZR5Q9mdV3MsbPVO2qZo0PIDmChvMjUR84Z9uChrCDpr
zXFtIv74Yz+2/Pw5eG4AUbvvdwBLfAhl4G20Fxp//gxede1jPGevu6Fdp4U4
fsCUMYQPKJ5yAQHWOTozCSp4hVbBaiDs+y3Xcw4cWjA6PIfDpBQHjBQtTMU0
z3ywdWHovy+RqHVJQBDEVsByL/IiKjEKuyg9nAxnJuGZFpQegKD9ov3z5x+R
bir6Y3S7joGl+QDhaF0xTuzJPvQdf7WYTqfO3QMNDR6CYI3ZHYEUhHP/ayQ8
aLGQETBUxY6pOGCyD0iQGAIIKIYVxJbBCYRxDcxY8IGyNjFj8tMemFI0Cf7x
hy2K0I7pUAz0CJYKm5k9dqlB9akmTJyXEqCwZtCKCAGSszaEgykbwzbGx181
1h9+uaE5iSZ+IpdrDGR15GRfBk9A90+Ry3UDOXA7xdAJpQgY2cQGaLXekJWu
gVIh7yGoUqjTtWmxDuxh40yuJGV+FxnYjjRbiEMoBop55D9Vm3oCGcvgwyip
Aj9dNMbVEDkkBzR9W+dYHfu1l00IBh4tlo1cMj07DDOIAUU2HlIBAwK0w3rd
i6gU+gsUMZDb2BTgWI0jo0HZ6szLpm/yZwv/kdSCtAvCz/Py3gEFexQQonrZ
BOtM/nSck9ZuOCNVtliAv1FcaUNVUbDcP8ELQ4TWasZhHHGA/Frf2Qxo1XsP
CqnQD2+d4eOVyKBs9ovhXgXsm/aywVyMe5cIe9r1xiGLtgjGgtgvkL+2KAYo
lDnuqf4OyJZ6TUdDXdEAqX0/FXJeNrVTWD0ISB7cZdfAJcKsJNYpgRF3hLc5
e1RHNkoHdk/eclmE5E8w04T22JrKAVcjGPcBgUgyXU4QXlcSQ1ubsijm2BUW
q7uiBYSdgoQqm9BqeQss3IGmqGzTBTwKwudUygCEJTFIXRNbT2LJgwkYcmFT
w+oD0FMLeyyEEe+vTyfi4uz8lwlAyX9c35z+dp38SvdHuEn70bnryaGbY9KA
Mg7CEMWdg5i3kmgoh5DmQS9cefoCbwG2GbDRYS3C6HRpR3Et/hSbdrrS6o5Q
twTwCzW7rHoLQBAgdAjUarqcTihDymWllC2qT6OBp407EuTFZEjBt5X470VT
WPPxEQ2azY5rLvHk14vXTy1qiZ1p/RJVTF4BRHYnndDWP1MI5HosOIYN4Fx5
H0WYc87td/gMYegWM8WiMOwUsHnz2zWncexhfv4cY6k9yTUU0fJMG9Ydmmw1
gRkuxRiQy62qPKDBjBlVYVdMdneEyCA34q4qROGaLsYoeBpbQmnboet1HSGy
S9uMGDUtAsJlNGJw7oyKiRDtt/59e9vT+vZbwLsn4rTwE+CY/T+sEhcPqsTF
aCVuyQ3uir6OXofG5ypHbxzpaoRNv509jlhvg6k9c5h+QOoFxILdFOLFh6FA
wf4cU6I95prgdNK1JLl2clKJ+y/hdXSmtvDwym2+9ji1QD3pSGud31WgSlMK
HyusKTjGYYwl/jWVfV9BO0UAQle7ubjE/qwtLvt8ABqIrXRFYQdtMV//aIMy
LsLv2xrSX4gM2++vGgCVqQuyrhR5cvXrxdMQzJ3FKGgbnridJ1w+P+yOkZTX
+hMR425g7suYz/j+/gTHaJ6GYzat4EckxngT7BPKAmzlx0XPQXasHYOtY38D
ejje97EceOM+e3PWKAfwpZ8io8U3PeRpIcLuP4+1HQYzyhR82aGAPbzhs/8q
3s5t4+XaOc0oR4MWzYP5G678/+NWCOLW5mCwIoDC/icgewYH/ocj3ShJFzRd
+89fEmZvX8JnXA5XnWBVvSozH6zHxdZDEraspqqQer2YiYD3IRUdEVfvviqK
+NGXWR+reFnEN6tI98FVUhEpiRT7HZm0N1C2EgqWAOXhGrprwPssbMdHqTcx
8vvJIwi6PUb+1pv1uOBu8Z9FhMpuw3hwpXTFUNbwZnELilLS4qktTkNIEph4
sqmwLUDoe0OR6qnrwxQ1giYs5KgKxCe4ooPyMG+49t1ZQPEDrnwAT6dZR/D1
0VXOIpwqR0ThqkgmGFE8KNgxYv/CaRns28G/U70B1do/bAUP6gAsatsKXWgh
zoZAb6c841RafBfLouPQxfIfVDpU3O/u1yMySHO8p/7GEP8ryUMIrEEMEB0h
gdAwBi52wDnuurQP7coLZ+6G4Kuk1R/6MF27riN9xBz6kO5LJWzVRLT3SshW
VpgpeqkqKtJdDvj1wfyhjO+K9GM82t3a6iCuH7urd2WPfWFQVGELQh4XcFF0
VD7CWqZdyhFvQKEnd9fe2u0B1F1FaWKEIeHp4q7MsRB0hNHgUSPzq/evXPOM
d+ZZY3szgbW87T5+ceD2GsAPvdICQSsqtXhogQ+OgUj7XWs5YXODmll7cQD3
4F2rmpv7gbJdqJa5rreTfz646nmhn+tb/jqi8cpBZzwygX3krlyVfZjWKv1h
pqPd7Wt7+YCTHZzrKIwHHFMxgbwGvNGn9hLH0Z7jXAdaBl8b4MiNuyUL0tBk
hN4dl7g0+rLGOX/sfO+VXdi1GhXdGEoPpeTS7/65vEGnYewAM0giX2D9o53E
GHgECdvJJrwh48jr68yOuyEna5yawiZ/Xt639yjkNhROcFSBMs2dqoy7+/W3
6lxzpONi/GZGGrLe0yWgGHunS4C60mtZ6XzLOcnGHp6qbdNCPGm4qZsHMV3h
ixsFj77hbEPBRGRTormdiOD7mAnPAfp05mC5+db24nxSQ9pyPa8kzvRPbBMI
aoE1dt66a+zQr9zz1mrelEWS/mnLaQHHmLYG+TYaIu3FwkODpH08GiYnY9ba
1/Q+oNA3XhwkxA+29I2bbXVtyYdYazEU+VdYbM8AGcn6FkiBB+OMM1vPJHbw
SgaEc3F/2lCHNrfbRkcMm+/4qEMNIjN6njtIHQ3cTIcd88ra5nZh+7IYySuk
t9NAUXofB8rp35xQyArdoMQLTMPxvJ9lyWCD7MFaGg7ItMgwo+QfxrS1LBA9
drGnl5Ho6tMtC42Ll1p09sqHKD2E5mZEjD+JRgzaqzSev8t4LgKlz1d3GQ+a
DrOFoJGJoX6ifZpAbDbe3LAFIS3btqwOxIsY6SupQJfFGTi6lN/XuuXpI3sl
bocx+Ma5pY+DvbF3JhEeTwOVjbI41OxDOBzxhH8+jxfnb97eXIijE5y8toYC
EXHRkBtmfBvagJHDF/W9gsBpyqZKBxb8RE8V3iOEn7qUgeMTlQWT3TWxDXVP
ycvYLNDlvmDjdlFw0NN2yio2nElUxLXQyj1TG1W4IfpuF3yToDbR8sK2IVYl
jqP3Oneuepy4LpZI5UbOdW739CZMp+IsjKj+2fGGCvYDIcTjmytj86hjLHcI
ubtnDfwTZGK/6V389qPqIjY5NqR1jBC8uqzKW2Wja3sllucOhPWvModDucMr
Sx4VHXkBIj7Vy8PqEVc0Xq54aKqAmE5Dqu4NBMz/3gYjMqcXOx4i9N2lXTdz
NnIOyiYr4XskUWYZTpaMHuyN21ld8zn7S8x2JIWk/N/TF7OXwn/FrB0xcg0J
+5YWrKSJ4p5Ira5sHRleztk4G4nd9GY6vazAXgfRW4yE7y9JQeh6c47Guaq5
24Kqpjeiuilw2pjLRckOyS1K02wAffMA/L7wvr9nMCwu13q5qtsJHfuY7onC
6bNbZrmCug50xGnLIi/6aOu9FuDP940HgKDAx8fevse3OpRpMUvW2dHOuetu
WAzJ5GZTH865FOj45vcIQiuyQ3i+P4RXWwMpta+j8Bkj2uqdMl73xIKjHQnt
AyRrJawI34o8VI0uvANZu5ntnlB2Mty/1+tTho6II4SyHUIMG2iCnClsBtkI
tvtcR22hVEaKpBFNrNlwOnTX7fyopNqqvxPALtZGL8GQJO+NSH9mlY/rUq51
ohb7EbKPBhGktdF5ZkeLs/K+gAIqU/67KOoTvgfIr9sM66yRIbEvujqxTVT4
G2fLOknSEKAhAgpjX32V2R1yaXoRLGZyDvDY8TGUioFalbAKaIxHDDXCKreX
8RCAG8ZlDFvzK2w8vQRUfmP4lT/8MyY1Gm63CjC7FM44gVsJUGyxyInU2mIH
qomBTBsHPbFh6515a3OpEwo+NRQJUbXTA/qp7Ma1LnCavmrcLPsX+O4gnUei
Rj842EQb0ymUJPY1HB3W9JE1YWxeYSGzQTepNDaEY2rzy5LjE/GWJO55Vqya
lUHby9KJk01iDhDvnl6PR48G/llEE3YhwJP0J/aTV1TA89j4XLWYBIHPv9sb
bg+2/JnrkQD+jF1iB+V1t6Bt5bl0723Wu7r2751oqmDfDcnYjUd8DC5+4bFj
Lg6v1wIv9ChvuyduenkhU9QM3xqM23LXlPBi8YMWdP7qovrwQsCj8EdQNWQT
otVXX0g4ihlf/wLc18h4EvHGPuJXhINMEZWTvYWw7yRE7w4xJps4Of0r25vO
OMfP9gTW1TM9dPklZfqPnANomp+dhjN3WLhyWY0lIP5RNfiKd4iCIT0WWWJP
GHeH8RvWoPzY88MTUJZQUUnzNBgAuEfJSUk+/MpnaPGuZbNTkrb5Qnqy7RNb
5dJ2VMp9vUZiw5VfF3vaCs2TdGTSYsd0W2SW+68mxY9r+ygR4stq11a9DjKE
xVJYKPlbcuuJXkHgOicYncEPrps5/h6RP1qJvynTh3+yFzhIHGyl7Yslnkwm
A2Ye9hMxAnHkfTvYO8rZHtvCvpcuujEZn3Tyfk5OimbMvS/bFxvkHlMLE9fQ
c/fYZTAdOGKUD+SByosQAozzMJ57hyzstuf+fGMMXXwtB7J33Rx+CcQO9dZS
T6DxX41NdiAT4lvz1TpeQ2LspRDr9U33B1npmuDBBZRF0ZxWaewCW15wypRe
/Mip6sM3awj7l8PfBRr3N0v4cFQjwpxPkusqtC7tVwjtezj96EL7BDHGG90f
DXaTMcLMsP3gfTl45ys4YAQMdD+2wmZHlzH+8VRFrVWmexjPDc9i9G2qYv9G
VVnW9ILyeC9+KDu+qNOfBj+fMD49ZVN+15OQ8MDWvrgkqT+WzLcJ9cnm0mjj
V1bP8DcJ8c3ae0k/M9GNILcvC1OYH5i2P2pmeAbHlkfe+y72lWTpfpppf6VE
v0RFy9r+YjQOuDfkY8MtI23aWEXFI93ikjx0oduhxPb9IDgdq9JSu+lMJg41
ONoecrSNzpWjlLpfCMWXDTP7MqHpvzHuftjAmVDiXocOpOb9Ohe1jtw7x54k
45cZNPfbto28N/aV9+ZzbVS+6GD/StJ7nq1R20sn0Kn74VdP5CJ0gDRg1v42
SbqKtwqoN+7eaqfSWdbet0j6qr1t1yZtjBUAkt/KyfhG2MnG3qRfnr453aMC
bFYUJT8pvZeV8ZfIsK1grT7Fn7zKVba08+5/nPBrqir7t4OFzI06+Ewl1tvz
t4/+D8dWMuY0WAAA

-->

</rfc>
