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

<t>One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms.  This document defines terminology for such schemes.  It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/"/>.
      </t>
      <t>
      </t>
    </note>
  </front>
  <middle>
    <?line 122?>

<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 (2024) 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, and that cannot be updated or replaced, are also at risk if a CRQC is developed during the operational lifetime of that product.</t>
      <t>Preparing for the potential development of a CRQC requires modifying established (standardised) protocols to use asymmetric algorithms that are perceived to be secure against quantum computers as well as today's classical computers.  These algorithms are called post-quantum, while algorithms based on integer factorisation, finite-field discrete logarithms or elliptic-curve discrete logarithms are called traditional cryptographic algorithms. In this document "traditional algorithm" is also used to refer to this class of algorithms.</t>
      <t>During the transition from traditional to post-quantum algorithms, there may be a requirement for protocols that use both algorithm types.  A designer may 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 implement a post-quantum algorithm alongside a traditional algorithm for ease of migration from an ecosystem where only traditional algorithms are implemented and used, to one that only uses post-quantum algorithms. Examples of solutions that could use both types of algorithm include, but are not limited to, <xref target="RFC9370"/>, <xref target="I-D.ietf-tls-hybrid-design"/>, <xref target="I-D.ietf-lamps-pq-composite-kem"/>, and <xref target="I-D.ietf-lamps-cert-binding-for-multi-auth"/>.
Schemes that combine post-quantum and traditional algorithms for key establishment or digital signatures are often called hybrids. For example:</t>
      <ul spacing="normal">
        <li>
          <t>NIST defines hybrid key establishment to be a "scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes" <xref target="NIST_PQC_FAQ"/>;</t>
        </li>
        <li>
          <t>ETSI defines hybrid key exchanges to be "constructions that combine a traditional key exchange ... with a post-quantum key exchange ... into a single key exchange" <xref target="ETSI_TS103774"/>.</t>
        </li>
      </ul>
      <t>The word "hybrid" is also used in cryptography to describe encryption schemes that combine asymmetric and symmetric algorithms <xref target="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 (PQC) community. Therefore, an attempt to move away from its use for PQC could lead to multiple definitions for the same concept, resulting in confusion and lack of clarity.</t>
      <t>This document provides language for constructions that combine traditional and post-quantum algorithms.   Specific solutions for enabling use of multiple asymmetric algorithms in cryptographic schemes may be more general than this, allowing the use of solely traditional or solely post-quantum algorithms.  However, where relevant, we focus on post-quantum traditional combinations as these are the motivation for the wider work in the IETF.  This document is intended as a reference terminology guide for other documents to add clarity and consistency across different protocols, standards, and organisations.  Additionally, this document aims to reduce misunderstanding about use of the word "hybrid" as well as defining a shared language for different types of post-quantum traditional hybrid constructions.</t>
      <t>In this document, a "cryptographic algorithm" is defined, as in <xref target="NIST_SP_800-152"/>, to be a "well-defined computational procedure that takes variable inputs, often including a cryptographic key, and produces an output".  Examples include RSA, ECDH, ML-KEM (formerly known as Kyber) and ML-DSA (formerly known as Dilithium).   The expression "cryptographic scheme" is used to refer to a construction that uses a cryptographic algorithm or a group of cryptographic algorithms to achieve a particular cryptographic outcome, e.g., key agreement.  A cryptographic scheme may be made up of a number of functions. For example, a Key Encapsulation Mechanism (KEM) is a cryptographic scheme consisting of three functions: Key Generation, Encapsulation, and Decapsulation.  A cryptographic protocol incorporates one or more cryptographic schemes.  For example, TLS <xref target="RFC8446"/> is a cryptographic protocol that includes schemes for key agreement, record layer encryption, and server authentication.</t>
    </section>
    <section anchor="primitives">
      <name>Primitives</name>
      <t>This section introduces terminology related to cryptographic algorithms and to hybrid constructions for cryptographic schemes.</t>
      <dl>
        <dt><strong>Asymmetric Traditional Cryptographic Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms,  elliptic curve discrete logarithms, or related mathematical problems.
</t>
          <t>A related mathematical problem is one that can be solved by solving the integer factorisation, finite field discrete logarithm or elliptic curve discrete logarithm problem.</t>
          <t>Where there is little risk of confusion asymmetric traditional cryptographic algorithms can also be referred to as traditional algorithms for brevity.  Traditional algorithms can also be called classical or conventional algorithms.</t>
        </dd>
        <dt><strong>Post-Quantum Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm that is intended to be secure against attacks using quantum computers as well as classical computers.
</t>
          <t>Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms.</t>
          <t>As with all cryptography, it always remains the case that attacks, either quantum or classical, may be found against post-quantum algorithms. Therefore it should not be assumed that just because an algorithm is designed to provide post-quantum security it will not be compromised.</t>
        </dd>
      </dl>
      <t>There may be asymmetric cryptographic constructions that are neither post-quantum nor asymmetric traditional algorithms according to the definitions above, but these are out of scope of this document.</t>
      <dl>
        <dt><strong>Component Algorithm</strong>:</dt>
        <dd>
          <t>Each cryptographic algorithm that forms part of a cryptographic scheme.</t>
        </dd>
        <dt><strong>Single-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme with one component algorithm.
</t>
          <t>A single-algorithm scheme could use either a traditional algorithm or a post-quantum algorithm.</t>
        </dd>
        <dt><strong>Multi-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme that incorporates more than one component algorithm, where the component algorithms have the same cryptographic purpose.
</t>
          <t>For example, a multi-algorithm scheme may include multiple signature algorithms or multiple Public Key Encryption (PKE) algorithms.  Component algorithms could be all traditional, all post-quantum, or a mixture of the two.</t>
        </dd>
        <dt><strong>Post-Quantum Traditional (PQ/T) Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Key Encapsulation Mechanism (KEM)</strong>:</dt>
        <dd>
          <t>A multi-algorithm KEM made up of two or more component algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.  The component algorithms could be KEMs, or other key establishment algorithms.</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 algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.  The component algorithms could be PKE algorithms, or other key establishment algorithms.
</t>
          <t>The standard security property for a PKE scheme is indistinguishability under chosen-plaintext attack, (IND-CPA). IND-CPA security is not sufficient for secure communication in the presence of an active attacker.  Therefore, in general, PKE schemes are not appropriate for use on the internet, and KEMs, which provide indistiguishability under chosen-ciphertext attacks (IND-CCA security), are required.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Digital Signature</strong>:</dt>
        <dd>
          <t>A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures are all examples of PQ/T hybrid schemes.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Combiner</strong>:</dt>
        <dd>
          <t>A method that takes two or more component algorithms and combines them to form a PQ/T hybrid scheme.</t>
        </dd>
        <dt><strong>PQ/PQ Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where all components are post-quantum algorithms.
</t>
          <t>The definitions for types of PQ/T hybrid schemes can adapted to define types of PQ/PQ hybrid schemes, which are multi-algorithm schemes where all component algorithms are Post-Quantum algorithms.</t>
        </dd>
      </dl>
      <t>In cases where there is little chance of confusion between other types of hybrid cryptography e.g., as defined in <xref target="RFC4949"/>, and where the component algorithms of a multi-algorithm scheme could be either post-quantum or traditional, it may be appropriate to use the phrase "hybrid scheme" without PQ/T or PQ/PQ preceding it.</t>
      <dl>
        <dt><strong>Component Scheme</strong>:</dt>
        <dd>
          <t>Each cryptographic scheme that makes up a PQ/T hybrid scheme or PQ/T hybrid protocol.
</t>
          <t>Depending on the construction of a PQ/T hybrid scheme or PQ/T hybrid protocol it may or may not be meaningful to define the component schemes as well as the component algorithms. For example, fused hybrids, as defined in <xref target="I-D.hale-pquip-hybrid-signature-spectrums"/>, may sufficiently entangle the component algorithms that the component schemes are not relevant.</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. Note that, at the cryptographic element level, the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements.
</t>
          <t>For example, a composite cryptographic public key is made up of two component public keys.</t>
        </dd>
        <dt><strong>Cryptographic Element Combiner</strong>:</dt>
        <dd>
          <t>A method that takes two or more component cryptographic elements of the same type and combines them to form a composite cryptographic element.
</t>
          <t>A cryptographic element combiner could be concatenation, such as where two component public keys are concatenated to form a composite public key as in <xref target="I-D.ietf-tls-hybrid-design"/>, or something more involved such as the dualPRF defined in <xref target="BINDEL"/>.</t>
        </dd>
      </dl>
    </section>
    <section anchor="protocols">
      <name>Protocols</name>
      <t>This section introduces terminology related to the use of post-quantum and traditional algorithms together in protocols.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Protocol</strong>:</dt>
        <dd>
          <t>A protocol that uses two or more component algorithms providing the same cryptographic functionality, where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>For example, a PQ/T hybrid protocol providing confidentiality could use a PQ/T hybrid KEM such as in <xref target="I-D.ietf-tls-hybrid-design"/>, or it could combine the output of a post-quantum KEM and a traditional KEM at the protocol level to generate a single shared secret, such as in <xref target="RFC9370"/>.  Similarly, a PQ/T hybrid protocol providing authentication could use a PQ/T hybrid digital signature scheme, or it could include both post-quantum and traditional single-algorithm digital signature schemes.</t>
          <t>A protocol that can negotiate the use of either a traditional algorithm or a post-quantum algorithm, but not of both types of algorithm, is not a PQ/T hybrid protocol. 
Protocols that use two or more component algorithms but with different cryptographic functionality, for example a post-quantum KEM and a pre-shared key (PSK) are also not PQ/T hybrid protocols.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Composite Key Establishment</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates a PQ/T hybrid scheme to achieve key establishment, in such a way that the protocol fields and message flow are the same as those in a version of the protocol that uses a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with composite key establishment could include a single PQ/T hybrid KEM, such as in <xref target="I-D.ietf-tls-hybrid-design"/>.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Composite Authentication</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates a PQ/T hybrid scheme to achieve authentication, in such a way that the protocol fields and message flow are the same as those in a version of the protocol that uses a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with composite authentication could include a single PQ/T hybrid digital signature, with component cryptographic elements being included in a PQ/T hybrid certificate.</t>
        </dd>
      </dl>
      <t>In a PQ/T hybrid protocol with a composite construction, 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>
      <dl>
        <dt><strong>PQ/T Hybrid Protocol with Non-Composite Key Establishment</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve key establishment, 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 a part of a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with non-composite key establishment could include a traditional key exchange scheme and a post-quantum KEM. A construction like this for IKEv2 is enabled by <xref target="RFC9370"/>.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Non-Composite Authentication</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve authentication, 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 a part of a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with non-composite authentication could use a PQ/T parallel PKI with one traditional certificate chain and one post-quantum certificate chain.</t>
        </dd>
      </dl>
      <t>In a PQ/T hybrid protocol with a non-composite construction, 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>
      <t>It is possible for a PQ/T hybrid protocol to be designed with both composite and non-composite constructions.  For example, a protocol that offers both confidentiality and authentication could have composite key agreement and non-composite authentication.  Similarly, it is possible for a PQ/T hybrid protocol to achieve certain cryptographic outcomes in a non-hybrid manner.  For example <xref target="I-D.ietf-tls-hybrid-design"/> describes a PQ/T hybrid protocol with composite key agreement, but with single-algorithm authentication.</t>
    </section>
    <section anchor="properties">
      <name>Properties</name>
      <t>This section describes some properties that may be desired from or achieved by a PQ/T hybrid scheme or PQ/T hybrid protocol.  Properties of PQ/T hybrid schemes are still an active area of research and development, e.g., <xref target="BINDELHALE"/>. This section does not attempt to be comprehensive, but rather covers a basic set of properties.</t>
      <t>It is not possible for one PQ/T hybrid scheme or PQ/T hybrid protocol to achieve all of the properties in this section. To understand what properties are required a designer or implementer will think about why they are using a PQ/T hybrid scheme. For example, a scheme that is designed for implementation security will likely require PQ/T hybrid confidentiality or PQ/T hybrid authentication, while a scheme for interoperability will require PQ/T hybrid interoperability.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Confidentiality</strong>:</dt>
        <dd>
          <t>The property that confidentiality is achieved by a PQ/T hybrid scheme or PQ/T hybrid protocol as long as at least one component algorithm that aims to provide this property remains secure.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Authentication</strong>:</dt>
        <dd>
          <t>The property that authentication is achieved by a PQ/T hybrid scheme or a PQ/T hybrid protocol as long as at least one component algorithm that aims to provide this property remains secure.</t>
        </dd>
      </dl>
      <t>The security properties of a PQ/T hybrid scheme or protocol depend on the security of its component algorithms, the choice of PQ/T hybrid combiner, and the capability of an attacker. Changes to the security of a component algorithm can impact the security properties of a PQ/T hybrid scheme providing hybrid confidentiality or hybrid authentication.  For example, if the post-quantum component algorithm of a PQ/T hybrid scheme is broken, the scheme will remain secure against an attacker with a classical computer, but will be vulnerable to an attacker with a CRQC.</t>
      <t>PQ/T hybrid protocols that offer both confidentiality and authentication do not necessarily offer both hybrid confidentiality and hybrid authentication.  For example, <xref target="I-D.ietf-tls-hybrid-design"/> provides hybrid confidentiality but does not address hybrid authentication.  Therefore, if the design in <xref target="I-D.ietf-tls-hybrid-design"/> is used with single-algorithm X.509 certificates as defined in <xref target="RFC5280"/> only authentication with a single algorithm is achieved.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Interoperability</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties share support for at least one component algorithm.
</t>
          <t>For example, a PQ/T hybrid digital signature might achieve hybrid interoperability if the signature can be verified by either verifying the traditional or the post-quantum component, such as the approach defined in section 7.2.2 of <xref target="ITU-T-X509-2019"/>.  In this example a verifier that has migrated to support post-quantum algorithms is required to verify only the post-quantum signature, while a verifier that has not migrated will verify only the traditional signature.</t>
        </dd>
      </dl>
      <t>In the case of a protocol that aims to achieve both authentication and confidentiality, PQ/T hybrid interoperability requires that at least one component authentication algorithm and at least one component algorithm for confidentiality is supported by both parties.</t>
      <t>It is not possible for a PQ/T hybrid scheme to achieve both PQ/T hybrid interoperability and PQ/T hybrid confidentiality without additional functionality at a protocol level.  For PQ/T hybrid interoperability a scheme needs to work whenever one component algorithm is supported by both parties, while to achieve PQ/T hybrid confidentiality all component algorithms need to be used.  However, both properties can be achieved in a PQ/T hybrid protocol by building in downgrade protection external to the cryptographic schemes.  For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client uses the TLS supported groups extension to advertise support for a PQ/T hybrid scheme and the server can select this group if it supports the scheme.  This is protected using TLS's existing downgrade protection, so achieves PQ/T hybrid confidentiality, but the connection can still be made if either the client or server does not support the PQ/T hybrid scheme, so PQ/T hybrid interoperability is achieved.</t>
      <t>The same is true for PQ/T hybrid interoperability and PQ/T hybrid authentication.  It is not possible to achieve both with a PQ/T hybrid scheme alone, but it is possible with a PQ/T hybrid protocol that has appropriate downgrade protection.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Backwards Compatibility</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties support the traditional component algorithm, while also using both algorithms if both are supported by both parties.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Forwards Compatibility</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties support the post-quantum component algorithm, while also using both algorithms if both are supported by both parties.</t>
        </dd>
      </dl>
    </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, 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>
        <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>
        </dd>
      </dl>
      <t>X.509 certificates as defined in <xref target="RFC5280"/> could be either traditional or post-quantum certificates depending on the algorithm in the Subject Public Key Info.  For example, a certificate containing a ML-DSA public key, as will be defined in <xref target="I-D.ietf-lamps-dilithium-certificates"/>, would be a post-quantum certificate.</t>
      <dl>
        <dt><strong>Post-Quantum Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain where all certificate include a public key for a post-quantum algorithm and are 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 include a public key for a traditional algorithm and are 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 with at least one being a traditional algorithm and at least one being 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 use a PQ/T parallel PKI as defined below.</t>
      <dl>
        <dt><strong>PQ/T Mixed Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain containing at least two of the three certificate types defined in this draft (PQ/T hybrid certificates, post-quantum certificates and traditional certificates)
</t>
          <t>For example, a traditional end-entity certificate could be signed by a post-quantum intermediate certificate, which in turn could be signed by a post-quantum root certificate. This may be desirable due to the lifetimes of the certificates, the relative difficulty of rotating keys, or for efficiency reasons. 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>
        </dd>
        <dt><strong>PQ/T Parallel PKI</strong>:</dt>
        <dd>
          <t>Two certificate chains, one a post-quantum certificate chain and one a traditional certificate chain, that are used together in a protocol.
</t>
          <t>A PQ/T parallel PKI might be used achieve hybrid authentication or hybrid interoperability depending on the protocol implementation.</t>
        </dd>
        <dt><strong>Multi-Certificate Authentication</strong>:</dt>
        <dd>
          <t>Authentication that uses two or more end-entity certificates.
</t>
          <t>For example, multi-certificate authentication may be achieved using a PQ/T parallel PKI.</t>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document defines security-relevant terminology to be used in documents specifying PQ/T hybrid protocols and schemes.  However, the document itself does not have a security impact on Internet protocols.  The security considerations for each PQ/T hybrid protocol are specific to that protocol and should be discussed in the relevant specification documents.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="BINDEL" target="https://doi.org/10.1007/978-3-030-25510-7_12">
        <front>
          <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="J." surname="Brendel" fullname="Jacqueline Brendel">
            <organization/>
          </author>
          <author initials="M." surname="Fischlin" fullname="Marc Fischlin">
            <organization/>
          </author>
          <author initials="B." surname="Goncalves" fullname="Brian Goncalves">
            <organization/>
          </author>
          <author initials="D." surname="Stebila" fullname="Douglas Stebila">
            <organization/>
          </author>
          <date year="2019" month="July"/>
        </front>
        <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
        <refcontent>Post-Quantum Cryptography pp.206-226</refcontent>
      </reference>
      <reference anchor="BINDELHALE" target="https://eprint.iacr.org/2023/423.pdf">
        <front>
          <title>A Note on Hybrid Signature Schemes</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="B." surname="Hale" fullname="Britta Hale">
            <organization/>
          </author>
          <date year="2023" month="July" day="23"/>
        </front>
        <refcontent>Cryptology ePrint Archive, Paper 2023/423</refcontent>
      </reference>
      <reference anchor="ETSI_TS103774" target="https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf">
        <front>
          <title>CYBER; Quantum-safe Hybrid Key Exchanges</title>
          <author>
            <organization>ETSI TS 103 744 V1.1.1</organization>
          </author>
          <date year="2020" month="December"/>
        </front>
      </reference>
      <reference anchor="ITU-T-X509-2019" target="https://www.itu.int/rec/T-REC-X.509-201910-I">
        <front>
          <title>ITU-T X.509 The Directory - Public-key and attribute certificate frameworks</title>
          <author>
            <organization>ITU-T</organization>
          </author>
          <date year="2019" month="January"/>
        </front>
      </reference>
      <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs">
        <front>
          <title>Post-Quantum Cryptography FAQs</title>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2022" month="July" day="05"/>
        </front>
      </reference>
      <reference anchor="NIST_SP_800-152" target="https://doi.org/10.6028/NIST.SP.800-152">
        <front>
          <title>NIST SP 800-152 A Profile for U. S. Federal Cryptographic Key Management Systems</title>
          <author initials="E. B." surname="Barker" fullname="Elaine B. Barker">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="M." surname="Smid" fullname="Miles Smid">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="D." surname="Branstad" fullname="Dannis Branstad">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2015" month="October"/>
        </front>
      </reference>
      <reference anchor="I-D.ietf-lamps-dilithium-certificates">
        <front>
          <title>Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA</title>
          <author fullname="Jake Massimo" initials="J." surname="Massimo">
            <organization>AWS</organization>
          </author>
          <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
            <organization>AWS</organization>
          </author>
          <author fullname="Sean Turner" initials="S." surname="Turner">
            <organization>sn3rd</organization>
          </author>
          <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
            <organization>Cloudflare</organization>
          </author>
          <date day="5" month="February" year="2024"/>
          <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 the Module-Lattice-Based Digital
   Signatures (ML-DSA) in Internet X.509 certificates and certificate
   revocation lists.  The conventions for the associated signatures,
   subject public keys, and private key are also described.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-certificates-03"/>
      </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="29" month="April" year="2024"/>
          <abstract>
            <t>   This document defines a new CSR attribute, relatedCertRequest, and a
   new X.509 certificate extension, RelatedCertificate.  The use of the
   relatedCertRequest attribute in a CSR and the inclusion of the
   RelatedCertificate extension in the resulting certificate together
   provide additional assurance that two certificates each belong to the
   same end entity.  This mechanism is particularly useful in the
   context of non-composite hybrid authentication, which enables users
   to employ the same certificates in hybrid authentication as in
   authentication done with only traditional or post-quantum algorithms.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-multi-auth-05"/>
      </reference>
      <reference anchor="I-D.ietf-tls-hybrid-design">
        <front>
          <title>Hybrid key exchange in TLS 1.3</title>
          <author fullname="Douglas Stebila" initials="D." surname="Stebila">
            <organization>University of Waterloo</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization>Cisco Systems</organization>
          </author>
          <author fullname="Shay Gueron" initials="S." surname="Gueron">
            <organization>University of Haifa</organization>
          </author>
          <date day="5" month="April" year="2024"/>
          <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-10"/>
      </reference>
      <reference anchor="I-D.ietf-lamps-pq-composite-kem">
        <front>
          <title>Composite ML-KEM for Use in the Internet X.509 Public Key Infrastructure and CMS</title>
          <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="John Gray" initials="J." surname="Gray">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="Massimiliano Pala" initials="M." surname="Pala">
            <organization>OpenCA Labs</organization>
          </author>
          <author fullname="Jan Klaußner" initials="J." surname="Klaußner">
            <organization>D-Trust GmbH</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization>Cisco Systems</organization>
          </author>
          <date day="2" month="March" year="2024"/>
          <abstract>
            <t>   This document defines Post-Quantum / Traditional composite Key
   Encapsulation Mechanism (KEM) algorithms suitable for use within
   X.509, PKIX and CMS protocols.  Composite algorithms are provided
   which combine ML-KEM with RSA-KEM and ECDH-KEM.  The provided set of
   composite algorithms should meet most Internet needs.

   This document assumes that all component algorithms are KEMs, and
   therefore it depends on [I-D.ietf-lamps-rfc5990bis] and
   [I-D.ounsworth-lamps-cms-dhkem] in order to promote RSA and ECDH
   respectively into KEMs.  For the purpose of combining KEMs, the
   combiner function from [I-D.ounsworth-cfrg-kem-combiners] is used.
   For use within CMS, this document is intended to be coupled with the
   CMS KEMRecipientInfo mechanism in [I-D.housley-lamps-cms-kemri].

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-kem-03"/>
      </reference>
      <reference anchor="I-D.hale-pquip-hybrid-signature-spectrums">
        <front>
          <title>Hybrid signature spectrums</title>
          <author fullname="Nina Bindel" initials="N." surname="Bindel">
            <organization>SandboxAQ</organization>
          </author>
          <author fullname="Britta Hale" initials="B." surname="Hale">
            <organization>Naval Postgraduate School</organization>
          </author>
          <author fullname="Deirdre Connolly" initials="D." surname="Connolly">
            <organization>SandboxAQ</organization>
          </author>
          <author fullname="Florence D" initials="F." surname="D">
            <organization>UK National Cyber Security Centre</organization>
          </author>
          <date day="21" month="March" year="2024"/>
          <abstract>
            <t>   This document describes classification of design goals and security
   considerations for hybrid digital signature schemes, including proof
   composability, non-separability of the component signatures given a
   hybrid signature, backwards/forwards compatiblity, hybrid generality,
   and simultaneous verification.

   Discussion of this work is encouraged to happen on the IETF PQUIP
   mailing list pqc@ietf.org or on the GitHub repository which contains
   the draft: https://github.com/dconnolly/draft-hale-pquip-hybrid-
   signature-spectrums

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-hale-pquip-hybrid-signature-spectrums-04"/>
      </reference>
      <reference anchor="RFC4949">
        <front>
          <title>Internet Security Glossary, Version 2</title>
          <author fullname="R. Shirey" initials="R." surname="Shirey"/>
          <date month="August" year="2007"/>
          <abstract>
            <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="FYI" value="36"/>
        <seriesInfo name="RFC" value="4949"/>
        <seriesInfo name="DOI" value="10.17487/RFC4949"/>
      </reference>
      <reference anchor="RFC5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author fullname="D. Cooper" initials="D." surname="Cooper"/>
          <author fullname="S. Santesson" initials="S." surname="Santesson"/>
          <author fullname="S. Farrell" initials="S." surname="Farrell"/>
          <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
          <author fullname="R. Housley" initials="R." surname="Housley"/>
          <author fullname="W. Polk" initials="W." surname="Polk"/>
          <date month="May" year="2008"/>
          <abstract>
            <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5280"/>
        <seriesInfo name="DOI" value="10.17487/RFC5280"/>
      </reference>
      <reference anchor="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
          <date month="August" year="2018"/>
          <abstract>
            <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="RFC9180">
        <front>
          <title>Hybrid Public Key Encryption</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes"/>
          <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
          <author fullname="B. Lipp" initials="B." surname="Lipp"/>
          <author fullname="C. Wood" initials="C." surname="Wood"/>
          <date month="February" year="2022"/>
          <abstract>
            <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
            <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9180"/>
        <seriesInfo name="DOI" value="10.17487/RFC9180"/>
      </reference>
      <reference anchor="RFC9370">
        <front>
          <title>Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
          <author fullname="CJ. Tjhai" initials="CJ." surname="Tjhai"/>
          <author fullname="M. Tomlinson" initials="M." surname="Tomlinson"/>
          <author fullname="G. Bartlett" initials="G." surname="Bartlett"/>
          <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
          <author fullname="D. Van Geest" initials="D." surname="Van Geest"/>
          <author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon"/>
          <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
          <date month="May" year="2023"/>
          <abstract>
            <t>This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.</t>
            <t>This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.</t>
            <t>This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9370"/>
        <seriesInfo name="DOI" value="10.17487/RFC9370"/>
      </reference>
    </references>
    <?line 348?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document is the product of numerous fruitful discussions in the IETF PQUIP group.  Thank you in particular to Mike Ounsworth, John Gray, Tim Hollebeek, Wang Guilin, Britta Hale, Rebecca Guthrie, Stephen Farrell, Paul Hoffman and Sofía Celi for their contributions.  This document is inspired by many others from the IETF and elsewhere.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1d63LcNpb+7yq/A0r7Y+xUd0tWnDhWaqtWluRE49gjW8rO
7C8XmkSrMWKTHYKU3DPlR9qn2BfbcwFAgAS7Jcezt9rJVCJ1k8DBwbl85wJo
Op0+ftToplBHYu9K1StdVkV1vRGLqhYXlWmm71tZNu1KXNUy142uSlmInzfz
WufiMluqlTJ7jx/J+bxWtzDExfv9K/d1MBw8kslGXVf15kjoclE9fvT4UV5l
pVzBxHktF81Uq2YxXf/W6jX8u5kuaZBp0w0yPfj28SPTzlfaGKCj2azh3fOz
q9ePH5Xtaq7qIxgTZoH/ZFVpVGlacySaulWPHwFt8LKslTwSl2cnjx/dVfXN
dV216yNx8f7X84vHj27UBj7MYcgSJi1VMz1FuuBdVbY4qBDxC0IwCX+GoXR5
LX7Cb/HjldTFkVg2zdoc7e/jb7LOlvpWzXCNs6q+3scP9ud1dWfU/vq3bB9f
w88e/Br+I9tmWeHqxRTHEWLRFgWz9nVR1arMlDittcmqouAHYCxZ6r9J3M8j
8esb8U7arT3ZACPFpcraWjcbcaLKplb8kuJ1LeyQs/xfysxks+vqdtbepCZ/
q7OlVIW4kLWBDfn9U694wNn6WTz140coU/UKRrrlnXp1/u707JcjfruR9bVq
OtbmlSZuPjuYPTs4eLH/8sUP029Bug6mh9999+xg+uLjs0P7JmuGFeg3aiPO
ykyuTVsQ0eKtAoJKbVZGyDIXx7ARQLVGWbePf8IHru0yuo2i/03dDwJ0AkT1
3Uy80mWuiu5zZuQ7XcreV/13/wjvwrYkXv6jzH5rVaFL1X+iP8bbmXgNUrKE
Z/uDvAXJG3zZf//VTPxUAX+KW2X6A7yqtSyHX/eHOJ2Jy0bNQfT7A5xW7XUh
Tfx1rRag6g3w/Ci2Vif1Zt1U17VcLzdivZ4dHnw/PTz8nt8yqtbKoMj4rTj9
0/mR2C0PZF7E4cGzl9ODFyh3TtJ+Pv7lbETa1LrWZTPTMqtJ6g4PDr/df374
7WydLyIpOxbvqkYJECtnX/V1KZu2Vs7SJqTIMzAtQSPyE78F+/azLFT8DmxY
08jgi5DXzF5yFOoClyeO2VRNQNnXoMVukTHbDoGrL6b4KX5+dnV5/vHq8tnB
ty9ePB9h3t3d3Uw1hvUVyIcp6n384GNj9vHNg4OP+J+XL+m358/3D57N6P8f
vz/Yb8xH/vT24Bn+sx7w/OTfXp19+FFYsZkauVCRtlv1TXEeuIjG7IjWIa4u
QXy+FTCX+NdnM/int/KDKcvQ+dWv06vpX747eDlFMdqybN20M+Dsfq2y/avp
h7OT6V9m7jUQyvNoHTSsoAfE1RLMvYbXGnC3QORFOy90NgX/RkZKNk2t5y1I
WqbqRi/IWolFDbuOTnHrUmmaoSrQYt+dX159vHh/8vH18fuRZWWmzmZgLhu0
3PsXdfVXINLsr1Fzf7NbkAWau7+Qv5loneNKDrNuJd27mfPSwGC4/moB1gRY
Iuuc7fcVmHOLf57gcp72NvEQxffgO7dacXkhfjiAnf3ucLen+f7g8Id9fGt2
eTGzb0VL640I5gAYtNCFIiz2KxhGMM8qVzW6ym7lOiNJfStLeQ02AlTxcmMa
tRphRt+snhWSPAMYDlnfqLr7njfc+VWwSgF3fpHzqpYoX6MDvwXKwVqvdP7V
hjyVJQgPWCYJWyi/xrhfSzKefTd9dsBW7Xx6SnhtWsjV2kxzXehmqVGwO20z
R4kn8fvpHIw0YMkpLGW6aotGT3ED48ebwjh0nIMbuy5To61/m2bVCjRLNwpU
f+WfWYJBtzDbDmKcm5maNehj3a6Yvg+vT56/fP7S/fzd4Q8H7ucfnj//3v38
8ln3+UswyEcMSqfTqZBz09QyawR/9CcQNElzIIMBKgE4h62kqEI0lQjtgJAF
RAvAOoBWuhRZJPDrumoqQLPwlaFxcnWrimpN4g9D88KEYa8JT8gGBsmqeo2i
oMS8apa92WCPmyDCkWazWikwlFlAyEyAbYUZIXBpaapcLUB5YIJe4GTabOlm
h5fOG6RTo+/MARfCSudKtAZ+BDwj0bEqBulAxUQsq7VCDL2Z4JMYxQAAwIAG
7CY8xUY8g9gAQTKAisoARXpBYzQdaybCOAme0CsMvA0Ju5m5LQL9zNHDP370
Txj41FXeZvjE40foRkCdYBESEW2BQ88LMCzIYVzMNfj5hUQvY0elaXIAibUC
JgM3pN3A6hYf1aVGR6NVAUoFXFJFodcwtADAD5BQtMCdeg2bvYKdcRKS3Ahm
HnIanZqChYKHM0vaE6bhWjdAsZdsg6gKh9M2tqOtVEb5RTGPlrQNNG832Vzi
bDzAaiLudFHgBt62RQnGGN7GfQKvKrMbpAxDwUuwuX8w4tgNgm9LEIsF6L8G
KouNKNBViGuFYxTTdQuyCeQ4eUTdBUNUT8RNWd2VLCiR1ZcgIeKDKtQtvCG8
S7TviScnH96fPPXChwKiMzAopGe1yjUo4R0sd4I7oRcTllmJmqSBBbRI9Qld
tRA/V3egX0CLprFKlSljJGALXDeGO3qNWoUMhKHXEGXjN6AcCuHGNTgY2M9u
fKepMPKpBIgJPMeFkWbkEgwseNrnT4EEUFKIGfxO9Dk+YBb80BY57o0BobQS
kisaHcVzDvoC4Skhat4veIenEcguIAghN25gbH3WrBbWkuD61Cc0Y16Z4RkQ
SZpvJcuN2CgIeVmk6JUMPFfVkNqvcwoO4UlgVSEzBSqPI8rCoBQJUKYb2BBL
Eu0dswxeyiEyBuJQPuH32vmtQi9Uo1eKdUY2jl5S8gvaEXwNqcNX1xWCeA0v
9symnbJW4B1QZ1YViM0GX/UqBkQ8cXZFg1o8DWwxsAKZkNZYzzmgO1MA4x3r
DMb7yotJf08Niv4dmAr8L8kH6BVYP2PIJvnHvEIHc+J0qCcwV2jsQYWXCKtS
Kp60axNru6Zku9IWrjNnUzJnyacCgkJnEzu30N+co9EJPc5e5KTck3soJiRA
ZBiBseRT8Ad6nfhFO9yNjbJx2slT4IkXdbWK6Bt3zRN8t0Y/scG9lE52iFaU
t0A6UABQPsj5dkqNOTTcvWPBYEbVNBps7ByBqRyZ2ultkh9kHvKcZlcZuyYr
X2hQEqrPrLLSiI4VXl0jYAM1gB9vNTpusB+WVcMpWf42RDvthF6tC+bD6BJk
UZXXBoYeXQeyUIFs4t6t9DVrPG8QLERllSGsj5a8xswBuITkQCx6niREHmCa
UFgIZFSl4v2hEeBjM7bhMwiJJQ5D4mSqoiU4Ya0cmV+/x7SzkdQhCCvaXE0E
xJ9EElrFQq80m9KJ+PvfLYr8/Bl/Gce8ve/ToBcfwoUOHtyCtT9/BtW4DJGj
E8XtgLFjdRqXoCsawhLkQbUAe+zsAi8S+Pwat555TYj6Gw4QHeS0EHc4D1tV
KfYYf1rwi/CB18EihJ7irkKiVhXBS+BaCa8HhhrRjlGYrOsZKJhzGs9poe4e
MDrMAnz+/CPSTfmRFN0uuWJp3kOQC+FHFomUMwMhs8O3xWw2c5oc7dDgIbDt
iBoQoIH1D79GwqNsFAkBQ2CsCYg9JrtnZ+O4ZMOgB6y+hsVYUIO8NilhCr0k
iFLSZ7IyQHiFckyTorVGEFZaRx4sl3JznxrC2kUlAWJrBsMIKMCXa0P4mpw3
DGNCXEdOIgxiNPvcaej35QqtVZOYOeTBE9j7p7jKVQsuczNDqwjOCIRsYm2v
Wq1JSldAqZB3YC/JnunGeAwFY1hjUihJ/oz0E1SB5UizhDhAY+SKIqRMrZsJ
uCCDDyOnSvx00RoXmwDcukHRt9GT3ePQv1pbb+DR8rqV10zPFsGMbECZj9tN
wJYAGTEBEJhNsu8lshjIba2dd0tNA6lBMOzEy/pg0mcbViCpjCCA+UVR3Tlv
b6cCQlTPZWD0yp+Or8TLDbud2gYh8DuyK2sp2opej9BOZ4YI3DUM29jiAPmN
vrVuzm7vHWxIjXp44wQfi36DYDwMsXtxdSja1y06XBy7Quzi3zcONPjQGsPs
MOz+0lAbsE3uVk9RfUS21CvDiA0guxroqZDzqm3chjUDgxSgY1YNfEWYpcT4
JxLijnDvmEf3yFrpSO5JW/qAdIKeZgS/7nHwgnYfYxwSXXYQQZoTTZt3WWRz
7BsW2rsYB5gNoVJbW4fWyBtYwi3sFIWDuoRHgfnsShllMCcGrmti41SMkNAB
gy9sG3h7D/bJYxuLU8SHy+OJODs5/Xki3v4yfXP2VjzBJCNY2E0XmL/BuuVT
GhYeOr08Tj106vKAGJNTih5CSDBVZJv2UhpN7BvgeRltikfVZrDUDnTB3ksu
XZPtGwk2aPBsqdUtgW4J2DdrQRV6LwCzYGPAmKvZ9WxCXlRe10rZgP44aZy8
bZI5RsAca3LNHn9etKUVsRD1oGhtqbiKJ7AdTy2ySc1pdRfFgDQHiOxmOqKh
fyIzySFeNA0LyakKPkoszhmAMLdoCEx7XJWy1DBStMyrXy7Z1WNW9fPn1JL8
TC6VidJpvOl3iNPvBHrBDO1EITeqDsAIL8yoGjNysitX4wI5CXhRIxzXVKMl
A2tsBKVtdrCX7wTrL20iZFS0CCxXSavC/jXJJkK93xx3XjBsQYkrID7R9s03
AJaPxHEZes8xxbhf1C9Go/6J6OUw0w9RqoeZlMynzrhwcLz1KZQKH6ZlYLUw
dVIVtxyW4k/Ot3/ZYoYJ2dRDlhhL8Z/J/XMGAMgDA9eALaYEFhqaDnp1W3Gf
tActj1D2XLHhq1m+ECyMh1zYgUSIM5KTkWFttNUlkhjl3aI69N6zchhVHr9M
3lwo1qsE9DJgcSZ5az4slQfjrbkYKaUkeOAKr+CMNKIOClV/CwviPV6AqBob
cRXRLm4oQywLwPQGNm6F6yGRzDCFwYElLw7chyb05UhE9rvFTJy7WFRtkEAe
xaM+wsDZzZLiBptthREBptgk7F9bgx9mkrKUYWKZcAoln3LOj1MQEM/oM0Mw
CWXH7RTIeYhfMBnqYsYgITYmFImIgtIhli3RzCU68LQKhTY2Q4NPRqCyNbEu
UgIQeWuzLh3cRlyJQUBWrS24DICdlfoTlxgYiPwZgIXtko4gyBCSYIefsvJ2
mkuKyaddvYQTME670g6eRBBtos9eBOk4Z1M52p92pHl04HJVluVjKThCT2nZ
s8S/pdzRw2jvlyQN4wWK10aW5MItUqjh10Ys5a0K4uEYQHB9ybKlh7Js8qvP
IpRhB4R9UOpzV+HMCHfcA9xt4pCby4E8uXhz9jSOIk9Sa/AVHDQtwYZQ/NrL
4tPOrPQnosYVlO+qmUgY7NAlPMEm1adxE6vfrRFeMOthzwolsTiZ3iKGbmPZ
Xuq9CQagh9PJZLuCoJl2JxIeXQFGLQHwTqb9wi1ILPVrLYsDn+SsfuOBXMZM
HJ4nCrwDzxywaYv0jTIIvuxE/n8Nn5DqsBBzf47x6C5lMSh5cAuDDNlCmCXn
YKqFUeUco9kNV+xFtgTLUk7X2ElEKUh28hPx5Pzd6fTk4hhCXvtT4EUNOdCu
JM6NEwyFbPqQ4xKf7QSAQtkcdCbgvTMMUnwxh3nmMo3wik2BTYJ1GF9ykGtc
bK2p8w3mpfRK3CHAkRJL4x2Y0KWHBZYV45zI9BpICVhhLCtOOgY85aqvrZfl
CVE+tdUC3wU6KsCDusK9xXn45n+NgFuQiqu1QSEzOvwE9o33IPxwpIQiqVuh
K0yFr8ThZMjhE87h1h1jVbOs8jDDtNMKcJaQxiGsS7VHRD6oQQMqOiIu3n+R
AyqKsFZD9fQRWNxp+iBl7tJ/CS5xgJBL245h03fRK0B5/I7TD6QmTb1Jkd+v
Tkb+ureQ85JiCNNBoCjkREfIhqELOuequVOqtEbRL8DlIMKaBaeypE9WcqLS
tr+5GuIO8EUId2TvvM1OoXvckBDnQHjhgofASNneCrKDyxrDqb1oE/YIDSOi
p02lGgruFBjNTOVcNhpA+kjyEng+xKorUgewJSmxtvP5T126ygrhqVorTmZb
GxulMIlz9x/TMajiPgEbha2UxNT3oi1CqY02y/uAoJ9kZDd7ecgFZWFtZXYo
KA/oqxQoTUh21AoG/5ZUkxyVLrZI6eVYl+aqMDaNF+fHzrju/3tTesoOYxub
lK45QDDWTSctbpISnzfZYA+tJP0UT0DYb1HasXGEgNxTV2wDDmEyQZac6ie0
Q2l7cSuLVlnIsiUDzg+4/C+KM5Xc1uNvOQvqLMcIK1yExAQj+gIRcQuxvzlk
BD932ADLRlymge2oVWNrR50rppWZgdZu5WeaSht/pwKWctRspWJFkvftTRkk
pQVK9h8MrX8puX+VdxAdakdIxDTEDIst4TaX1vxD2yKnE9cF8kXcSgTnLrrt
SB8RBxuHUghOQr2Nw3zgB6ebCKfgSYoKbNRj3nblbd/qMvISKLr6hFG/rYdi
KoQqOgRxFzJTQ2oHRjG9TEDbyUzCGEndPiNVPViaFIdtxuPLgdt9N20bqtvB
dp95Sm+KHTXoVcXGBRCy0ubpuU/WI50x/girVfZVttYDCgO+u/rrdu2l8j9y
EwWMmKfLWy4zOMIot9jK4uLD69gP8kk42zqDhSRbHn+w0wk6FO7bcwWMVoSt
uFuXJ07lB+x3XnLiyhpVUndifg4EXb0lkW1zbkZibDj5xwdSPS1MwqaOaMTI
EMdSCzDGrl0qVPZDMr/p9xMd7XoAfXfMUjk/TS4oWjGOT2uN1kaf2i4jRzuZ
P5QMDuqx19y1cUUudBLT61sJqbF7heepsf9iJ4Piuugof8bC7pgVDh/sPnMy
SFWPTdBVDGPpxditVNdVwyFDp0VfnuLmmgHiSxhmpKtz4pI5acZiPlZ01qBr
BN6pZzg1Jfm71pWterbo1GBc1taIx1lo0Cw+ubh887RrwMdlpBZhfFY5YUyY
yA5zUPYxzMB5a5MUvCHcSMZDQX/GIMVHyMyesMCOOh8v+EnssRvkwQpPb2BT
UFHd+b4rsmJk3fEYCoGWW1Ub1ysaDhX2nIyUVx5gl4h3nccaZi9jNfKK37NU
PdXfclpOWA91v708jmzB197I2NL839nFpAXduoUDWzcJxtyG3eaKWz1p7JzX
HA4cHLt0qaRta4jwXZCmmAjXrExJt1qvZK2LDWNZi1n4/KmHk2mC3emTe+0r
F9H5rBh25pdMRI7nusqun58bDSd8cC6ks9A31OBZ+e4rS2pMW6HntcQ7ESzT
AZTB+goR9GfH/tg9v1OR3lXl9CsaxqAMmZRYs8NKJpCYVYH7YjH7eNKRjupv
XzB2yXRfnfGgHn6woW/45GhQWP9K6lvCXj3EEI925Fs7Z/1tzw3PMDQK838o
o9x7gP77/M3Z7SGFrtgWzd1NYM4tlLuP7Y5F7vfZ7wfJW9+Y/7+w3VvYdiFu
mB6blQpx8ea86/uImsmCuyxADHXps0XxWYX+Y4zrdjqFmNyHOoaenedETmjo
KWRAeO28Q2B5t2wb2WnqPPq9/mBo2re7ghH/wR6WUk/AKqPnhcvWpRWO6PCt
VzQhBRmBZJT5FuYPemllT5srDByMGzSOe0ndUoJHjTSxJfSdtQmCem20Uayp
H8ILZ0hQSOXgnIftvDYMcZAEO8RKliUVwANO7ITA/qRSH6RuA+ZBf7GPzQb2
YKSr2B2n7GWDOjIw7xQeu7Rlp40TETrQjSeFkIfMqZyPdD+gICUCSsZKoKgo
psEWv6DNoFYSn8ceBLyEja8Z6I5Pu354YHt3IRR6KxGvtlI2VO7OQbkeQgVc
M9q16dWSQvYMj3PhFs2lwYqcIivccSlQOBw2EjQ0fg+oq4WeDNbexQuOXdqe
/bCLgaVVojurAoaLT567x8P2Bjr4b0/3YnLEH0StuZcS84039qjL3XITuh8+
xpEopfcVv3fe0VuVRTghq7nvQqHJrVG0tMbBQ89k9Hg39Ph0rtyRQjPjIumw
vu0UoSlTc/WfTDYsRORYNHPVbdPG18sisjGB+IUag4gAjylTCWFX+xv3sdoD
Ta5dhmTG0+fagrnTJ7HGJGAbLrFnuO+5whFT949f49XI2fItxW9PXU7lc1c7
96PgLSyNSWbObBVuWWmu8cQizQUIdzsFdmevnXDa1irfU3USe/1w7nQ9EVOQ
oGx458/YcfqxJXf513HlS+pdHwPoRep07JDWMUJgK+d1dYN3o9AaXLcx6S3F
4/2O/eGdAsPOfOcyk5fHpC8l4Ps7UtnIANzcG9vknN10t7cgRg0GGOE5XYpz
H6Zvrw5052pH5kHedM4xz/Fk3OjEYaPfwva6E6zZWaXwR+rS0IXvzwsv6kp1
BeFFWDAU3ZXQ47HdPJvfivuCrXlKmLzznuUHoydGrN5DLLc9JYQCWKiGK3i4
93S5VHerBQ3M1QnJGsole9OuIQzmvsxdVnF39DesZaz09bLxkGPECboN7l6z
qwJYBHvE1t6WN+ijTXChSXioedwiTKLKJjVdYStUsOsOvb2YHc4O0WyAkMXX
OFKJyZ2N7UoQlsiaebyUxl7iwWVOx+DRa89Mh5/gcV6eveSjv5owbWpByHBy
1C1PAFmi/phxOcoO6UNkf5SHa3lRoOU8ottPvuUl1g57ojpU/MlWCNRdRWQP
D6WlsDfLeD4l5QXs+f4+XrKbwwIWasc2xL0r3U/jbF1wv9+1T5nr8pP+RHlc
BBNkJOLCqTXV2+d11JZK5bSRdN4ec0F41H/bgYdRTvlMd8eAbUsbbQ5FkoJL
88ILCHi6DltY4+Ch4KAa4DmDtLa6yO09EXl1V4Ji5Cq8M0h9wlZwvgBpmPQY
Oc37oBYp23AAv+Mh4I6TdFrbEAElVW/oboJbXKXpWeaUyDlkZ8/5IleMKhSB
MtgxPguuF3RejscyAdRxNyswpG34njMOxIDKPxi+Fw5/TXGNbiqxG2C2bbg/
joZflJblRGpjQRIlqLQvXwdso6MCtDYPGhxT8KkhS4iqrRrQd9FXLiWKV6PU
rbuY5AG6O8AtCavRNw4WQKT2FCIUmxvoJZUS78S2GW1/2Eyc2rYELHkFgPSO
bkDFdDoswqOT/1ZwEuxz71qR1Ik5vujNX54TXz5mULr4ow7wjJj8mDeg8v+z
WbMr+vmKvMGLcKnlOMDNv6fnK8LfY13FUVqke8EXeBzeDBP+cS9x2ExHxyK+
9MBXuqkm3cW15SCp6JWlolKFaxZ094EsZIYSx61Q40YnTHx6p3mvFzrD6tzv
sAEqoPBH2Gos0sS3ipse4ZwQyzUIcJtW2fDcSrrvcVuBv5vO9wNIM9YQSaeq
0+T0+1CZntYh37HZA5Z1MXYvwOmx22ZZ2S1yYoUdN+ZVf2R3TclMVhvWvziZ
wqkeTEvgL3WLV7bGgRggmTKf2hnGFSLNJ5u3oBM+qNGcVHV52Xv3rA1F2OXO
tjLGVG1tj/y5gpklyB/z/x0MTl3t8GXGxMf8gYAletm3nLeztER3nHxlUkJD
tYuSB6VC+gecerH3WAXW2NRmcDIoOpmAH1y2c/wjAeHBXrzofVj3i80A8YJF
1N7JFEo0VrktxoxP8tzr8nY6xHPnD6qPLm+HdGFyVXcdCcMCdnBmLviu67/Y
Lmo9T1SrvuruEMzowOKIVH7ZEsy2NWxxpsMlbBfo/pHLFF740hXIfqEo+hKo
VXScLtw3bzsJr+9GG4TqQwDBnW73xhvu8S2QYwvgoMXbO4ewvQQtMBnaIEG/
29RKa2jZaztsYaMY9pXUIo75J5hlRhfpFBR1U9lVmx7yiBpBAoM0V0V1F271
W/1JPWynQ6Ph+Ei7ZG+WoAvEIrNLndCBAeELVPCPhvEdEynhmGyxhv2G8PDL
p4xD+lYvfHzEyXeXorP4UXksIoIi2ZXKdQ++uYO9uLS2Lu8xUl3BjoYmkDMJ
YRWfah556ztP3OXlHZaJuMVHngoWB3+LPQkXSJOkNIQ9PsaH/JQ9WJlheCEN
9Yhsrb4NJYE7D0CA+tcgj58/sXCky1RJeGBjrxeTlDWdzjdTyp5iKT8KYy4C
oXYhJJ776RNmz8iNe5xe55Pc3iE1Ef7eIYvJujM0nbJaAOyCk0gBOYXv/5jF
diBWjyZOBiigO+sb1e2j+3ZC1U43+cXzp8/3pHXGof5Y2/gQX8jG3hLduW2X
fYyaF0LG2aaY7k/d4VWFub2K0PTvpHVXJzsJnrqjvlEsHfxVEcpnultNDd06
S2WRdCmRDp36XGZwJ7AK7lZtjCoWXYBDHVIyuM2DS77AA/fHE8OTE7H+ZdFi
7RXn2TKdCyGn7+7NJYshm+BbJH3prBLeV9ca42xxdzGtH8EVQi1v7DacH787
3rEFXD3hJ2VwHSr+BZW5zG54oOMMr/ssVH5tD1v//YgvuVT5P+8tZGHU3uf+
yPYP2Ni/2IAWCV4B9WiBM3WrGzzRbhdG7ApuwOW/Q8nZXGKyLG/EpmrpDFx3
fydw7S222P6pLc1dVWOP4R+rZSl+qiVA4Su9gj0HwZwrdTMRf5b4hyxb0Esw
D69q/yfgJuIDPJFlEr4ET6jhg8tGrbFV9LWsgdF40YoEWn+uFouVZBt0WS3+
498lOOFCu8t8NRVb+A+Q2f69xC2+Zk1Fr/mG/5oGXeFg7N8lcIsnkAUsJYA2
e/SffulOhMl0AAA=

-->

</rfc>
