<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-pquip-pqt-hybrid-terminology-06" number="9794" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" prepTime="2025-06-13T16:48:14" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology-06" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9794" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="PQ/T Hybrid Terminology">Terminology for Post-Quantum Traditional Hybrid Schemes</title>
    <seriesInfo name="RFC" value="9794" stream="IETF"/>
    <author fullname="Florence Driscoll" initials="F." surname="Driscoll">
      <organization showOnFrontPage="true">UK National Cyber Security Centre</organization>
      <address>
        <email>florence.d@ncsc.gov.uk</email>
      </address>
    </author>
    <author fullname="Michael Parsons" initials="M." surname="Parsons">
      <organization showOnFrontPage="true">UK National Cyber Security Centre</organization>
      <address>
        <email>michael.p1@ncsc.gov.uk</email>
      </address>
    </author>
    <author fullname="Britta Hale" initials="B." surname="Hale">
      <organization showOnFrontPage="true">Naval Postgraduate School</organization>
      <address>
        <email>britta.hale@nps.edu</email>
      </address>
    </author>
    <date month="06" year="2025"/>
    <area>SEC</area>
    <workgroup>pquip</workgroup>
    <keyword>cryptography</keyword>
    <keyword>quantum-safe</keyword>
    <keyword>pqc</keyword>
    <keyword>composite</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9794" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-primitives">Primitives</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cryptographic-elements">Cryptographic Elements</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocols">Protocols</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-properties">Properties</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certificates">Certificates</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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).  Current predictions
      vary on 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 (in 2025) with an algorithm vulnerable to a quantum
      computer can 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 indent="0" pn="section-1-2">Ongoing responses to the potential development of a CRQC include
      modifying established (or standardised) protocols to use asymmetric
      algorithms that are designed 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 indent="0" pn="section-1-3">At the time of publication, the term "post-quantum" is generally used
      to describe cryptographic algorithms that are designed to be secure
      against an adversary with access to a CRQC. Post-quantum algorithms can
      also be referred to as "quantum-resistant" or "quantum-safe"
      algorithms. There are merits to the different terms. For example, some
      prefer to use the terms quantum-resistant or quantum-safe to explicitly
      indicate that these algorithms are designed to be secure against quantum
      computers. Others disagree and prefer to use the term post-quantum, in case
      of compromises against such algorithms that could make the terms
      quantum-resistant or quantum-safe misleading. Similarly, some prefer to
      refer specifically to Shor's Algorithm or to the mathematical problem
      that is being used to prevent attacks. Post-Quantum Cryptography (PQC) is
      commonly used amongst the cryptography community, and so it will be used
      throughout this document. Similarly, the term "traditional algorithm"
      will be used throughout the document as, at the time of publication, it
      is widely used in the community, though other terms, including
      classical, pre-quantum, or quantum-vulnerable, are preferred by some.</t>
      <t indent="0" pn="section-1-4">To mitigate risks, there may be a requirement for protocols that 
      use both algorithm types, either during the transition from traditional 
      to post-quantum algorithms or as a general solution.
      When the risk of deploying new algorithms is above the accepted
      threshold for their use case, a designer may combine a post-quantum
      algorithm with a traditional algorithm, with the goal of adding
      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" format="default" sectionFormat="of" derivedContent="RFC9370"/>, <xref target="I-D.ietf-tls-hybrid-design" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/>, <xref target="I-D.ietf-lamps-pq-composite-kem" format="default" sectionFormat="of" derivedContent="COMPOSITE-KEM"/>, and <xref target="RFC9763" format="default" sectionFormat="of" derivedContent="RFC9763"/>.</t>
      <t indent="0" pn="section-1-5">Schemes that combine post-quantum and traditional algorithms for key
      establishment or digital signatures are often called "hybrids". For
      example:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-6">
        <li pn="section-1-6.1">
          <t indent="0" pn="section-1-6.1.1">The National Institute of Standards and Technology (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" format="default" sectionFormat="of" derivedContent="NIST_PQC_FAQ"/>.</t>
        </li>
        <li pn="section-1-6.2">
          <t indent="0" pn="section-1-6.2.1">The European Telecommunications Standards Institute (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" format="default" sectionFormat="of" derivedContent="ETSI_TS103774"/>.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-7">The word "hybrid" is also used in cryptography to describe encryption
      schemes that combine asymmetric and symmetric algorithms <xref target="RFC9180" format="default" sectionFormat="of" derivedContent="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.  At the time of publication, hybrid is
      generally used for schemes that combine post-quantum and traditional
      algorithms; it will be so used throughout this document, though some
      have alternative preferences such as double-algorithm or
      multi-algorithm.</t>
      <t indent="0" pn="section-1-8">This document provides language for constructions that combine
      traditional and post-quantum algorithms. Specific solutions for enabling
      the 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, in order to add clarity and consistency
      across different protocols, standards, and organisations.  Additionally, this document aims to reduce 
   misunderstandings about the use of the word "hybrid" and to define a 
   shared language for different types of post-quantum and traditional 
   hybrid constructions.</t>
      <t indent="0" pn="section-1-9">In this document, a "cryptographic algorithm" is defined, as in <xref target="NIST_SP_800-152" format="default" sectionFormat="of" derivedContent="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, Elliptic Curve
      Diffie-Hellman (ECDH), Module-Lattice-Based Key-Encapsulation Mechanism
      (ML-KEM) (formerly known as Kyber), and Module-Lattice-Based Digital
      Signature Algorithm (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" format="default" sectionFormat="of" derivedContent="RFC8446"/> is a cryptographic protocol that includes schemes for
      key agreement, record layer encryption, and server authentication.</t>
    </section>
    <section anchor="primitives" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-primitives">Primitives</name>
      <t indent="0" pn="section-2-1">This section introduces terminology related to cryptographic
      algorithms and to hybrid constructions for cryptographic schemes.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-2-2">
        <dt pn="section-2-2.1">Traditional asymmetric cryptographic algorithm:</dt>
        <dd pn="section-2-2.2">
          <t indent="0" pn="section-2-2.2.1">An asymmetric cryptographic algorithm based on integer
          factorisation, finite field discrete logarithms, elliptic curve
          discrete logarithms, or related mathematical problems.</t>
          <t indent="0" pn="section-2-2.2.2">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 indent="0" pn="section-2-2.2.3">Where there is little risk of confusion, traditional asymmetric
          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 pn="section-2-2.3">Post-quantum asymmetric cryptographic algorithm:</dt>
        <dd pn="section-2-2.4">
          <t indent="0" pn="section-2-2.4.1">An asymmetric cryptographic algorithm that is intended to be
          secure against attacks using quantum computers as well as classical
          computers.</t>
          <t indent="0" pn="section-2-2.4.2">Where there is little risk of confusion, post-quantum asymmetric
          cryptographic algorithms can also be referred to as "post-quantum
          algorithms" for brevity. Post-quantum algorithms can also be called
          "quantum-resistant" or "quantum-safe" algorithms.</t>
          <t indent="0" pn="section-2-2.4.3">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 an 
          algorithm will not be compromised just because it is designed to provide 
          post-quantum cryptography. Should an attack be found
          against a post-quantum algorithm, it is commonly still referred to
          as a "post-quantum algorithm", as they were designed to protect against
          an adversary with access to a CRQC, and the labels are referring to
          the designed or desired properties.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-2-3">There may be asymmetric cryptographic constructions that are neither
      post-quantum nor asymmetric traditional algorithms according to the
      definitions above. These are out of scope of this document.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-2-4">
        <dt pn="section-2-4.1">Component asymmetric algorithm:</dt>
        <dd pn="section-2-4.2">
          <t indent="0" pn="section-2-4.2.1">Each cryptographic algorithm that forms part of a cryptographic
          scheme.</t>
          <t indent="0" pn="section-2-4.2.2">An asymmetric component algorithm operates on the input of the
          cryptographic operation and produces a cryptographic output that can
          be used by itself or jointly to complete the operation. Where there
          is little risk of confusion, component asymmetric algorithms can
          also be referred to as "component algorithms" for brevity, as is done
          in the following definitions.</t>
        </dd>
        <dt pn="section-2-4.3">Single-algorithm scheme:</dt>
        <dd pn="section-2-4.4">
          <t indent="0" pn="section-2-4.4.1">A cryptographic scheme with one component algorithm.</t>
          <t indent="0" pn="section-2-4.4.2">A single-algorithm scheme could use either a traditional
          algorithm or a post-quantum algorithm.</t>
        </dd>
        <dt pn="section-2-4.5">Multi-algorithm scheme:</dt>
        <dd pn="section-2-4.6">
          <t indent="0" pn="section-2-4.6.1">A cryptographic scheme that incorporates more than one component
          algorithm, where the component algorithms have the same
          cryptographic purpose as each other and as the multi-algorithm
          scheme.</t>
          <t indent="0" pn="section-2-4.6.2">For example, a multi-algorithm signature scheme may include
          multiple signature algorithms, or a multi-algorithm Public Key
          Encryption (PKE) scheme may include multiple PKE
          algorithms. Component algorithms could be all traditional, all
          post-quantum, or a mixture of the two.</t>
        </dd>
        <dt pn="section-2-4.7">Post-Quantum Traditional (PQ/T) hybrid scheme:</dt>
        <dd pn="section-2-4.8">
          <t indent="0" pn="section-2-4.8.1">A multi-algorithm scheme where at least one component algorithm
          is a post-quantum algorithm and at least one is a traditional
          algorithm.</t>
          <t indent="0" pn="section-2-4.8.2">Components of a PQ/T hybrid scheme operate on the same input
          message and their output is used together to complete the
          cryptographic operation either serially or in parallel. PQ/T hybrid
          scheme design is aimed at requiring successful breaking of all
          component algorithms to break the PQ/T hybrid scheme's security
          properties.</t>
        </dd>
        <dt pn="section-2-4.9">PQ/T hybrid Key Encapsulation Mechanism (KEM):</dt>
        <dd pn="section-2-4.10">
          <t indent="0" pn="section-2-4.10.1">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 pn="section-2-4.11">PQ/T hybrid Public Key Encryption (PKE):</dt>
        <dd pn="section-2-4.12">
          <t indent="0" pn="section-2-4.12.1">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 indent="0" pn="section-2-4.12.2">The standard security property for a PKE scheme is
          indistinguishability under chosen-plaintext attack
          (IND-CPA) <xref target="BDPR" format="default" sectionFormat="of" derivedContent="BDPR"/>. 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 indistinguishability under chosen-ciphertext
          attack (IND-CCA) <xref target="BDPR" format="default" sectionFormat="of" derivedContent="BDPR"/>, are required.</t>
        </dd>
        <dt pn="section-2-4.13">PQ/T hybrid digital signature:</dt>
        <dd pn="section-2-4.14">
          <t indent="0" pn="section-2-4.14.1">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 indent="0" pn="section-2-4.14.2">Note that there are many possible ways of constructing a PQ/T
          hybrid digital signature. Examples include parallel signatures,
          composite signatures, or nested signatures.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-2-5">PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures
      are all examples of PQ/T hybrid schemes.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-2-6">
        <dt pn="section-2-6.1">Post-Quantum Traditional (PQ/T) hybrid composite scheme:</dt>
        <dd pn="section-2-6.2">
          <t indent="0" pn="section-2-6.2.1">A multi-algorithm scheme where at least one component algorithm
          is a post-quantum algorithm and at least one is a traditional
          algorithm, and where the resulting composite scheme is exposed as a
          singular interface of the same type as the component algorithms.</t>
          <t indent="0" pn="section-2-6.2.2">A PQ/T hybrid composite can be referred to as a "PQ/T
          composite". An example of a PQ/T hybrid composite is a single KEM
          algorithm comprised of a PQ KEM component and a traditional KEM
          component, for which the result presents as a KEM output.</t>
        </dd>
        <dt pn="section-2-6.3">PQ/T hybrid combiner:</dt>
        <dd pn="section-2-6.4">
          <t indent="0" pn="section-2-6.4.1">A method that takes two or more component algorithms and combines them to form a PQ/T hybrid scheme.</t>
        </dd>
        <dt pn="section-2-6.5">PQ/PQ hybrid scheme:</dt>
        <dd pn="section-2-6.6">
          <t indent="0" pn="section-2-6.6.1">A multi-algorithm scheme where all components are post-quantum
          algorithms.</t>
          <t indent="0" pn="section-2-6.6.2">The definitions for types of PQ/T hybrid schemes can be adapted
          to define types of PQ/PQ hybrid schemes, which are multi-algorithm
          schemes where all component algorithms are post-quantum
          algorithms. These are designed to mitigate risks when the two
          post-quantum algorithms are based on different mathematical
          problems. Some prefer to refer to these as PQ/PQ multi-algorithm
          schemes, and reserve the term "hybrid" for PQ/T hybrids.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-2-7">In cases where there is little chance of confusion between other
      types of hybrid cryptography (e.g., as defined in <xref target="RFC4949" format="default" sectionFormat="of" derivedContent="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 newline="true" indent="3" spacing="normal" pn="section-2-8">
        <dt pn="section-2-8.1">Component scheme:</dt>
        <dd pn="section-2-8.2">
          <t indent="0" pn="section-2-8.2.1">Each cryptographic scheme that makes up a PQ/T hybrid scheme or PQ/T hybrid protocol.</t>
        </dd>
      </dl>
    </section>
    <section anchor="cryptographic-elements" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-cryptographic-elements">Cryptographic Elements</name>
      <t indent="0" pn="section-3-1">This section introduces terminology related to cryptographic elements
      and their inclusion in hybrid schemes.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-3-2">
        <dt pn="section-3-2.1">Cryptographic element:</dt>
        <dd pn="section-3-2.2">
          <t indent="0" pn="section-3-2.2.1">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 indent="0" pn="section-3-2.2.2">Types of cryptographic elements include public keys, private
          keys, plaintexts, ciphertexts, shared secrets, and signature
          values.</t>
        </dd>
        <dt pn="section-3-2.3">Component cryptographic element:</dt>
        <dd pn="section-3-2.4">
          <t indent="0" pn="section-3-2.4.1">A cryptographic element of a component algorithm in a
          multi-algorithm scheme.</t>
          <t indent="0" pn="section-3-2.4.2">For example, in <xref target="I-D.ietf-tls-hybrid-design" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/>, the
          client's keyshare contains two component public keys: one for a
          post-quantum algorithm and one for a traditional algorithm.</t>
        </dd>
        <dt pn="section-3-2.5">Composite cryptographic element:</dt>
        <dd pn="section-3-2.6">
          <t indent="0" pn="section-3-2.6.1">A cryptographic element that incorporates multiple component
          cryptographic elements of the same type for use in a multi-algorithm
          scheme, such that the resulting composite cryptographic element is
          exposed as a singular interface of the same type as the component
          cryptographic elements.</t>
          <t indent="0" pn="section-3-2.6.2">For example, a composite cryptographic public key is made up of
          two component public keys.</t>
        </dd>
        <dt pn="section-3-2.7">PQ/T hybrid composite cryptographic element:</dt>
        <dd pn="section-3-2.8">
          <t indent="0" pn="section-3-2.8.1">A cryptographic element that incorporates multiple component
          cryptographic elements of the same type for use in a multi-algorithm
          scheme, such that the resulting composite cryptographic element is
          exposed as a singular interface of the same type as the component
          cryptographic elements, where at least one component cryptographic
          element is post-quantum and at least one is traditional.</t>
        </dd>
        <dt pn="section-3-2.9">Cryptographic element combiner:</dt>
        <dd pn="section-3-2.10">
          <t indent="0" pn="section-3-2.10.1">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 indent="0" pn="section-3-2.10.2">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" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/>, or
          something more involved such as the dualPRF defined in <xref target="BINDEL" format="default" sectionFormat="of" derivedContent="BINDEL"/>.</t>
        </dd>
      </dl>
    </section>
    <section anchor="protocols" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-protocols">Protocols</name>
      <t indent="0" pn="section-4-1">This section introduces terminology related to the use of
      post-quantum and traditional algorithms together in protocols.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-4-2">
        <dt pn="section-4-2.1">PQ/T hybrid protocol:</dt>
        <dd pn="section-4-2.2">
          <t indent="0" pn="section-4-2.2.1">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 indent="0" pn="section-4-2.2.2">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" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/>, 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" format="default" sectionFormat="of" derivedContent="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 indent="0" pn="section-4-2.2.3">A protocol that can negotiate the use of either a traditional
          algorithm or a post-quantum algorithm, but not the use of both types of
          algorithm, is not a PQ/T hybrid protocol.  Protocols that use two or
          more component algorithms but with different cryptographic
          functionalities, for example, a post-quantum KEM and a Pre-Shared Key
          (PSK), are also not PQ/T hybrid protocols.</t>
        </dd>
        <dt pn="section-4-2.3">PQ/T hybrid protocol with composite key establishment:</dt>
        <dd pn="section-4-2.4">
          <t indent="0" pn="section-4-2.4.1">A PQ/T hybrid protocol that incorporates a PQ/T hybrid composite
          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 indent="0" pn="section-4-2.4.2">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" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/>.</t>
        </dd>
        <dt pn="section-4-2.5">PQ/T hybrid protocol with composite data authentication:</dt>
        <dd pn="section-4-2.6">
          <t indent="0" pn="section-4-2.6.1">A PQ/T hybrid protocol that incorporates a PQ/T hybrid composite
          scheme to achieve data 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 indent="0" pn="section-4-2.6.2">For example, a PQ/T hybrid protocol with composite data
          authentication could include data authentication through the use of a
          PQ/T composite hybrid digital signature, exposed as a single
          interface for PQ signature and traditional signature components.</t>
        </dd>
        <dt pn="section-4-2.7">PQ/T hybrid protocol with composite entity authentication:</dt>
        <dd pn="section-4-2.8">
          <t indent="0" pn="section-4-2.8.1">A PQ/T hybrid protocol that incorporates a PQ/T hybrid composite
          scheme to achieve entity 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 indent="0" pn="section-4-2.8.2">For example, a PQ/T hybrid protocol with composite entity
          authentication could include entity authentication through the use of
          PQ/T Composite Hybrid certificates.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-4-3">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 newline="true" indent="3" spacing="normal" pn="section-4-4">
        <dt pn="section-4-4.1">PQ/T hybrid protocol with non-composite key establishment:</dt>
        <dd pn="section-4-4.2">
          <t indent="0" pn="section-4-4.2.1">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
          as a part of a single-algorithm scheme.</t>
          <t indent="0" pn="section-4-4.2.2">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 the Internet Key
          Exchange Protocol Version 2 (IKEv2) is enabled by <xref target="RFC9370" format="default" sectionFormat="of" derivedContent="RFC9370"/>.</t>
        </dd>
        <dt pn="section-4-4.3">PQ/T hybrid protocol with non-composite authentication:</dt>
        <dd pn="section-4-4.4">
          <t indent="0" pn="section-4-4.4.1">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
          as part of a single-algorithm scheme.</t>
          <t indent="0" pn="section-4-4.4.2">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 indent="0" pn="section-4-5">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 indent="0" pn="section-4-6">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" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/> describes a PQ/T hybrid protocol
      with composite key agreement, but with single-algorithm
      authentication.</t>
      <t indent="0" pn="section-4-7">PQ/T hybrid protocols may not specify non-composite aspects, but can
      choose to do so for clarity, in particular, if including both composite
      and non-composite aspects.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-4-8">
        <dt pn="section-4-8.1">PQ/T hybrid composite protocol:</dt>
        <dd pn="section-4-8.2">
          <t indent="0" pn="section-4-8.2.1">A PQ/T hybrid protocol that only uses composite constructions can
          be referred to as a "PQ/T hybrid composite protocol".</t>
          <t indent="0" pn="section-4-8.2.2">An example of this is a protocol that only provides entity
          authentication, and achieves this using PQ/T hybrid composite entity
          authentication. Similarly, another example is a protocol that offers both key
          establishment and data authentication, and achieves this using both
          PQ/T hybrid composite key establishment and PQ/T hybrid composite
          data authentication.</t>
        </dd>
        <dt pn="section-4-8.3">PQ/T hybrid non-composite protocol:</dt>
        <dd pn="section-4-8.4">
          <t indent="0" pn="section-4-8.4.1">A PQ/T hybrid protocol that does not use only composite
          constructions can be referred to as a "PQ/T hybrid non-composite
          protocol".</t>
          <t indent="0" pn="section-4-8.4.2">For example, a PQ/T hybrid protocol that offers both
          confidentiality and authentication and uses composite key agreement
          and non-composite authentication would be referred to as a "PQ/T
          hybrid non-composite protocol".</t>
        </dd>
      </dl>
    </section>
    <section anchor="properties" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-properties">Properties</name>
      <t indent="0" pn="section-5-1">This section describes some properties that may be desired from or
      achieved by a PQ/T hybrid scheme or a PQ/T hybrid protocol.  Properties of
      PQ/T hybrid schemes are still an active area of research and
      development, e.g., in <xref target="BINDELHALE" format="default" sectionFormat="of" derivedContent="BINDELHALE"/>. This section does not
      attempt to be comprehensive, but rather covers a basic set of
      properties.</t>
      <t indent="0" pn="section-5-2">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 newline="true" indent="3" spacing="normal" pn="section-5-3">
        <dt pn="section-5-3.1">PQ/T hybrid confidentiality:</dt>
        <dd pn="section-5-3.2">
          <t indent="0" pn="section-5-3.2.1">The property that confidentiality 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>
        <dt pn="section-5-3.3">PQ/T hybrid authentication:</dt>
        <dd pn="section-5-3.4">
          <t indent="0" pn="section-5-3.4.1">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 indent="0" pn="section-5-4">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 indent="0" pn="section-5-5">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" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/> provides hybrid confidentiality
      but does not address hybrid authentication.  Therefore, if the design in
      <xref target="I-D.ietf-tls-hybrid-design" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/> is used with
      single-algorithm X.509 certificates as defined in <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, only authentication with a single algorithm is
      achieved.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-5-6">
        <dt pn="section-5-6.1">PQ/T hybrid interoperability:</dt>
        <dd pn="section-5-6.2">
          <t indent="0" pn="section-5-6.2.1">The property that a PQ/T hybrid scheme or a PQ/T hybrid protocol
          can be completed successfully provided that both parties share
          support for at least one component algorithm.</t>
          <t indent="0" pn="section-5-6.2.2">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" format="default" sectionFormat="of" derivedContent="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 indent="0" pn="section-5-7">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 indent="0" pn="section-5-8">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" format="default" sectionFormat="of" derivedContent="HYBRID-TLS"/>, 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 it
      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 indent="0" pn="section-5-9">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 newline="true" indent="3" spacing="normal" pn="section-5-10">
        <dt pn="section-5-10.1">PQ/T hybrid backwards compatibility:</dt>
        <dd pn="section-5-10.2">
          <t indent="0" pn="section-5-10.2.1">The property that a PQ/T hybrid scheme or a 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 pn="section-5-10.3">PQ/T hybrid forwards compatibility:</dt>
        <dd pn="section-5-10.4">
          <t indent="0" pn="section-5-10.4.1">The property that a PQ/T hybrid scheme or a PQ/T hybrid protocol
          can be completed successfully using a post-quantum component
          algorithm provided that both parties support it, while also having
          the option to use both post-quantum and traditional algorithms if
          both are supported by both parties.</t>
          <t indent="0" pn="section-5-10.4.2">Note that PQ/T hybrid forwards compatibility is a protocol or scheme property only.</t>
        </dd>
      </dl>
    </section>
    <section anchor="certificates" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-certificates">Certificates</name>
      <t indent="0" pn="section-6-1">This section introduces terminology related to the use of
      certificates in hybrid schemes.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-6-2">
        <dt pn="section-6-2.1">PQ/T hybrid certificate:</dt>
        <dd pn="section-6-2.2">
          <t indent="0" pn="section-6-2.2.1">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 indent="0" pn="section-6-2.2.2">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 indent="0" pn="section-6-2.2.3">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 indent="0" pn="section-6-2.2.4">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 pn="section-6-2.3">Post-quantum certificate:</dt>
        <dd pn="section-6-2.4">
          <t indent="0" pn="section-6-2.4.1">A digital certificate that contains a single public key for a
          post-quantum digital signature algorithm.</t>
        </dd>
        <dt pn="section-6-2.5">Traditional certificate:</dt>
        <dd pn="section-6-2.6">
          <t indent="0" pn="section-6-2.6.1">A digital certificate that contains a single public key for a
          traditional digital signature algorithm.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-6-3">X.509 certificates as defined in <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> could be
      either traditional or post-quantum certificates depending on the
      algorithm in the Subject Public Key Info.  For example, a certificate
      containing a ML-DSA public key, as defined in <xref target="I-D.ietf-lamps-dilithium-certificates" format="default" sectionFormat="of" derivedContent="ML-DSA"/>, would be a
      post-quantum certificate.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-6-4">
        <dt pn="section-6-4.1">Post-quantum certificate chain:</dt>
        <dd pn="section-6-4.2">
          <t indent="0" pn="section-6-4.2.1">A certificate chain where all certificates include a public key
          for a post-quantum algorithm and are signed using a post-quantum
          digital signature scheme.</t>
        </dd>
        <dt pn="section-6-4.3">Traditional certificate chain:</dt>
        <dd pn="section-6-4.4">
          <t indent="0" pn="section-6-4.4.1">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 pn="section-6-4.5">PQ/T hybrid certificate chain:</dt>
        <dd pn="section-6-4.6">
          <t indent="0" pn="section-6-4.6.1">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 indent="0" pn="section-6-5">A PQ/T hybrid certificate chain is one way of achieving hybrid
      authentication of the identity of a sender in a protocol, but it is not the
      only way. An alternative is to use a PQ/T parallel PKI as defined
      below.</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-6-6">
        <dt pn="section-6-6.1">PQ/T mixed certificate chain:</dt>
        <dd pn="section-6-6.2">
          <t indent="0" pn="section-6-6.2.1">A certificate chain containing at least two of the three
          certificate types defined in this document (PQ/T hybrid certificates,
          post-quantum certificates, and traditional certificates).</t>
          <t indent="0" pn="section-6-6.2.2">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 pn="section-6-6.3">PQ/T parallel PKI:</dt>
        <dd pn="section-6-6.4">
          <t indent="0" pn="section-6-6.4.1">Two certificate chains, one that is a post-quantum certificate chain and
          one that is a traditional certificate chain, and that are used together in a
          protocol.</t>
          <t indent="0" pn="section-6-6.4.2">A PQ/T parallel PKI might be used to achieve hybrid authentication
          or hybrid interoperability depending on the protocol
          implementation.</t>
        </dd>
        <dt pn="section-6-6.5">Multi-certificate authentication:</dt>
        <dd pn="section-6-6.6">
          <t indent="0" pn="section-6-6.6.1">Authentication that uses two or more end-entity certificates.</t>
          <t indent="0" pn="section-6-6.6.2">For example, multi-certificate authentication may be achieved
          using a PQ/T parallel PKI.</t>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">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. More general guidance about the security considerations,
      timelines, and benefits and drawbacks of the use of PQ/T hybrids is also out
      of scope of this document.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-lamps-dilithium-certificates" to="ML-DSA"/>
    <displayreference target="I-D.ietf-tls-hybrid-design" to="HYBRID-TLS"/>
    <displayreference target="I-D.ietf-lamps-pq-composite-kem" to="COMPOSITE-KEM"/>
    <references anchor="sec-informative-references" pn="section-9">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="BDPR" target="https://www.cs.ucdavis.edu/~rogaway/papers/relations.pdf" quoteTitle="true" derivedAnchor="BDPR">
        <front>
          <title>Relations Among Notions of Security for Public-Key Encryption Schemes</title>
          <author initials="M." surname="Bellare">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Desai">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Pointcheval">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Rogaway">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="June" year="2001"/>
        </front>
      </reference>
      <reference anchor="BINDEL" target="https://doi.org/10.1007/978-3-030-25510-7_12" quoteTitle="true" derivedAnchor="BINDEL">
        <front>
          <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Brendel" fullname="Jacqueline Brendel">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Fischlin" fullname="Marc Fischlin">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Goncalves" fullname="Brian Goncalves">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Stebila" fullname="Douglas Stebila">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="July"/>
        </front>
        <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
        <refcontent>Post-Quantum Cryptography, PQCrypto 2019, Lecture Notes in Computer Science, vol. 11505, pp. 206-226</refcontent>
      </reference>
      <reference anchor="BINDELHALE" target="https://eprint.iacr.org/2023/423.pdf" quoteTitle="true" derivedAnchor="BINDELHALE">
        <front>
          <title>A Note on Hybrid Signature Schemes</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Hale" fullname="Britta Hale">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2023" month="July" day="23"/>
        </front>
        <refcontent>Cryptology ePrint Archive, Paper 2023/423</refcontent>
      </reference>
      <reference anchor="I-D.ietf-lamps-pq-composite-kem" target="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-kem-06" quoteTitle="true" derivedAnchor="COMPOSITE-KEM">
        <front>
          <title>Composite ML-KEM for use in X.509 Public Key Infrastructure and CMS</title>
          <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
            <organization showOnFrontPage="true">Entrust Limited</organization>
          </author>
          <author initials="J." surname="Gray" fullname="John Gray">
            <organization showOnFrontPage="true">Entrust Limited</organization>
          </author>
          <author initials="M." surname="Pala" fullname="Massimiliano Pala">
            <organization showOnFrontPage="true">OpenCA Labs</organization>
          </author>
          <author initials="J." surname="Klaussner" fullname="Jan Klaussner">
            <organization showOnFrontPage="true">Bundesdruckerei GmbH</organization>
          </author>
          <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
            <organization showOnFrontPage="true">Cisco Systems</organization>
          </author>
          <date month="March" day="18" year="2025"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-kem-06"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="ETSI_TS103774" target="https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf" quoteTitle="true" derivedAnchor="ETSI_TS103774">
        <front>
          <title>CYBER; Quantum-safe Hybrid Key Exchanges</title>
          <author>
            <organization showOnFrontPage="true">European Telecommunications Standards Institute (ETSI)</organization>
          </author>
          <date year="2020" month="December"/>
        </front>
        <refcontent>ETSI TS 103 744 v1.1.1</refcontent>
      </reference>
      <reference anchor="I-D.ietf-tls-hybrid-design" target="https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-12" quoteTitle="true" derivedAnchor="HYBRID-TLS">
        <front>
          <title>Hybrid key exchange in TLS 1.3</title>
          <author fullname="Douglas Stebila" initials="D." surname="Stebila">
            <organization showOnFrontPage="true">University of Waterloo</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization showOnFrontPage="true">Cisco Systems</organization>
          </author>
          <author fullname="Shay Gueron" initials="S." surname="Gueron">
            <organization showOnFrontPage="true">University of Haifa and Meta</organization>
          </author>
          <date day="14" month="January" year="2025"/>
          <abstract>
            <t indent="0">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-12"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="ITU-T-X509-2019" target="https://www.itu.int/rec/T-REC-X.509-201910-I" quoteTitle="true" derivedAnchor="ITU-T-X509-2019">
        <front>
          <title>Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks</title>
          <author>
            <organization showOnFrontPage="true">ITU-T</organization>
          </author>
          <date year="2019" month="October"/>
        </front>
        <seriesInfo name="ITU-T Recommendation" value="X.509"/>
      </reference>
      <reference anchor="I-D.ietf-lamps-dilithium-certificates" target="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11" quoteTitle="true" derivedAnchor="ML-DSA">
        <front>
          <title>Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Digital Signature Algorithm (ML-DSA)</title>
          <author initials="J." surname="Massimo" fullname="Jake Massimo">
            <organization showOnFrontPage="true">AWS</organization>
          </author>
          <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
            <organization showOnFrontPage="true">AWS</organization>
          </author>
          <author initials="S." surname="Turner" fullname="Sean Turner">
            <organization showOnFrontPage="true">sn3rd</organization>
          </author>
          <author initials="B. E." surname="Westerbaan" fullname="Bas Westerbaan">
            <organization showOnFrontPage="true">Cloudflare</organization>
          </author>
          <date month="May" day="22" year="2025"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-certificates-11"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs" quoteTitle="true" derivedAnchor="NIST_PQC_FAQ">
        <front>
          <title>Post-Quantum Cryptography (PQC) FAQs</title>
          <author>
            <organization showOnFrontPage="true">NIST</organization>
          </author>
          <date year="2025" month="January" day="31"/>
        </front>
      </reference>
      <reference anchor="NIST_SP_800-152" target="https://doi.org/10.6028/NIST.SP.800-152" quoteTitle="true" derivedAnchor="NIST_SP_800-152">
        <front>
          <title>A Profile for U. S. Federal Cryptographic Key Management Systems</title>
          <author initials="E." surname="Barker" fullname="Elaine B. Barker">
            <organization showOnFrontPage="true">Information Technology Laboratory</organization>
          </author>
          <author initials="M." surname="Smid" fullname="Miles Smid">
            <organization showOnFrontPage="true">Information Technology Laboratory</organization>
          </author>
          <author initials="D." surname="Branstad" fullname="Dannis Branstad">
            <organization showOnFrontPage="true">Information Technology Laboratory</organization>
          </author>
          <date year="2015" month="October"/>
        </front>
        <seriesInfo name="NIST SP" value="800-152"/>
        <seriesInfo name="DOI" value="10.6028/NIST.SP.800-15"/>
      </reference>
      <reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4949" quoteTitle="true" derivedAnchor="RFC4949">
        <front>
          <title>Internet Security Glossary, Version 2</title>
          <author fullname="R. Shirey" initials="R." surname="Shirey"/>
          <date month="August" year="2007"/>
          <abstract>
            <t indent="0">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" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9180" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9370" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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 indent="0">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>
      <reference anchor="RFC9763" target="https://www.rfc-editor.org/info/rfc9763" quoteTitle="true" derivedAnchor="RFC9763">
        <front>
          <title>Related Certificates for Use in Multiple Authentications within a Protocol</title>
          <author initials="A." surname="Becker" fullname="Alison Becker">
            <organization showOnFrontPage="true">National Security Agency</organization>
          </author>
          <author initials="R." surname="Guthrie" fullname="Rebecca Guthrie">
            <organization showOnFrontPage="true">National Security Agency</organization>
          </author>
          <author initials="M." surname="Jenkins" fullname="Michael J. Jenkins">
            <organization showOnFrontPage="true">National Security Agency</organization>
          </author>
          <date month="June" year="2025"/>
        </front>
        <seriesInfo name="RFC" value="9763"/>
        <seriesInfo name="DOI" value="10.17487/RFC9763"/>
      </reference>
    </references>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">This document is the product of numerous fruitful discussions in the
      IETF PQUIP group.  Thank you in particular to <contact fullname="Mike       Ounsworth"/>, <contact fullname="John Gray"/>, <contact fullname="Tim       Hollebeek"/>, <contact fullname="Wang Guilin"/>, <contact fullname="Rebecca Guthrie"/>, <contact fullname="Stephen Farrell"/>,
      <contact fullname="Paul Hoffman"/>, and <contact fullname="Sofía Celi"/>
      for their contributions.  This document is inspired by many others from
      the IETF and elsewhere.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Florence Driscoll" initials="F." surname="Driscoll">
        <organization showOnFrontPage="true">UK National Cyber Security Centre</organization>
        <address>
          <email>florence.d@ncsc.gov.uk</email>
        </address>
      </author>
      <author fullname="Michael Parsons" initials="M." surname="Parsons">
        <organization showOnFrontPage="true">UK National Cyber Security Centre</organization>
        <address>
          <email>michael.p1@ncsc.gov.uk</email>
        </address>
      </author>
      <author fullname="Britta Hale" initials="B." surname="Hale">
        <organization showOnFrontPage="true">Naval Postgraduate School</organization>
        <address>
          <email>britta.hale@nps.edu</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
