<?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.5 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pquip-pqt-hybrid-terminology-02" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.19.2 -->
  <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-02"/>
    <author fullname="Florence Driscoll">
      <organization>UK National Cyber Security Centre</organization>
      <address>
        <email>florence.d@ncsc.gov.uk</email>
      </address>
    </author>
    <date year="2024" month="February" day="02"/>
    <area>SEC</area>
    <workgroup>PQUIP</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 112?>

<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 117?>

<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 are also at risk if a CRQC is developed during the operational lifetime of that product.</t>
      <t>Preparing for the potential development of a CRQC requires modifying established (standardised) protocols to use asymmetric algorithms that are perceived to be secure against quantum computers as well as today's classical computers.  These algorithms are called post-quantum, while algorithms based on integer factorisation, finite-field discrete logarithms or elliptic-curve discrete logarithms are called traditional cryptographic algorithms. In this document "traditional algorithm" is also used to refer to this class of algorithms.</t>
      <t>During the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that use both algorithm types.  A designer may choose to combine a post-quantum algorithm with a traditional algorithm to add protection against an attacker with a CRQC to the security properties provided by the traditional algorithm.  They may also choose to implement a post-quantum algorithm alongside a traditional algorithm for ease of migration from an ecosystem where only traditional algorithms are implemented and used, to one that only uses post-quantum algorithms. Examples of solutions that could use both types of algorithm include, but are not limited to, <xref target="RFC9370"/>, <xref target="I-D.ietf-tls-hybrid-design"/>, <xref target="I-D.ietf-lamps-pq-composite-kem"/>, and <xref target="I-D.ietf-lamps-cert-binding-for-multi-auth"/>.
Schemes that combine post-quantum and traditional algorithms for key establishment or digital signatures are often called hybrids. For example:</t>
      <ul spacing="normal">
        <li>
          <t>NIST defines hybrid key establishment to be a "scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes" <xref target="NIST_PQC_FAQ"/>;</t>
        </li>
        <li>
          <t>ETSI defines hybrid key exchanges to be "constructions that combine a traditional key exchange ... with a post-quantum key exchange ... into a single key exchange" <xref target="ETSI_TS103774"/>.</t>
        </li>
      </ul>
      <t>The word "hybrid" is also used in cryptography to describe encryption schemes that combine asymmetric and symmetric algorithms <xref target="RFC4949"/>, so using it in the post-quantum context overloads it and risks misunderstandings.  However, this terminology is well-established amongst the post-quantum cryptography (PQC) community. Therefore, an attempt to move away from its use for PQC could lead to multiple definitions for the same concept, resulting in confusion and lack of clarity.</t>
      <t>This document provides language for constructions that combine traditional and post-quantum algorithms.   Specific solutions for enabling use of multiple asymmetric algorithms in cryptographic schemes may be more general than this, allowing the use of solely traditional or solely post-quantum algorithms.  However, where relevant, we focus on post-quantum traditional combinations as these are the motivation for the wider work in the IETF.  This document is intended as a reference terminology guide for other documents to add clarity and consistency across different protocols, standards, and organisations.  Additionally, this document aims to reduce misunderstanding about use of the word "hybrid" as well as defining a shared language for different types of post-quantum traditional hybrid constructions.</t>
      <t>In this document, a "cryptographic algorithm" is defined, as in <xref target="NIST_SP_800-152"/>, to be a "well-defined computational procedure that takes variable inputs, often including a cryptographic key, and produces an output".  Examples include RSA, ECDH, ML-KEM (formerly known as Kyber) and ML-DSA (formerly known as Dilithium).   The expression "cryptographic scheme" is used to refer to a construction that uses a cryptographic algorithm or a group of cryptographic algorithms to achieve a particular cryptographic outcome, e.g., key agreement.  A cryptographic scheme may be made up of a number of functions. For example, a Key Encapsulation Mechanism (KEM) is a cryptographic scheme consisting of three functions: Key Generation, Encapsulation, and Decapsulation.  A cryptographic protocol incorporates one or more cryptographic schemes.  For example, TLS <xref target="RFC8446"/> is a cryptographic protocol that includes schemes for key agreement, record layer encryption, and server authentication.</t>
    </section>
    <section anchor="primitives">
      <name>Primitives</name>
      <t>This section introduces terminology related to cryptographic algorithms and to hybrid constructions for cryptographic schemes.</t>
      <dl>
        <dt><strong>Traditional Cryptographic Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms,  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 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 believed to be secure against attacks using quantum computers as well as classical computers.
</t>
          <t>Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms.</t>
        </dd>
        <dt><strong>Component Algorithm</strong>:</dt>
        <dd>
          <t>Each cryptographic algorithm that forms part of a cryptographic scheme.</t>
        </dd>
        <dt><strong>Single-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme with one component algorithm.
</t>
          <t>A single-algorithm scheme could use either a traditional algorithm or a post-quantum algorithm.</t>
        </dd>
        <dt><strong>Multi-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme that incorporates more than one component algorithm, where the component algorithms have the same cryptographic purpose.
</t>
          <t>For example, a multi-algorithm scheme may include multiple signature algorithms or multiple Public Key Encryption (PKE) algorithms.  Component algorithms could be all traditional, all post-quantum, or a mixture of the two.</t>
        </dd>
        <dt><strong>Post-Quantum Traditional (PQ/T) Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Key Encapsulation Mechanism (KEM)</strong>:</dt>
        <dd>
          <t>A multi-algorithm KEM made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Public Key Encryption (PKE)</strong>:</dt>
        <dd>
          <t>A multi-algorithm PKE scheme made up of two or more component PKE algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Digital Signature</strong>:</dt>
        <dd>
          <t>A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures are all examples of PQ/T hybrid schemes.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Combiner</strong>:</dt>
        <dd>
          <t>A method that takes two or more component algorithms and combines them to form a PQ/T hybrid scheme.</t>
        </dd>
        <dt><strong>PQ/PQ Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where all components are post-quantum algorithms.
</t>
          <t>The definitions for types of PQ/T hybrid schemes can adapted to define types of PQ/PQ hybrid schemes, which are multi-algorithm schemes where all component algorithms are Post-Quantum algorithms.</t>
        </dd>
      </dl>
      <t>In cases where there is little chance of confusion between other types of hybrid cryptography e.g., as defined in <xref target="RFC4949"/>, and where the component algorithms of a multi-algorithm scheme could be either post-quantum or traditional, it may be appropriate to use the phrase "hybrid scheme" without PQ/T or PQ/PQ preceding it.</t>
      <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.
</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.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Composite Key Exchange</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates a PQ/T hybrid scheme to achieve key exchange, 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 exchange could include a single PQ/T hybrid KEM.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Composite Key Agreement</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates a PQ/T hybrid scheme to achieve key agreement, 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 agreement 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 Exchange</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve key exchange, 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>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Non-Composite Key Agreement</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve key agreement, 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 agreement 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 properties that may be desired from or achieved by a PQ/T hybrid scheme or PQ/T hybrid protocol.</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 desirable 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.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Forwards Compatibility</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties support the post-quantum component algorithm.</t>
        </dd>
        <dt><strong>Weak Non-Separability</strong>:</dt>
        <dd>
          <t>A property of a hybrid digital signature that guarantees that, given a hybrid signature value, an adversary cannot remove either component signature without leaving some evidence behind.
</t>
          <t>Weak non-separability does not necessarily prevent an attacker with a PQ/T hybrid signature value from creating a traditional-only or post-quantum-only signature that will be accepted by the verification function for one of the component algorithms. Rather it means that a verifier would be able to identify, under a stripping attack, that the remaining signature had been derived from a PQ/T hybrid signature.</t>
        </dd>
        <dt><strong>Strong Non-Separability</strong>:</dt>
        <dd>
          <t>A property of a hybrid digital signature that guarantees that, given a hybrid signature value, an attacker cannot create a single-algorithm signature that will be accepted by the verification function for one of the component algorithms.
</t>
          <t>A signature only achieves strong non-separability if the attacker cannot use the hybrid signature to create any single-algorithm signature that verifies, even if the signature is on a different message to the original hybrid digital signature.</t>
          <t>In the context of PQ/T hybrid signatures this means that an attacker cannot take a PQ/T hybrid digital signature and generate any post-quantum or traditional signature that will verify correctly.</t>
        </dd>
        <dt><strong>Simultaneous Verification</strong>:</dt>
        <dd>
          <t>A property of a hybrid digital signature where the verifier cannot return a positive result and finish the verification process before all component signatures are verified.  Moreover, this property is within the algorithm rather than being policy or protocol based.
</t>
          <t>In the context of PQ/T hybrid signatures this means that both the post-quantum and traditional component signatures need to be verified before the verifier returns a result.</t>
        </dd>
      </dl>
      <t>Weak non-separability, strong non-separability and simultaneous verification are related concepts, with strong non-separability being a stronger property than weak non-separability and simultaneous verification being a stronger property still.  These concepts are introduced, explored in more detail and examples provided in <xref target="BINDELHALE"/>.</t>
    </section>
    <section anchor="certificates">
      <name>Certificates</name>
      <t>This section introduces terminology related to the use of certificates in hybrid schemes.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Certificate</strong>:</dt>
        <dd>
          <t>A digital certificate that contains public keys for two or more component algorithms where at least one is a traditional algorithm and at least one is a post-quantum algorithm.
</t>
          <t>A PQ/T hybrid certificate could be used to facilitate a PQ/T hybrid authentication protocol.  However, a PQ/T hybrid authentication protocol does not need to use a PQ/T hybrid certificate; separate certificates could be used for individual component algorithms.</t>
          <t>The component public keys in a PQ/T hybrid certificate could be included as a composite public key or as individual component public keys.</t>
          <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="algorithm-specification">
      <name>Algorithm Specification</name>
      <t>This section introduces terminology for specifying the component algorithms used in PQ/T hybrid schemes or PQ/T hybrid protocols.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Scheme Identifier</strong>:</dt>
        <dd>
          <t>A single code point that specifies all component algorithms used in a PQ/T hybrid scheme.</t>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document defines security-relevant terminology to be used in documents specifying PQ/T hybrid protocols and schemes.  However, the document itself does not have a security impact on Internet protocols.  The security considerations for each PQ/T hybrid protocol are specific to that protocol and should be discussed in the relevant specification documents.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="BINDEL" target="https://doi.org/10.1007/978-3-030-25510-7_12">
        <front>
          <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="J." surname="Brendel" fullname="Jacqueline Brendel">
            <organization/>
          </author>
          <author initials="M." surname="Fischlin" fullname="Marc Fischlin">
            <organization/>
          </author>
          <author initials="B." surname="Goncalves" fullname="Brian Goncalves">
            <organization/>
          </author>
          <author initials="D." surname="Stebila" fullname="Douglas Stebila">
            <organization/>
          </author>
          <date year="2019" month="July"/>
        </front>
        <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
        <refcontent>Post-Quantum Cryptography pp.206-226</refcontent>
      </reference>
      <reference anchor="BINDELHALE" target="https://eprint.iacr.org/2023/423.pdf">
        <front>
          <title>A Note on Hybrid Signature Schemes</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="B." surname="Hale" fullname="Britta Hale">
            <organization/>
          </author>
          <date year="2023" month="July" day="23"/>
        </front>
        <refcontent>Cryptology ePrint Archive, Paper 2023/423</refcontent>
      </reference>
      <reference anchor="ETSI_TS103774" target="https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf">
        <front>
          <title>CYBER; Quantum-safe Hybrid Key Exchanges</title>
          <author>
            <organization>ETSI TS 103 744 V1.1.1</organization>
          </author>
          <date year="2020" month="December"/>
        </front>
      </reference>
      <reference anchor="ITU-T-X509-2019" target="https://www.itu.int/rec/T-REC-X.509-201910-I">
        <front>
          <title>ITU-T X.509 The Directory - Public-key and attribute certificate frameworks</title>
          <author>
            <organization>ITU-T</organization>
          </author>
          <date year="2019" month="January"/>
        </front>
      </reference>
      <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs">
        <front>
          <title>Post-Quantum Cryptography FAQs</title>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2022" month="July" day="05"/>
        </front>
      </reference>
      <reference anchor="NIST_SP_800-152" target="https://doi.org/10.6028/NIST.SP.800-152">
        <front>
          <title>NIST SP 800-152 A Profile for U. S. Federal Cryptographic Key Management Systems</title>
          <author initials="E. B." surname="Barker" fullname="Elaine B. Barker">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="M." surname="Smid" fullname="Miles Smid">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="D." surname="Branstad" fullname="Dannis Branstad">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2015" month="October"/>
        </front>
      </reference>
      <reference anchor="I-D.ietf-lamps-dilithium-certificates">
        <front>
          <title>Internet X.509 Public Key Infrastructure: Algorithm Identifiers for Dilithium</title>
          <author fullname="Jake Massimo" initials="J." surname="Massimo">
            <organization>AWS</organization>
          </author>
          <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
            <organization>AWS</organization>
          </author>
          <author fullname="Sean Turner" initials="S." surname="Turner">
            <organization>sn3rd</organization>
          </author>
          <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
            <organization>Cloudflare</organization>
          </author>
          <date day="7" month="August" year="2023"/>
          <abstract>
            <t>   Digital signatures are used within X.509 certificates, Certificate
   Revocation Lists (CRLs), and to sign messages.  This document
   describes the conventions for using Dilithium quantum-resistant
   signatures in Internet X.509 certificates and certificate revocation
   lists.  The conventions for the associated post-quantum signatures,
   subject public keys, and private key are also described.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-certificates-02"/>
      </reference>
      <reference anchor="I-D.ietf-lamps-cert-binding-for-multi-auth">
        <front>
          <title>Related Certificates for Use in Multiple Authentications within a Protocol</title>
          <author fullname="Alison Becker" initials="A." surname="Becker">
            <organization>National Security Agency</organization>
          </author>
          <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
            <organization>National Security Agency</organization>
          </author>
          <author fullname="Michael J. Jenkins" initials="M. J." surname="Jenkins">
            <organization>National Security Agency</organization>
          </author>
          <date day="29" month="November" 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-03"/>
      </reference>
      <reference anchor="I-D.ietf-tls-hybrid-design">
        <front>
          <title>Hybrid key exchange in TLS 1.3</title>
          <author fullname="Douglas Stebila" initials="D." surname="Stebila">
            <organization>University of Waterloo</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization>Cisco Systems</organization>
          </author>
          <author fullname="Shay Gueron" initials="S." surname="Gueron">
            <organization>University of Haifa</organization>
          </author>
          <date day="7" month="September" year="2023"/>
          <abstract>
            <t>   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

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

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-09"/>
      </reference>
      <reference anchor="I-D.ietf-lamps-pq-composite-kem">
        <front>
          <title>Composite KEM For Use In Internet PKI</title>
          <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="John Gray" initials="J." surname="Gray">
            <organization>Entrust Limited</organization>
          </author>
          <date day="23" month="October" year="2023"/>
          <abstract>
            <t>   This document defines Post-Quantum / Traditional composite Key
   Encapsulation Mechanism (KEM) algorithms suitable for use within
   X.509 and 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 [RFC5990] 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-02"/>
      </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="6" month="November" year="2023"/>
          <abstract>
            <t>   This document describes classification of design goals and security
   considerations for hybrid digital signature schemes, including proof
   composability, non-separability of the ingredient 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-01"/>
      </reference>
      <reference anchor="RFC4949">
        <front>
          <title>Internet Security Glossary, Version 2</title>
          <author fullname="R. Shirey" initials="R." surname="Shirey"/>
          <date month="August" year="2007"/>
          <abstract>
            <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="FYI" value="36"/>
        <seriesInfo name="RFC" value="4949"/>
        <seriesInfo name="DOI" value="10.17487/RFC4949"/>
      </reference>
      <reference anchor="RFC5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author fullname="D. Cooper" initials="D." surname="Cooper"/>
          <author fullname="S. Santesson" initials="S." surname="Santesson"/>
          <author fullname="S. Farrell" initials="S." surname="Farrell"/>
          <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
          <author fullname="R. Housley" initials="R." surname="Housley"/>
          <author fullname="W. Polk" initials="W." surname="Polk"/>
          <date month="May" year="2008"/>
          <abstract>
            <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5280"/>
        <seriesInfo name="DOI" value="10.17487/RFC5280"/>
      </reference>
      <reference anchor="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
          <date month="August" year="2018"/>
          <abstract>
            <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="RFC9370">
        <front>
          <title>Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
          <author fullname="CJ. Tjhai" initials="CJ." surname="Tjhai"/>
          <author fullname="M. Tomlinson" initials="M." surname="Tomlinson"/>
          <author fullname="G. Bartlett" initials="G." surname="Bartlett"/>
          <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
          <author fullname="D. Van Geest" initials="D." surname="Van Geest"/>
          <author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon"/>
          <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
          <date month="May" year="2023"/>
          <abstract>
            <t>This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.</t>
            <t>This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.</t>
            <t>This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9370"/>
        <seriesInfo name="DOI" value="10.17487/RFC9370"/>
      </reference>
    </references>
    <?line 369?>

<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, Paul Hoffman and Sofía Celi for their contributions.</t>
      <t>This document is inspired by many others from the IETF and elsewhere. In particular, many of the definitions in the Properties section are drawn from <xref target="BINDELHALE"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+09bXMbN3rfPeP/gNF9ODtDUrJsx7EynakiyYni2CdbyuX6
yQMuQRLVcpde7Epmb/yT+iv6x/q8AFhgF0tKjtPrXNvr3MnkLvC8vwMcj8cP
H9S6ztWR2LtS1UoXZV4uNmJeVuKiNPX4XSOLulmJq0rOdK3LQubip8200jNx
mS3VSpm9hw/kdFqpG1ji4t3+lfs6WA4eyWStFmW1ORK6mJcPHzx8MCuzQq5g
41kl5/VYq3o+Xn9s9Br+ux4vaZFx3S4yPjh8+MA005U2BuCoN2t49/zs6tXD
B0WzmqrqCNaEXeB/srIwqjCNORJ11aiHDwC2pwBmpeSRuDw7efjgtqyuF1XZ
rI/Exbtfzy8ePrhWG/hwBksWsGmh6vEpwgXvqqLBRYWIXxCCQfgNltLFQvyI
3+LHK6nzI7Gs67U52t/Hf8kqW+obNUEcJ2W12McP9qdVeWvU/vpjto+v4Wf3
fg3/I5t6WSL2YozrCDFv8pxJ+yovK1VkSpxW2mRlnvMDsJYs9H9I5OeR+PW1
eCsta082QEhxqbKm0vVGnKiirhS/pBivuV1yMvvXIjPZZFHeTJprhAMZW61g
pRsm1w/nb0/Pfjnit2tZLVTd4jcrNaH05GDy5ODgxf7LF9+Nn44Pnh6MD58/
f3IwfvHhyaF9k8XTStVrtRFnRSbXpskJaPFGZUvAxqyMkMVMHAM1AGqNAmcf
/4QPLCwaLbXo/8buDwGCCfLydiJ+0MVM5e3nTMq3upCdr7rv/gzvAm0SL/8s
s4+NynWhuk9013gzEa+AVUt4trvIG2B/78vu+z9MxI8l0Ce/Uaa7wA+VlkX/
6+4SpxNxWaspyF93gdOyWeTSxF9Xag76VgPNj2KTcVJt1nW5qOR6uRHr9eTw
4Nvx4eG3/JZRlVYGRcaz4vQv50ditzyQjovDgycvxwcvUO6cpP10/MvZgLSp
daWLeqJlVpHUHR4cPt1/dvh0sp7NIyk7Fm/LWgkQK2fk9KKQdVMpZ+4SUuQJ
mJagAfmJ3wK+/SRzFb8DDKtrGXwR0prJS9ZaXSB64pjtxUhcyDVosUMyJtsh
UPXFGD/Fz8+uLs8/XF0+OXj64sWzAeLd3t5OVG1YXwF82KLaxw8+1GYf3zw4
+ID/8/Il/evZs/2DJxP6/w/fHuzX5gN/enPwBP+z7tH85N9+OHv/vbBiMzZy
riJtt+qbojxQEY3ZEeEhri5BfJ4K2Ev89ckE/tPB/GDMMnR+9ev4avy35wcv
xyhGW9DWdTMByu5XKtu/Gr8/Oxn/beJeA6E8j/CgZQU9IK6WYHM1vFaDzwMg
L5pprrMxOBkyUrKuKz1tQNIyVdV6TtZKzCvgOnqmrajSNn1VIGTfnl9efbh4
d/Lh1fG7AbQyU2UTMJc1Wu79i6r8dwDS7K9Rcz9aFmSB5u7P5UcT4Tms5LDr
VtC9mzkvDCyG+JdzsCZAElnN2H5fgTm3QcgjROdxh4mHKL4Hzx224vJCfHcA
nH1+uNvTfHtw+N0+vjW5vJjYtyLUOiuCOQACzXWuKCD6FQwjmGc1UxW6yhZz
nZGkvpGFXICNAFW83JharQaI0TWrZ7kkzwCGQ1bXqmq/Z4Y7vwpWKaDOL3Ja
VhLla3DhNwA5WOuVnn21JU9lAcIDlkkCC+XXWPdrScaT5+MnB2zVzsenFDSN
c7lam/FM57peahTsVtvMUeJJ/H48BSMNAd0YUBmvmrzWY2Rg/HidGxeizsCN
LYrUauuP46xcgWbpWoHqr/wzSzDoNta1ixjnZsZmDfpYNSuG7/2rk2cvn710
fz8//O7A/f3ds2ffur9fghE+4mhwPB4LOTV1JbNa8Ed/AeGStC4SFcIjiIqB
fRTOi7oUoe4LmUOYDuSCcEoXIouEfF2VdQlhJHxlaJ2ZulF5uSaRh6UZGWHY
U8ITsoZFsrJaI/uVmJb1srMb8LUOUgtpNquVAuOYBYBMBNhT2BEyhoa2mqk5
KAxs0MlYTJMt3e7w0nmNcGr0lzOIBQHTqRKNgT8hhpHoTBVHxwDFSCzLtcLI
eTPCJzF9AKePmQTYSniKDXcGQTkGxhBIlAYg0nNao25JMxLGSe2IXuFg25CA
m4ljEejkDL36wwd/woyjKmdNhk88fICuA1QIkJAYxea49DQHY4IURmQW4Nvn
Ej2LXZW2mUFgWCkgMlBDWgaWN/ioLjQ6F61yUCSgkspzvYalBQT5EAaKBqhT
rYHZK+CMk5AkI5h4SGl0ZAoQBa9mlsQThmGha4DYS7PBSAqX0zapIlYqozxS
TKMlsYH2bTebStyNF1iNxK3Oc2TgTZMXYIDhbeQTeFKZXSNkmINdgp39sxHH
bhF8W4JYzEHnNUCZb0SO7kEsFK6Rj9cNyCaA4+QR9RWMTzUS10V5W7CgRJZe
goSI9ypXN/CG8G7Qvicenbx/d/LYCx8KiM7AiJCeVWqmQQlvAd0RckLPRyyz
EjVJAwkISfUJ3bMQP5W3oF8Ai6a1CpUpYyTEE4g3pjh6jVqFBISl15De4jeg
HApDjAU4FeBnu77TVFj5VEJYCTRHxEgzZhKMKnjXZ48BBFBSyBM8J7oU7xEL
/mjyGfLGgFBaCZkpWh3Fcwr6AkkpRdHML3iHtxFILgAIw2xkYGx91qwW1pIg
fuoTmjGvzPAMiCTtt5LFRmyUrAw9KHODwiFAR66BznYnYglTAtaYQZILe6LY
wb8r54JyPVe1XilWBVk7MEh3L4jQ+Bpuiq+uS4zHNbzYsYZ2y0qBoUdVWJUg
DRt81WsOAPHImQsN0v44MLGAIeKWVkRPEIA7UxCRO4oYTN2V536XVQYl+hYs
AP4vsR3UBYyaMWRq/GNeT4M9cTsUf9grtOGgmUuMkFKamzRXI2uSxmSS0oar
tVJjslLJpwKAQh8S+6zQjZyjLQkdyV7ke9yTeygmJEBk74Cw5CrwD3qd6EUc
btdG2Tht5SlwsPOqXEXwDXvcEb5bofnfIC9Raw2IDpJDOjkiuFH2AklBYUBZ
If/a6i3Wp5CTx4JjFFXRytmyRJMHYAC7pxh5ygGAnJImqUS2YDYjOFTGfshK
HVqPhJ4zAa2MoheFV9cYkYFywJ83Gr00GAtLwP6WLJUbwoL406KiV+ucaTOI
jMzLYmFgk0GMkKwKZBd5u9ILtgjMQEBJZaWhsB4NOHKlAE+QXIhF04OEAQdY
ZBQmii3KQjHPaAX42AwJxASyX4nLkLiZMm8oiuC32ep6vhO3I6nE2CtvZmok
INUkkIqyBvO20mxBR+Lvf7fB4+fP+I/h8LbzfTq+xYcQ0d6DW8Lqz59BdS7D
gNEJ5fY4sSV1OhxBD9SPRpAG5RzstbMbjCTQ+RWynmlNgfQ3nAu6SNNGtv19
2OpKscdhp415MWpgPFiE0JPclgjUqqSoEqhWwOuBIccgxyisy3UMGOw5jve0
Ee4eEDpM+D9//h7hplJICm5XR7Ew72FsC5lGFomUMwghscO3xWQycTodcaj3
ENh+DBYwLgPvEH6NgEeFJxICjnyxBi/2GOyOHY7TkQ3HOuAVNCBjYxmktUkJ
U+hFQZSSPpWUAbMtlGPaFK05xl6FdfQBulSG+1RTiJ2XEiJrzTEwBhzg67Wh
sJqcOyxjwnCOnEiYu2j2yeMwLpArtFZ1YueQBo+A948Ry1UDLnUzQfsIzgqE
bGStsFqtSUpXAKmQt2A5yZ7p2vjQCdawxiRXkvwd6SeoAsuRZglxAY+RK0qM
MrWuR+CWDD6MlCrw03ljXEqSgwdA0bdJk+Vx6H+t1TfwaLFo5ILh2SKYkQ0o
ZsN2E0JKiBQx1w/MJtn3AkkM4DbWzjtU04FWLwd24mV9NOmzzSYQVI4wgPh5
Xt66aMBuBYCojsvApJU/HcbEyw27ncrmHvBvJFfWUJIVvR5FQ60ZouCv5rCO
LQ6AX+sb6+Yse2+BIRXq4bUTfGyy9XLwMLPupNOhaC8adLi4domxjX/fuPDB
Z9SYXYfZ9pdm2BDvzBz2lMxHYEu9MhzRQUivenoq5LRsasewumeQguiZVQNf
EWYpMe2JhLgF3DvmQR5ZKx3JPWlLN2AdoacZiG/3OLlBuw9hhiTRZQcRVDTR
tHmXRTbHvmFDf5cDAbEzoFBlHVotrwGFG+AUZYG6gEeB+OxKOcpgSvRc18im
p5hBoQMGX9jU8PYe8MnHNjZOEe8vj0fi7OT0p5F488v49dkb8QjriWBhN20+
/hpblI9pWXjo9PI49dCpK/lhKk7VeMgcwVSRbdpLaTSRrxfvy4gpPtI2PVTb
oIuCdWoVk+0bSEZo8Wyp1Q2F3xKi4KwBVei8AMQCxoAxV5PFZEReVC4qpWwe
f5w0Tt42SaApgyEF98jx73lTWBELox4UrS3NVfEI2PHYRjapPa3uohiQ5gCQ
7U5HtPSPZCY5BYy2YSE5VcFHCeScAQhLioaCaR9XpSw1rBShefXLJbt6LKB+
/pxCye/kKpgoncabfhdxek6gF8zQTuRyo6ogGGHEjKqwECfbzjQiyLW/iwrD
cU3tWDKwxuZS2hYFO2VOsP7S1j8GRYuC5TJpVdi/JslEUe834ZxH3OHwRbVv
voEI+UgcF6HLHNKGu5UCxGApYCQ69cr0Q4CVo0yydjrhxsDx1qdQFHxuloGp
wnpKmd9wVop/OYf+Zcj0i6+phywwFuLfyOdzWQDAA6tWgwGmqhZaFx9v3aUA
QjhRPD1VbOIqliQMC4aTK5ztodgyGgIaWNbmVW1JieO5GxT8zntW4qJ24pcJ
mUu6pipHgzpQC4tLxVsrY6mKGPPjYqBXkqCB66aC29EYX1BS+jHscvdoceIS
wx4hzsBZbMcfnaAhT8IGP6XldptLysnGbZmcE3BH87SBp6QP1cNnr0FhxqkX
Z3vjFjTvHVytQmmKA4dKMOQ907GwBf4N1Q7uB3u3E2XYX1C8PoCSC7dR3RNf
Q2otb1SQD8UOhNsKliwdL2uLH10SodN2gZBPSnztItwZ3Z17gAcLnOd2OfCj
i9dnj+Ms4iSFgy/cg8SGDKH8pVPlJc6s9CeCxvURb8uUFod24hHOBD6OZwY9
swZIwZQHlkE+ii2pNIfYcw8V+2jKIliAHk5XFS0GwezizkBoEAMMWoO4K1n1
oYcCLiTQ/eNQ2yIwg0jBl62U7sANn/1H4XZqK35+aGsQo15t8M749d/8n8MW
3A9iawM7kCKIfMJPgPYccYYfDpRBJTUa2+Jy+EocEoYUPuE6TNUSVtXLchZm
iWmydcJTW8+hcgR1EtB7Ae59KFogLt59kRXJ87DeSj2zgVILk/hqmSh7uRQ+
QSV2/TNpO6k2BY9eAcjjd6hnhn3ZSg1Ab1LgdzsMkdHtIHKONW7j1+lGkGjN
MhXHkFNV3ypI6LlS4xFweURYd+R0VPqCAxcbgvopMnmHA6UoZYB33jHZcCFi
GTIk9FW69h2zNbaUKo1tcds/pfrpssKuzl7EhD2KaLDaQ0ylOihyag25nJpx
6bcXlkWSl4jJwnhjReoAtiQl1nY//6lLOa0Qnqq14oKUHaCIyhBEubuv6QhU
cv8Pm0BYHVASy1fzJg+lNmKWE8WwZzzAzU4tYU6VFNtd6QvKPcagBEoTgh1N
ccB/S+orDEoXW6Q0OrYT5iqpNhWP090z7t393rRc2WU4KV8qXXGQZ3ixtMVN
QuIzog2OvEnST/EIhP0GpR0bwuTZH7uCOVBIF1Rxo3IdPsGlN3Ej84aLlFur
WPyAq+GgOFPZfD38lrOgznIMkMJFuQwwllJARBwi9l84EokNFvg702swAfYf
ttQK7IC02dZ/W1dMmPWTqa30TENpc6hU1FkMmq1UvE/yvr2xSlKao2T/2RD+
S8mjZ8xBdKgtIBHRMGaYb0mZuDzuH9oWR524Tu4XUSuRYLkMpQV9QBxsLkFp
FAn1PSls2USwd9MwRyv0fJ3QLknSbQr45cHPXRHfFhkN4WhX8xl4mj921WBU
Cxt4wKjClq54TMxHC0P0EVYy7ats8XoQBnR3fYjtGkBtMKQmWhgini5uuPLm
AKNx00bmF+9fxb6ED3/YFjIWVG2b6N6GO+jU3XX2AAitKD7hYTXeOJV02e+8
5MQVZuoo7IybuVnqSpCJqoMz1RJivM3oj09GOlqYDD1aoDHO1DMelcOGX1sS
kt20xjP9bqKj3SyM7xLjRB/7OjLjEcaUfCOuEW70qe22O9hznOdDyeD+Lo5a
unGGyA2NYnj9SA3NNa7wHB/2IXcSKO4PDNJnKHWNSeF87O6R617JbmiDtoge
Sy/mP4ValDWH3a0WfXmpjyeWMEaDZQamm0Y0E1vWA4TdooVcymwdXnjKyGto
kll9N5eMw4PeXjj3QsGAncfFQQwfovr17ZA2smiFs77YS87LW9+uJ6UnY4hj
b+Qnb1Rl3IhRuFTYqhyoyt5DjYlirYGPhn1igfMq0tHpe/Lj2PXW/giGBI27
fyaOeLTuyJKO3dpyukVY93o3/h1HhuxrMzA2k/88HEya/60s7BnqUbDmtsBz
qnhei9aeMc7hwsExKVdL2oZDFJwGdYqRcBOHVHWr9EpWOt9wIG4DLj4v5mPh
NMBuxPxOfK3woHrB5zxwvLZgIGZ4JqNoh3J5WmjEh15COHN9TVNapR+hsKDG
sOV6Wkk8w2yJDhEl4JeLYMgyDibc8zsV6W1ZjL+OcwraSElhNcOeKhE8WsG/
a/hoH0/6/kGt7YrDLknuKjEercEPNvQNn/UKeqLblPZ+LPli/3RvngTO6v8e
U+5hSQvg0V394eB0s3U3nB9004YJptdhHRZNBQ/oYX3l/PXZzSEGpTRiykMj
4FVtOnAXFxqL2e9zo/eSs65P/X9Bu7Og7craYHscB8nFxevzdoYiGtcJrgAA
MdSFr9rFc9/dxybiTr45Bve+/rnjbrlYGfpbSjsxRXNOOnCAW9hG7hKPvP1u
t9z3sNs98oAb50CHxoiAVEZPc1c1TSscwWHPVc14Q0pUA8kALg4TvzeXKDva
XOL8sHGLxrUTUreU4NFQypAV7APUGUmM6hX6PrRwhgSFVPZm5u0Uq+FIE0Gw
S6xkUagqpsTOTMSf+ujmCnfKjbi0QE/07MHAhKY7pNapKLZgBOfYbOdv46SD
jsPigQskHxNpxgdi79kTZNHEekfEEjQT9+gEhjY/z4MEx8Gv7cS5RXIirkrR
TsiDivN5WPc4aiahSXPhsj1oiLUof/6t4nPNWN69thP2t8tNaKl5ejzR/e/q
SOeYlVfAebgha4Q/ZkibW/thT1HG6U5HuzrE6ztHOu7qQKGdEUk6QzzVud8y
tVf3yeSMRQSOdfxXLZ82vsUXgY312i+UMHSeeDqSTnLsGrviI2v2HIU9wcNC
4+HjHMzYCcwEjsnYpo9ix8bdEcMBq/DH43g1cLh1S7/eQzejjr9r9/tV8M6H
2iQbArZxuCw1D3LEIs39npHrO4tMrp1wIjjtCd2JOIkdZLh3ugWKFV9QNrxh
ZOg87xDKbbl7WPmSetd1l3qeOpTXh3UIEBwXrsprvImBcHBDrqS3VEHojg/3
DzX3x4Sdd0leVZE+Fc3XCiQE1gRxwJ3DgFlJPsLdFYHhXLDAAM3pCo67EH17
M6Y9zjewD9JmVipbtp/N8EDO4MbBSUbLaxsB7GwK+ZM8aS/PN3SFVwGlBpnw
qh1Yio5od2hsmWcrcvE8qjVPCZN33rH8YPTEgNW7j+W25xRQAHNVc8MUeU9X
2bTH6mlhbgZJ1lCeMjDNGjJGvlFgl1XcnSj1W0crvVjWPuYYcIKOwe1rFqsb
VQGP2NrbbhJ9tAnuWQjPUg5bhFHUSKY5MZzeCrjuwroXk8PJIZoNELL4ojjq
6LkjeS5alQ7Iimm8lMbeHcBdZUfgwUuWjIsT6HFGz94t0MUmLPTaIKS/OeqW
B4AsUXfNuPtnl/TZJDsL7uB1cxLnER0/+cKJWDvsQc5Q8UdbQ6D2hhTeY0AK
O7sMlx5SXsAeK+7GS5Y5LGChdmwLuXc1KGidrQh3R3S7kLnBROkPssa9fUFG
Iu5TW1O9fV8HbaHUjBhJx3yxbIInjLcN2g9SytfmWwJsQ21wnhVBCq7oCs89
83ZtbGGNgw8Fe/0LTxmEtdH5zB5Pn5W3BSjGTIWXlqhPeDUV38vSrw8MHCK8
11SXne+Af+PZw5aSdEjUEACFsXexydkNYmk6ljklci6ys8cLkSpG5YqCMuAY
H0HVGD+6tUwQ6rgD3RzS1nyrEidiAOWfDd9Chf9MUY0uSLAMMNsYzgGRnWAt
LMkJ1NoGSVTL0X5aICAbTgUxbj5ocETBp/okIai2akDXRV+56iHeyFA17j6E
e+huL25JWI2ucbABRIqnkKHY+1o69ZfEO7FtRtsfzj+n2JYIS36AgPSW7ljE
yjMg4aOTf2hwEvC5c5tBMiqJcQJV/d+N0q6sxeL0m5LX1BS4xEvHZITGcYsE
OerBCIwgWTTwPoiydbIjsdA3qmhf64zQ8uUhaIrovjnAmeel6RIRq6jBXLV/
2TkucMZ0VhaH+oRCiuBhg6la6gL1Tgg62orYYTHQBNi1qh6mMOtK3XAFs5dC
RayLseDCW1YpWXN9KZCkMUVDZXyygD/skM4lczLDC0/aG6o48rLhiJ+SdjW5
XgsjHJV/L3losKYhfBf3tLHcrT+WZ60HG9Q5WFOqxaEjryu9XhNaRJBR20Xh
9JXI7zFZSlxPYdGyotvi+FKrNPXcKdG6wnLJP07+HKet+BEj21GIsI/zR3Os
Pd7qNuK80DlAw6TqCbPNa7qYuHMpPeSpZ8JYFpudeFp5gRAMtaOfRNFxdizK
+qtIXOPGhjqw7EIHF5D0mGcRP/dnUPjOo3labgwHHqFM97mIc9I7s0Z0su3Q
ZbHZdv4nyX2b8mRlhXdw567MeqmxLSoLVTZG/DUQh/sKdXu0ySutN5LwQMGd
UrrYwd6QRDjhqTKz7AsjXbdicDAHCx6dILlzcM/lxBBqvIGHy/ZKKQ873iel
sdrO0uflp5I2xCIfhhZiXeY620SFSLqx4fcynmc2u56uO3qaxDFIBNr0n+kS
0ZsJzTcPIYEJ5KRPGQ3qJ58eCWQi4ork25Yokbb3Xbne4tCCTFVpv1dVFGkU
4jbp8rZDMbwkhdD+pk4HId896KbdZyO8+Sana1npil9q2NRS8/1Z/gSoD1yC
mXr8QQWaWsBrtumEVFAz+z3j9VHtbegQVNQSaV/wmuqUMuyLx0efwnMLdIpz
14T90MR8en45PTC/5e4C0ZneiDr6zuW7K4jmMkPpYI83nHC0TcIgYb7TC2Gk
xVv2Z80DCL8XLLPxbxaYDuDcDJtpkKUmHa6Hx2zTR0y2jSO22/npRWmGzp5g
4mzS4HSP/DA8jat6De2eDE47xc0OuW1YwREc+xVO2jGQ+54NJzUyWW04Wokb
KdzmwZYE/qNq8HLouAhbCFhubHcYVog0nWzPgg4ko0ZzQ9X1ZO98PKAvwq5v
tpUwpmyqzJLdhicWIFqOOgVfTuDU7RRfZkx8vT8QsMTRuy3XA6RuWPrKoISG
ahck92qDdM9jd+ruQ4NKxrY1g4PM0UFK/OCymeJPkIQXU+DPSPTHY2IzQLRg
EbXXwIUSjcNgNguIDx7f6ach6Mxxm4QNordDurCxqtvQsj/nFRzxD75rxxS3
i1rHE1Wqq7o7BDOafR2Qyi9DwWzDYYsz7aOwXaAHp3e/AgayOyQSfYmhE53+
D/nmbSeFiLujDSpghAGEC/XuGG+4x7eEHFsCDkLe3niGU5hogcnQBs353aZW
WkPLXtvFFraCyb6SMk1Ml2GXCd3olVPFnZIjbTqRRzQvGRikqcrL25DVb/Qn
dT9Oh0bD0ZG4ZC8zojsLI7NLh84CA8KXceLvAvK9RinhGG2xhr0EKPjyMcch
XasXPj7g5NufX2Dxo9GYCAiqYq/UTHfCN3cPCaKGWevulaoSKzGBCeQuQjjx
RkWrWeOrDO73FNpYJqIWl6xyFgf/exkkXCBNXLqzp935TgJl74HIML2QhkYp
t07e9CWBp/RAgLo3rw8f9bXhSJucSnhgYy83lNQxHU83Y+qcQgqtozTmIhBq
V4bGI9ZdwOyR/mGP0xkQltsHiW1R0A9Dh8eVW2W1AbBLTiIF5Pa9/9mc7YGY
n9zpNU16UUB7NUk0sxdd8RaqdnoWPt4/fZQ6rTMu6o+1je8cCMnYQdFdM+M6
j9HgYkg4Ozsa3FJnb6Omde6WO9MvGtFrftwh6Ufc5eipu4kGuhipHJuvthHn
XGrW/poDf6sf7I7NpBJ/apBozcDRGOhQV9fBNniz05+CHxvFG2Rn9oZY070q
3N1o77R87G5viWgW/MYT9XvdZdMBHdOjVlSD8b3e4Kp2FVx5XRuVz9skkIat
ZWt37EgccNT9hmxAcBHbqCxC1v7yRLZM95woMHLXmZNVlXXwLYK+dJYbbxRt
jHH+qr0v3K/gBsUsbSwbzo/fHu9gAU+X8JMyuKUaf89qKrNrK/MZ3sKcq9nC
3p/z9yO+e1jN/mVvLnOj9j53V7Y/J2Z/aAetNrwCJqQBylSNrvGSIosYkSu4
mJx/jpe73URkWVyLTdnQlQzttcpAtTd4WucvTWFuywqPK/xcLgvxYyUhXbjS
K+A5KO9UqeuR+E3i7/k2YLvAhP5Q+R/hxF/WBEh+KufzlWQrfFnO/+s/JYQh
uXY3qGsaNeEfePQ0SlyebtY09DPd8G8X0a1bxv5cjEOOAk0gGQWp9AM2LU4j
+54bjmuvLLPkaSfXvamhee1K3tpfNelU+h78NyFcErUQegAA

-->

</rfc>
