<?xml version='1.0' encoding='utf-8'?> 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.21 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pquip-pqt-hybrid-terminology-06" number="9794" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 --> version="3" updates="" obsoletes="" xml:lang="en">

  <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-06"/> name="RFC" value="9794"/>
    <author fullname="Florence Driscoll"> Driscoll" initials="F." surname="Driscoll">
      <organization>UK National Cyber Security Centre</organization>
      <address>
        <email>florence.d@ncsc.gov.uk</email>
      </address>
    </author>
    <author fullname="Michael Parsons"> Parsons" initials="M." surname="Parsons">
      <organization>UK National Cyber Security Centre</organization>
      <address>
        <email>michael.p1@ncsc.gov.uk</email>
      </address>
    </author>
    <author fullname="Britta Hale"> Hale" initials="B." surname="Hale">
      <organization>Naval Postgraduate School</organization>
      <address>
        <email>britta.hale@nps.edu</email>
      </address>
    </author>
    <date year="2025" month="January" day="10"/> month="June"/>
    <area>SEC</area>
    <workgroup>PQUIP</workgroup>
    <keyword>Internet-Draft</keyword>
    <workgroup>pquip</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 120?>
      <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 125?>

<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. 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 (2024) (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>Ongoing responses to the potential development of a CRQC include
      modifying established (standardised) (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,
      "post-quantum", while algorithms based on integer factorisation,
      finite-field discrete logarithms logarithms, or elliptic-curve discrete logarithms
      are called traditional "traditional cryptographic algorithms. algorithms". In this document document,
      "traditional algorithm" is also used to refer to this class of
      algorithms.</t>

      <t>At the time of publication, the term post-quantum "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 "quantum-resistant" or quantum-safe "quantum-safe"
      algorithms. There are merits to the different terms, for example terms. For example, some
      prefer to use the terms quantum-resistant or quantum-safe to explictly explicitly
      indicate that these algorithms are designed to be secure against quantum computers but others disagree,
      computers. Others disagree and prefer to use the term post-quantum, in case
      of compromises against such algorithms which 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 attack. Post-quantum cryptography 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 pre-quantum, or quantum-vulnerable, are preferred by some.</t>
      <t>There

<!-- [rfced] May we update this sentence as follows for clarity?

Original:
   There may be a requirement for protocols that use both algorithm
   types, for example during the transition from traditional to post-
   quantum algorithms or as a general solution, to mitigate risks.

Perhaps:
   To mitigate risks, there may be a requirement for protocols that
   use both algorithm types (for example, during the transition from
   traditional to post-quantum algorithms or as a general solution).
-->

      <t>There may be a requirement for protocols that use both algorithm
      types, for example, during the transition from traditional to
      post-quantum algorithms or as a general solution, to mitigate
      risks. 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 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"/>, <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"/>.</t>
      target="RFC9763"/>.</t>

      <t>Schemes that combine post-quantum and traditional algorithms for key
      establishment or digital signatures are often called hybrids. "hybrids". For
      example:</t>

      <ul spacing="normal">
        <li>

<!-- Quotations from [NIST_PQC_FAQ] and [ETSI_TS103774] are accurate. -->
          <t>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"/>;</t> target="NIST_PQC_FAQ"/>.</t>
        </li>
        <li>
          <t>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"/>.</t>
        </li>
      </ul>

      <t>The word "hybrid" is also used in cryptography to describe encryption
      schemes that combine asymmetric and symmetric algorithms <xref
      target="RFC9180"/>, so using it in the post-quantum context overloads it
      and risks misunderstandings.  However, this terminology is
      well-established amongst the post-quantum cryptography 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>

<!-- [rfced] May we adjust the text below as follows to make the verbs
"reduce" and "defining" parallel?

Original:
   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 and traditional
   hybrid constructions.

Perhaps:
   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>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 documents, in order 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 and traditional hybrid constructions.</t>

<!-- Quotation from [NIST_SP_800-152] is accurate. -->
      <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 Elliptic Curve
      Diffie-Hellman (ECDH), Module-Lattice-Based Key-Encapsulation Mechanism
      (ML-KEM) (formerly known as Kyber) Kyber), and ML-DSA 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"/> 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>

      <dl newline="true">
        <dt><strong>Traditional Asymmetric Cryptographic Algorithm</strong>:</dt> asymmetric 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> problems.</t>

          <t>A related mathematical problem is one that can be solved by
          solving the integer factorisation, finite field discrete logarithm logarithm,
          or elliptic curve discrete logarithm problem.</t>

          <t>Where there is little risk of confusion, traditional asymmetric
          cryptographic algorithms can also be referred to as traditional algorithms "traditional
          algorithms" for brevity.  Traditional algorithms can also be called classical
          "classical" or conventional "conventional" algorithms.</t>
        </dd>
        <dt><strong>Post-Quantum Asymmetric Cryptographic Algorithm</strong>:</dt>

        <dt><strong>Post-quantum asymmetric cryptographic algorithm</strong>:</dt>

        <dd>
          <t>An asymmetric cryptographic algorithm that is intended to be
          secure against attacks using quantum computers as well as classical computers.
</t>
          computers.</t>

          <t>Where there is little risk of confusion, post-quantum asymmetric
          cryptographic algorithms can also be referred to as post-quantum algorithms "post-quantum
          algorithms" for brevity. Post-quantum algorithms can also be called quantum-resistant
          "quantum-resistant" or quantum-safe "quantum-safe" algorithms.</t>

          <t>As with all cryptography, it always remains the case that
          attacks, either quantum or classical, may be found against
          post-quantum algorithms. Therefore Therefore, it should not be assumed that
          just because an algorithm is designed to provide post-quantum
          security that it will not be compromised. Should an attack be found
          against a post-quantum algorithm, it is commonly still referred to
          as a post-quantum algorithm "post-quantum algorithm", as they were designed to protect against
          an adversary with access to a CRQC CRQC, and the labels are referring to
          the designed or desired properties.</t>
        </dd>
      </dl>

      <t>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>

      <dl newline="true">
        <dt><strong>Component Asymmetric Algorithm</strong>:</dt> asymmetric algorithm</strong>:</dt>
        <dd>
          <t>Each cryptographic algorithm that forms part of a cryptographic scheme.
</t>
          scheme.</t>
          <t>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 aysmmetric asymmetric algorithms can
          also be referred to as component algorithms "component algorithms" for brevity, as is done
          in the following definitions.</t>
        </dd>
        <dt><strong>Single-Algorithm Scheme</strong>:</dt>

        <dt><strong>Single-algorithm scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme with one component algorithm.
</t> 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>

        <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 as each other and as the multi-algorithm scheme.
</t>
          scheme.</t>
          <t>For example, a multi-algorithm signature scheme may include
          multiple signature algorithms 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><strong>Post-Quantum Traditional (PQ/T) Hybrid Scheme</strong>:</dt> 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>
          algorithm.</t>
          <t>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. The 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><strong>PQ/T Hybrid hybrid Key Encapsulation Mechanism (KEM)</strong>:</dt>
        <dd>
          <t>A multi-algorithm KEM made up of two or more component algorithms
          where at least one is a post-quantum algorithm and at least one is a
          traditional algorithm.  The component algorithms could be KEMs, KEMs or
          other key establishment algorithms.</t>
        </dd>

        <dt><strong>PQ/T Hybrid hybrid Public Key Encryption (PKE)</strong>:</dt>
        <dd>
          <t>A multi-algorithm PKE scheme made up of two or more component
          algorithms where at least one is a post-quantum algorithm and at
          least one is a traditional algorithm.  The component algorithms
          could be PKE algorithms, algorithms or other key establishment algorithms.
</t> algorithms.</t>
          <t>The standard security property for a PKE scheme is
          indistinguishability under chosen-plaintext attack, attack
          (IND-CPA). IND-CPA security is not sufficient for secure
          communication in the presence of an active attacker.  Therefore, in
          general, PKE schemes are not appropriate for use on the internet, Internet,
          and KEMs, which provide indistiguishability indistinguishability under chosen-ciphertext attacks
          attack (IND-CCA security), are required.</t>
        </dd>

        <dt><strong>PQ/T Hybrid Digital Signature</strong>:</dt> 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> algorithm.</t>
          <t>Note that there are many possible ways of constructing a PQ/T
          hybrid digital signatures. signature. Examples include parallel signatures,
          composite signatures signatures, or nested signatures.</t>
        </dd>
      </dl>

      <t>PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures
      are all examples of PQ/T hybrid schemes.</t>
      <dl>

      <dl newline="true">
        <dt><strong>Post-Quantum Traditional (PQ/T) Hybrid Composite Scheme</strong>:</dt> hybrid composite 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
          algorithm, and where the resulting composite scheme is exposed as a
          singular interface of the same type as the component algorithms.
</t> algorithms.</t>
          <t>A PQ/T Hybrid Composite hybrid composite can be referred to as a PQ/T Composite. "PQ/T
          composite". Examples of PQ/T Hybrid Composites hybrid composites include 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><strong>PQ/T Hybrid Combiner</strong>:</dt> 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> hybrid scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where all components are post-quantum algorithms.
</t>
          algorithms.</t>
          <t>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 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 "hybrid" for PQ/T hybrids.</t>
        </dd>
      </dl>

      <t>In cases where there is little chance of confusion between other
      types of hybrid cryptography e.g., (e.g., as defined in <xref target="RFC4949"/>,
      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>

      <dl newline="true">
        <dt><strong>Component Scheme</strong>:</dt> scheme</strong>:</dt>
        <dd>
          <t>Each cryptographic scheme that makes up a PQ/T hybrid scheme or PQ/T hybrid protocol.</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>

      <dl newline="true">
        <dt><strong>Cryptographic Element</strong>:</dt> 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> 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> cryptographic element</strong>:</dt>
        <dd>
          <t>A cryptographic element of a component algorithm in a
          multi-algorithm scheme.
</t> scheme.</t>
          <t>For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the
          client's keyshare contains two component public keys, keys: one for a
          post-quantum algorithm and one for a traditional algorithm.</t>
        </dd>

        <dt><strong>Composite Cryptographic Element</strong>:</dt> cryptographic element</strong>:</dt>
        <dd>
          <t>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> elements.</t>
          <t>For example, a composite cryptographic public key is made up of
          two component public keys.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Composite Cryptographic Element</strong>:</dt> hybrid composite cryptographic element</strong>:</dt>
        <dd>
          <t>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><strong>Cryptographic Element Combiner</strong>:</dt> 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>
          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>

      <dl newline="true">
        <dt><strong>PQ/T Hybrid Protocol</strong>:</dt> 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> algorithm.</t>
          <t>For example, a PQ/T hybrid protocol providing confidentiality
          could use a PQ/T hybrid KEM such as in <xref
          target="I-D.ietf-tls-hybrid-design"/>, or it could combine the
          output of a post-quantum KEM and a traditional KEM at the protocol
          level to generate a single shared secret, such as in <xref
          target="RFC9370"/>.  Similarly, a PQ/T hybrid protocol providing
          authentication could use a PQ/T hybrid digital signature scheme, or
          it could include both post-quantum and traditional single-algorithm
          digital signature schemes.</t>
          <t>A protocol that can negotiate the use of either a traditional
          algorithm or a post-quantum algorithm, but not of both types of
          algorithm, is not a PQ/T hybrid protocol.  Protocols that use two or
          more component algorithms but with different cryptographic functionality,
          functionalities, for example example, a post-quantum KEM and a pre-shared key (PSK) Pre-Shared Key
          (PSK), are also not PQ/T hybrid protocols.</t>
        </dd>

        <dt><strong>PQ/T Hybrid Protocol hybrid protocol with Composite Key Establishment</strong>:</dt> composite key establishment</strong>:</dt>
        <dd>
          <t>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> scheme.</t>
          <t>For example, a PQ/T hybrid protocol with composite key
          establishment could include a single PQ/T hybrid KEM, such as in
          <xref target="I-D.ietf-tls-hybrid-design"/>.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol hybrid protocol with Composite Data Authentication</strong>:</dt> composite data authentication</strong>:</dt>
        <dd>
          <t>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> scheme.</t>
          <t>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> components.</t>
        </dd>

        <dt><strong>PQ/T Hybrid Protocol hybrid protocol with Composite Entity Authentication</strong>:</dt> composite entity authentication</strong>:</dt>
        <dd>
          <t>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> scheme.</t>
          <t>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>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>

      <dl newline="true">
        <dt><strong>PQ/T Hybrid Protocol hybrid protocol with Non-Composite Key Establishment</strong>:</dt> non-composite key establishment</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates multiple
          single-algorithm schemes to achieve key establishment, where at
          least one uses a post-quantum algorithm and at least one uses a
          traditional algorithm, in such a way that the formats of the
          component cryptographic elements are the same as when they are used
          as a part of a single-algorithm scheme.
</t> scheme.</t>
          <t>For example, a PQ/T hybrid protocol with non-composite key
          establishment could include a traditional key exchange scheme and a
          post-quantum KEM. A construction like this for IKEv2 the Internet Key
          Exchange Protocol Version 2 (IKEv2) is enabled by <xref
          target="RFC9370"/>.</t>
        </dd>

        <dt><strong>PQ/T Hybrid Protocol hybrid protocol with Non-Composite Authentication</strong>:</dt> 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
          as part of a single-algorithm scheme.
</t> 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 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>
      <t>PQ/T hybrid protocols may not specify non-composite aspects, but can
      choose to do so for clarity, in particular particular, if including both composite
      and non-composite aspects.</t>
      <dl>

      <dl newline="true">
        <dt><strong>PQ/T Hybrid Composite Protocol</strong>:</dt> hybrid composite protocol</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that only uses composite constructions can
          be referred to as a PQ/T Hybrid Composite Protocol.
</t>
          <t>For example, "PQ/T hybrid composite protocol".</t>
          <t>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><strong>PQ/T Hybrid Non-Composite Protocol</strong>:</dt> hybrid non-composite protocol</strong>:</dt>
        <dd>
          <t>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> "PQ/T hybrid non-composite
          protocol".</t>
          <t>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 "PQ/T
          hybrid non-composite protocol.</t> protocol".</t>
        </dd>
      </dl>
    </section>
    <section anchor="properties">
      <name>Properties</name>
      <t>This section describes some properties that may be desired from or
      achieved by a PQ/T hybrid scheme or 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"/>. This section does not
      attempt to be comprehensive, but rather covers a basic set of
      properties.</t>
      <t>It is not possible for one PQ/T hybrid scheme or PQ/T hybrid protocol
      to achieve all of the properties in this section. To understand what
      properties are required 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>

      <dl newline="true">
        <dt><strong>PQ/T Hybrid Confidentiality</strong>:</dt> hybrid confidentiality</strong>:</dt>
        <dd>
          <t>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><strong>PQ/T Hybrid Authentication</strong>:</dt> 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"/>
      target="RFC5280"/>, only authentication with a single algorithm is
      achieved.</t>
      <dl>

      <dl newline="true">
        <dt><strong>PQ/T Hybrid Interoperability</strong>:</dt> hybrid interoperability</strong>:</dt>
        <dd>
          <t>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> 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 Section 7.2.2 of <xref
          target="ITU-T-X509-2019"/>.  In this example 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
      interoperability, a scheme needs to work whenever one component algorithm
      is supported by both parties, while to achieve PQ/T hybrid confidentiality
      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 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>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>

      <dl newline="true">
        <dt><strong>PQ/T Hybrid Backwards Compatibility</strong>:</dt> hybrid backwards compatibility</strong>:</dt>
        <dd>
          <t>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><strong>PQ/T Hybrid Forwards Compatibility</strong>:</dt>
        <dd>
          <t>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> parties.</t>
          <t>Note that PQ/T hybrid forwards compatability compatibility is a protocol or scheme property only.</t>
        </dd>
      </dl>
    </section>

    <section anchor="certificates">
      <name>Certificates</name>
      <t>This section introduces terminology related to the use of
      certificates in hybrid schemes.</t>
      <dl>

      <dl newline="true">
        <dt><strong>PQ/T Hybrid Certificate</strong>:</dt> 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> 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 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>
        <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> 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>

      <dl newline="true">
        <dt><strong>Post-quantum certificate chain</strong>:</dt>
        <dd>
          <t>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><strong>Traditional Certificate Chain</strong>:</dt> 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> 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 it is not the
      only way. An alternative is to use a PQ/T parallel PKI as defined
      below.</t>
      <dl>

      <dl newline="true">
        <dt><strong>PQ/T Mixed Certificate Chain</strong>:</dt> mixed certificate chain</strong>:</dt>
        <dd>
          <t>A certificate chain containing at least two of the three
          certificate types defined in this draft document (PQ/T hybrid certificates,
          post-quantum certificates certificates, and traditional certificates)
</t> 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 parallel PKI</strong>:</dt>
        <dd>
          <t>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>
          protocol.</t>
          <t>A PQ/T parallel PKI might be used to achieve hybrid authentication
          or hybrid interoperability depending on the protocol
          implementation.</t>
        </dd>
        <dt><strong>Multi-Certificate Authentication</strong>:</dt>

        <dt><strong>Multi-certificate authentication</strong>:</dt>
        <dd>
          <t>Authentication that uses two or more end-entity certificates.
</t> certificates.</t>
          <t>For example, multi-certificate authentication may be achieved
          using a PQ/T parallel PKI.</t>
        </dd>
      </dl>
    </section>

    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document defines security-relevant terminology to be used in
      documents specifying PQ/T hybrid protocols and schemes.  However, the
      document itself does not have a security impact on Internet protocols.
      The security considerations for each PQ/T hybrid protocol are specific
      to that protocol and should be discussed in the relevant specification
      documents. 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">
      <name>IANA Considerations</name>
      <t>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">
      <name>Informative References</name>

<!-- [BINDEL] -->
      <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> 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">
        <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>

<!-- [ETSI_TS103774] -->
      <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>
            <organization>European Telecommunications Standards Institute (ETSI)</organization>
          </author>
          <date year="2020" month="December"/>
        </front>
        <refcontent>ETSI TS 103 744 v1.1.1</refcontent>
      </reference>

<!-- [ITU-T-X509-2019] Date was changed from January 2019 to October 2019 to match the information at the URL. -->
      <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
          <title>Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks</title>
          <author>
            <organization>ITU-T</organization>
          </author>
          <date year="2019" month="January"/> month="October"/>
        </front>
        <seriesInfo name="ITU-T Recommendation" value="X.509"/>
      </reference>

<!-- [rfced] FYI, this reference has been edited to show the most
recent date it was updated (31 January 2025). Please review and
let us know if you prefer otherwise.

Original:
   [NIST_PQC_FAQ]
              National Institute of Standards and Technology (NIST),
              "Post-Quantum Cryptography FAQs", 5 July 2022,
              <https://csrc.nist.gov/Projects/post-quantum-cryptography/
              faqs>.
Current:
   [NIST_PQC_FAQ]
              NIST, "Post-Quantum Cryptography (PQC) FAQs", 31 January
              2025, <https://csrc.nist.gov/Projects/post-quantum-
              cryptography/faqs>.
-->

      <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs">
        <front>
          <title>Post-Quantum Cryptography (PQC) FAQs</title>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
            <organization>NIST</organization>
          </author>
          <date year="2022" month="July" day="05"/> year="2025" month="January" day="31"/>
        </front>
      </reference>

<!-- [NIST_SP_800-152] -->
      <reference anchor="NIST_SP_800-152" target="https://doi.org/10.6028/NIST.SP.800-152">
        <front>
          <title>NIST SP 800-152 A
          <title>A Profile for U. S. Federal Cryptographic Key Management Systems</title>
          <author initials="E. B." initials="E." 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>
        <seriesInfo name="NIST SP" value="800-152"/>
        <seriesInfo name="DOI" value="10.6028/NIST.SP.800-15"/>
      </reference>

<!-- [I-D.ietf-lamps-dilithium-certificates] draft-ietf-lamps-dilithium-certificates
IESG State: IESG Evaluation. Updated to "long way" to match the document's header.-->

<reference anchor="I-D.ietf-lamps-dilithium-certificates"> anchor="I-D.ietf-lamps-dilithium-certificates" target="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11">
   <front>
      <title>Internet X.509 Public Key Infrastructure: Infrastructure - Algorithm Identifiers for ML-DSA</title> Module-Lattice-Based Digital Signature Algorithm (ML-DSA)</title>
      <author fullname="Jake Massimo" initials="J." surname="Massimo"> surname="Massimo" fullname="Jake Massimo">
         <organization>AWS</organization>
      </author>
      <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis"> surname="Kampanakis" fullname="Panos Kampanakis">
         <organization>AWS</organization>
      </author>
      <author fullname="Sean Turner" initials="S." surname="Turner"> surname="Turner" fullname="Sean Turner">
         <organization>sn3rd</organization>
      </author>
      <author initials="B. E." surname="Westerbaan" fullname="Bas Westerbaan" initials="B." surname="Westerbaan"> Westerbaan">
         <organization>Cloudflare</organization>
      </author>
      <date day="4" month="November" year="2024"/>
          <abstract>
            <t>   Digital signatures are used within X.509 certificates, Certificate
   Revocation Lists (CRLs), and to sign messages.  This document
   describes the conventions for using FIPS 204, the Module-Lattice-
   Based Digital Signature Algorithm (ML-DSA) in Internet X.509
   certificates and certificate revocation lists.  The conventions for
   the associated signatures, subject public keys, and private key are
   also described.

            </t>
          </abstract> month="May" day="22" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-certificates-05"/> value="draft-ietf-lamps-dilithium-certificates-11" />

</reference>

<!-- [I-D.ietf-lamps-cert-binding-for-multi-auth]
in AUTH48 as RFC-to-be 9763 as of 5/29/25.
-->
<reference anchor="I-D.ietf-lamps-cert-binding-for-multi-auth"> anchor="RFC9763" target="https://www.rfc-editor.org/info/rfc9763">
<front>
      <title>Related Certificates for Use in Multiple Authentications within a Protocol</title>
      <author fullname="Alison Becker" initials="A." surname="Becker"> surname="Becker" fullname="Alison Becker">
         <organization>National Security Agency</organization>
      </author>
      <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie"> surname="Guthrie" fullname="Rebecca Guthrie">
         <organization>National Security Agency</organization>
      </author>
      <author initials="M." surname="Jenkins" fullname="Michael J. Jenkins" initials="M. J." surname="Jenkins"> Jenkins">
         <organization>National Security Agency</organization>
      </author>
<date day="10" month="December" year="2024"/>
          <abstract>
            <t>   This document defines a new CSR attribute, relatedCertRequest, and a
   new X.509 certificate extension, RelatedCertificate.  The use of the
   relatedCertRequest attribute in a CSR and the inclusion of the
   RelatedCertificate extension in the resulting certificate together
   provide additional assurance that two certificates each belong to the
   same end entity.  This mechanism is particularly useful in the
   context of non-composite hybrid authentication, which enables users
   to employ the same certificates in hybrid authentication as in
   authentication done with only traditional or post-quantum algorithms.

            </t>
          </abstract> month='June' year='2025'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-multi-auth-06"/> name="RFC" value="9763"/>
<seriesInfo name="DOI" value="10.17487/RFC9763"/>
</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

<!-- [I-D.ietf-tls-hybrid-design] draft-ietf-tls-hybrid-design-12 IESG State: I-D Exists as of Haifa</organization>
          </author>
          <date day="7" month="October" year="2024"/>
          <abstract>
            <t>   Hybrid key exchange refers 02/12/25. -->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-hybrid-design.xml"/>

<!-- [I-D.ietf-lamps-pq-composite-kem]
 Updated 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 "long way" to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange match information 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-11"/>
      </reference> header. -->

<reference anchor="I-D.ietf-lamps-pq-composite-kem"> anchor="I-D.ietf-lamps-pq-composite-kem" target="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-kem-06">
   <front>
      <title>Composite ML-KEM for use in X.509 Public Key Infrastructure and CMS</title>
      <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth"> surname="Ounsworth" fullname="Mike Ounsworth">
         <organization>Entrust Limited</organization>
      </author>
      <author fullname="John Gray" initials="J." surname="Gray"> surname="Gray" fullname="John Gray">
         <organization>Entrust Limited</organization>
      </author>
      <author fullname="Massimiliano Pala" initials="M." surname="Pala"> surname="Pala" fullname="Massimiliano Pala">
         <organization>OpenCA Labs</organization>
      </author>
      <author fullname="Jan Klaußner" initials="J." surname="Klaußner"> surname="Klaussner" fullname="Jan Klaussner">
         <organization>Bundesdruckerei GmbH</organization>
      </author>
      <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer"> surname="Fluhrer" fullname="Scott Fluhrer">
         <organization>Cisco Systems</organization>
      </author>
      <date day="21" month="October" year="2024"/>
          <abstract>
            <t>   This document defines combinations of ML-KEM [FIPS.203] in hybrid
   with traditional algorithms RSA-OAEP, ECDH, X25519, and X448.  These
   combinations are tailored to meet security best practices and
   regulatory requirements.  Composite ML-KEM is applicable in any
   application that uses X.509, PKIX, and CMS data structures and
   protocols that accept ML-KEM, but where the operator wants extra
   protection against breaks or catastrophic bugs in ML-KEM.  For use
   within CMS, this document is intended to be coupled with the CMS
   KEMRecipientInfo mechanism in [RFC9629].

            </t>
          </abstract> month="March" day="18" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-kem-05"/> value="draft-ietf-lamps-pq-composite-kem-06" />

</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>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9180.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9370.xml"/>
    </references>

    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve document is the comprehensibility product of written material that is generated numerous fruitful discussions 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
      IETF PQUIP group.  Thank you 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 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 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 IETF 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 elsewhere.</t>
    </section>
  </back>

<!-- [rfced] Abbreviations:

a) Regarding IND-CPA and X.509 v2 certificate revocation list (CRL) for use IND-CCA in the Internet. An overview of this approach and model is provided as an introduction. Section 2:

Current:
   The X.509 v3 certificate format standard security property for a PKE scheme is described
   indistinguishability under chosen-plaintext attack (IND-CPA).
   IND-CPA security is not sufficient for secure communication 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
   presence of required certificate extensions is specified. The X.509 v2 CRL format is described an active attacker.  Therefore, in detail along with standard and Internet-specific extensions. An algorithm general, PKE
   schemes are not appropriate for X.509 certification path validation is described. An ASN.1 module use on the Internet, and examples KEMs,
   which provide indistiguishability under chosen-ciphertext attack
   (IND-CCA security), 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 required.

- Is the Internet word 'security' needed in a way 'IND-CCA security'?
- We note that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="RFC9180">
        <front>
          <title>Hybrid Public Key Encryption</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes"/>
          <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
          <author fullname="B. Lipp" initials="B." surname="Lipp"/>
          <author fullname="C. Wood" initials="C." surname="Wood"/>
          <date month="February" year="2022"/>
          <abstract>
            <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also RFC 9771 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 references for any combination of an asymmetric KEM, key derivation function (KDF), IND-CCA and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not IND-CCA2. Would
you like to add references to this document, or will this be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
            <t>This document is a product of sufficiently
clear to the Crypto Forum Research Group (CFRG) in reader? (See https://www.rfc-editor.org/rfc/rfc9771#section-4.2.1)

b) FYI, we added expansions for abbreviations upon first use for the IRTF.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9180"/>
        <seriesInfo name="DOI" value="10.17487/RFC9180"/>
      </reference>
      <reference anchor="RFC9370">
        <front>
          <title>Multiple Key Exchanges
items below. Please review each expansion 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 carefully to extend the
ensure correctness.

Elliptic Curve Diffie-Hellman (ECDH)
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) (per FIPS 203)
Module-Lattice-Based Digital Signature Algorithm (ML-DSA)
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
-->

<!-- [rfced] For readability we have formatted the IKE SA is being rekeyed or is creating additional Child SAs.</t>
            <t>This lists in this
document updates RFC 7296 by renaming with a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" line break between each term and renaming a field in its definition.
We suggest removing 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 <strong> element (which yields bold font
in IKEv2.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9370"/>
        <seriesInfo name="DOI" value="10.17487/RFC9370"/>
      </reference>
    </references>
    <?line 386?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document is the product of numerous fruitful discussions HTML and PDF, and yields asterisks in the IETF PQUIP group.  Thank you TXT); please let
us know if removing <strong> is acceptable.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in particular to Mike Ounsworth, John Gray, Tim Hollebeek, Wang Guilin, Rebecca Guthrie, Stephen Farrell, Paul Hoffman and Sofía Celi more precise language, which is helpful for their contributions.  This readers.

In addition, please consider whether "traditional" should be updated throughout
this document is inspired by many others from for clarity.  While the IETF and elsewhere.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1d63LcNpb+7yq/A0v7Y+xUd0uWnThWaqtGkeREcexRLGUz
+8uFJtHdGLHJNkFK7p3yu+wL7EvsvtieCwACJMiWbGdmd2riJJa6QVwOzuU7
F4DT6fThg1rVuTxK9q5ktVZFmZfLbbIoq+Si1PX0l0YUdbNOriqRqVqVhciT
H7fzSmXJZbqSa6n3Hj4Q83klb6CLi1/2r+zXXnfQJBW1XJbV9ihRxaJ8+ODh
g6xMC7GGgbNKLOqpkvViunnfqA38v56uqJNp3XYyPfjm4QPdzNdKa5hHvd3A
s+dnVy8fPiia9VxWR9AnjAJ/pWWhZaEbfZTUVSMfPoC5PYVpVlIcJZdnJw8f
3JbV9bIqm81RcvHLr+cXDx9cyy18mEGXBQxayHp6ivOCZ2XRYKdJEj6QJDyF
36ArVSyTH/Bb/HgtVH6UrOp6o4/29/E3UaUrdSNnuMZZWS338YP9eVXearm/
eZ/u42P42b0fwz+iqVclrj6ZYj9JsmjynEn7Mi8rWaQyOa2UTss85wbQlyjU
fwjcz6Pk11fJG2G29mQLhEwuZdpUqt4mJ7KoK8kPSV7XwnQ5y/5YpDqdLcub
WXMdG/y1SldC5smFqDRsyOcPveYOZ5snu4b+HrqoRfKjyGVs2DfiBgZE/l4C
WzfANMjMZZkHw82pk9kKOvljsdEzmTVIbuTfag093TBXfH/+5vTs5yN+tBbV
UtbtNmalop17cjB7cnDwfP/F82+nT6cHTw+mh19//eRg+vzdk0PzJEuhEZ5X
cpucFanY6CanSSevJSy+UHqtE1FkyTFsOlBIoVyZ5h+wwdIsuGUK+mdqf0hA
/kAs3syS71WRybz9nCn3RhWi81X32Z/gWWCByMM/ifR9I3NVyG6Lbh+vZ8lL
4MgVtO128hq4vPdl9/nvZ8kPJdAnv5G62wFsvij6X3e7OJ0ll7Wcg5h1Ozgt
m2UudPh1JRegVmqg+VGoGU+q7aYugZE2q22y2cwOD76ZHh5+w09pWSmpkWXc
Vpz+6fwo2c0PpMqSw4MnL6YHz5HvLKf9ePzz2QC3yU2linqmRFoR1x0eHD7d
f3b4dLbJFgGXHSdvSmB6YCury9WyEHVTSavVI1zkCBjnoAH+CZ+CfWuF0tuw
UFp9WjN5ySjJC1xecsxqcQKKZQMawy4yJNshUPX5FD/Fz8+uLs/fXV0+OXj6
/PmzAeLd3t7OZK1ZXmH6MES1jx+8q/U+Pnlw8A7/evGCfnv2bP/gyYz+fffN
wX6t3/GnNwdP8M+mR/OTf//+7O13iWGbqRYLGUi7Ed8Y5YGKqMGOaB3J1SWw
z9MExkr+7ckM/nRWfjBlHjq/+nV6Nf3z1wcvpshGI8tWdTMDyu5XMt2/mr49
O5n+eWYfA6Y8D9ZB3SbUILlagWlR8FgNph0medHMc5VOwZaSkhJ1Xal5A5yW
yqpWC9JWyaKCXUcDPLpUGqYvCrTYN+eXV+8ufjl59/L4l4FlpbpKZ6Aua7QS
+xdV+ReYpN7foOS+N1uQepK7vxDvdbDOYSGHUUen7kzaeaGhM1x/uQBtAiQR
Vcb6+wrUucFaj3A5jzubeIjse/C1XW1yeZF8ewA7+/XhbkvzzcHht/v41Ozy
YmaeCpbW6RHUARBooXJJuO9XUIygnmUmKzTL7cpVSpz6WhRiCToCRPFyq2u5
HiBGV62e5YIsAygOUV3Lqv2eN9zaVdBKHnV+FvOyEshfgx2/hpmDtl6r7It1
eSoKYB7QTAK2UHyJfr8UZzz5evrkgLXa+fSUsOE0F+uNnmYqV/VKIWO30qaP
Ii3x++kclDTg1iksZbpu8lpNcQPD5nWuLRLPwIwti1hvm/fTtFyDZKlaguiv
qc3blyfPXjx7YX/++vDbA/vzt8+efWN/fvGk/fwFqNgjhrTT6TQRc11XIq0T
/uhPwDpCb0CKkWQAfgDaw+aQT5LUZeJLdiJy8DWAGACWVJGkAQtvqrIuAQvD
V5r6yeSNzMsNMTR0zetNNNtBaCFq6CQtqw1urkzmZb3qjAa7Vnv+kdDb9VqC
6ku9icwS0JYwIrg9DQ2VyQWIAwzQcbt0k67s6PDQeY3zVGgNM0B6sNK5TBoN
PwJCEWgqJUN8mMUkWZUbiTB4O8GW6AOBSUd3CDQhtGK1nIJngRAbYEKpYUZq
QX3ULWkmibY8OaFHGD9rYl+Yld0jELkMjfbDB/+CflNVZk2KTR4+QMsAEgKr
EAhSc+x7noOuQBLjapZguhcCDYfplsbJAPdVEqgM5BBmB8sbbKoKhbZDyRzk
BMgk81xtoOsE/AVAeUkD5Kk2sNtr2BrLItGdYOohqdFOSVgpGC29ok3hOSxV
DTPWFhNpBErYnTKuIe2l1NItiom0on2gcdvB5gJH4w7Wk+RW5Tnu4E2TF6Bf
4WncKDCUIr3GmaEneQlq9A86Obad4NMC+GIBIq1glvk2yVH7J0uJfeTTTQPM
CdOxDIniCLqlmiTXRXlbMKcEilwAiyRvZS5v4InEWTnzXPLo5O0vJ49hmSdN
ZThDZoq2Vic3Amw9TOkW1jvBrVCLCXOtQFlSQANapfyA5jdJfixvQcJgMopY
uZCp1Br7wIWjC6M2KFdIQRhmA146fgPiIRFCLMFowIa2/VtZhZ5PBcBGIDqu
jGQjE6A0wXo+ewxTADEFP8BtRZfkPWolKTSHrdHAk4ZBMkl9I3fOQV7AwySM
zNsFT/AgCVILpoMgGvcv1D4blgqjSXB18gOqMSfM0AY4ksZbi2KbbCU4zMxR
9AhMqyhrEvtNRu4etARC5SKVIPLYo8g1MlECsnQN22GmhNQ2BIOHMvCrYXLI
nvB7ZS1RrhayVmvJIiNqO98ZK91liQ+BDGwwpqJxytjDpkR0ruD5jva0Ixdp
3mSgAkrQLlvswskZTOWR1S4KZOOxp5GhdyRFXGwd/dgUOfppDBlIxyndbdXI
/regLvBvYhGQLVCBWpNecs2cUHtD4mgoKzCWr/FBjFeIlmJiHtVtE6O/pqS/
4lquVWlTUmnRVt6EfIsTWjjf6Jyj4vHNzl5gqWzLPeQV4iJSjkBYMiy83crQ
i/a37RsZ5LhmU2wYaEP43yyZvgDjFhpL6MyoLdBAdjDY0RQ8BTm4kLtuPgp8
BsqG9AtLZ4rqhiWe5fRiACmkpC00dUurr3gUYBvrMYAcKOTdGrfrve/J+TQH
NsIpwX9rcP9rJzStoUWygIijyMsPAKKAl3S5RntiqY5iYAl4l/HR2n/YAPHR
OiCyI1eLqFbHuPq+MgReXALAB38EvhTLSsqJVdnelEMpQewFcoGcgT1V5Vqh
Dgl1ejsvECr4IC0bEJG1uL4fAaDrXApEtOC+qDVGTxEFdcjKPyCMJHyMPAif
9g1uZfcshmEMJgSiSNRslolhlBvCEGQdOnzm+5r4KNBjXRZWBAT8vNQsS0FL
bNaA5qCVOPDAI66qslmuyqYOJTxYvpPBIbEf7lK2OkOgORqRdDbstyqTdkGK
AZM3ffANoWvmIcv/bCWQhk4fT5CMjmreJrfWm03exokoWGbc5ZlxtMg3YhFc
AxyAtSFKft+oin1WFDrP4uBWIucSrG/BAsb2OxLqGVDP9VgAVwe6eMQXgc4I
ihkFCNPOG6MrS2DgWi1RaNGIgxb5DeAVDUZGHUiegckvyZYW8jYAGdDnHFAy
Q0/Qd4yGViAsqzJnJANfqYoWihI5IShFGqAiKsFGzdE5FwNzt0gnykX8JQ6+
LOFztBIZ7SqSWaYM7j0FHUFPVty0Df/Doxv0YkFdwI83KuONNsTvz4Gt95YW
Q0pc4Z4x9w6tSeQoddD14MJo+40GW6slgybecliITEtNARCEwhWGU1GdxDpi
neumhBIPqhMlhba+LIyqthpBD7HQLDljbiRjbPnHsDFrTsfMxMKBzbawbELq
HKeEwDIHdcFodJL89a/GEf/4EX8ZDgR0vo9HArARLrTXcCQA8fEjAYtL3/22
3DnudbfEjvt2iOf7rh1SoVwAmrW4ipcJlH7Zyj6FJb6icOcnhXCcs2+CC/3J
sRkWyR57/s7ECLN45jzE6LclrmRdkmMPxC7gcQ8fobnSEhMfHTAFY07DMU2Q
YQ/2x4+ofvz4nV3sWYNiKDDKlUujzFnpa2/JLSUeYYA6vlob3jYr3cOgRF01
acC/Vgn5++o/ncxmM6s2AmboNQIYjogP/WlQ3f7XuNwgH2A4DteLGeBkj6fd
gcRhHGkboFbjguIO6Rjf+v4MsEfUu2HJe/ItSR4NihoULWthPC4fTWB25ENN
oZG8FLAHimMXZDsQC1E4hNws6Eb7XjiBBT/opNg9mvoemg9INoM45hFwzOPW
yBvkC9JH2BAVvVxviLfXaJ7ELShnUp4Iiq3PC30YzYX4jRqjMiCLK8ltIg4x
RizRYk0RLbRyE3RMsTFSqsBPF422oSRwj8lsmmgXBq3GvBXDq333hGJyn6GN
vsO9sTDLOVgD4M3hJMKtK4FUyzHoRPlmA3owzKQNesZHYRlyKnzwatSpM47M
374baIyqBjIVy0YseS9GhDJYXJENG6hLA64960RmtEDmYrhM5tRuctzZ74Vt
7RYYTEf6z+IomCi7ucB2eV7eWphmhoKJyI5lxj3lTwfX0UoMW/fKRMvgdyRW
2lBYMHg8cMlbtU0RCOOFsYaG6cN+GjRhGBvhc4Ua6NqKPBa39MLGfjC4EwH2
hXrZIK7Bvhlx2+fZE868IDAGhP0A8ScHhZPjzK6eXQ9/2kKtNTtgWZPKnoZC
ANvUdsPqnir2QjisFPCRRK8EOgABC3tOtsU/o4Jq5D7gfJKXbuQEMfPeQHxi
j0NtaPUwIkfsy0bVS7OhYndmnjSuecK42RZYAMFToFJl3XfwhCnoqih0qQpo
ChvAmKX1oETf3FsHHeN5iHQAPzQ1PL0He+VgpI3Uvb08niRnJ6c/TpLXP09f
nb1OHmGSC+zLto0iv8IancfULTQ6vTyONTq1eSgMIBOMkB9AcVHVVpeCLNVE
vl7gSQSb4jw13VtqoPoEl2mR5h8MJkHn6UrJG3J4BLgZaQPi0HkAiAUbA6ZM
zpazCWEIinuY4PNxVEE5/SQyjNdySJTr0/DnRVMYFvPhJbLWSMVP8gi247FB
g7ExjfwiG5D0wCTbkY6o6x9IVbKpC4ZhJjmV3keRxVkl4GfCNPktDovGtDX0
FCzz6udLBjqYA/z4MbYkN5JNvCF3aqf+LbR3O4EYIEVdkYutrDwoxgvTssL0
kWjLpXCBnLG6qNDzUVQjREpWG2dVmVRWJzsHFkCYsP0ga5F6KaNahS1slEzk
Xnzl11get1YxzMC7INVXX4FXcpQcF74FHRKMu4Wnk8Hw9CTpJNzijSgxwUSK
Jv9mnLg+Hm2FXOE8YpuTKcGjMaGe/Mba909bTD97GGtkJmNm/BtBgJr+D9MD
BVfnbWTGAc/JUB54kF9Ggs4jzi2W2xKmDepyB7o1fm2b8mCgh7HK7nOGEYPS
ly/Midax7WS0u3H8ICE6mtKJpXLuuWkhQPi8XRuK/QXbdpcUhNm2e6UejHhp
4yPnQWZoS4FakYMXpmHWa6Q0R2mFNtJmyA4mTxFq9OKwXoTWmLhF2XgJ2kEc
7XxCHF2vyNMz+UzoEaCVSXP+pdH4YSooA+gnbglbtekK47qEI7rAoXW2zBBt
3iGbYZwfR3cxyP4qhmKFNsbtwvZgbWGQzt4PRxqJ0Fvg2U7qxURI75G/Mnlh
UFViLnOOX/E0SCuaTJMdgnLYWuEU24gq12+EIfIhpo94hBQ3NAwSrLeg+Lbr
aCgSmqK5DibbevkUx57ZRCyG5hpKK+sUJs/gxk91sLo6sWEwX1d1tdOZwNzS
mFJCJKsJDjJqi5lqJl3S1XVuAh4UpRy7XzuyaVxdSgdo2nR8B6/38eiG4gWt
WSTMPEem1zJf4G7/pVRUIIIYpUTQVcsw5T+7u1r0lrXVER99RAtGKBKoQHaS
cCcLad3dRWl9d48jzBZfUhxv2mboOD5sLU8cFpP84ACR2TgkwhFCL3ziMLUN
phtWH8oRkM8Rl3sz+dcUjbnf3LtlZ5pRNkU6BpZkAxUm8danP4WT2hhaCLtN
CRFsi0RJ4agBFfGykeiElJw8GIHoeDO91q6+3HOTXJGIDQW1rTpJs15/XGhs
nSYbfH108ers8egI0CAwTicxOvHWo1YEFe9tOkWXOilunp36QLO2hYm3JeuJ
DpLysdojPCr1ODxK5TgiTmuzvcAXuRRY4xZnA3aqhgwRVWV7HVDjeEaNN/ak
zTGQVqQjXkGNpFV1VtMRd7G6W2Ol11Jam6Uqq8Raf38pOSPc0VdDGtIII56r
oBAtlp8VqLQRLeWz2PTYGNJKFaINrJOifDCqGt2QfV00OaomcW18aIJOMd5A
tIrtaJL9wf6gYylMC6u903E73f1BZsDQjBddiOaDwqqKHtd8KQ7h6E50VCdD
MF12DFmjREoue96HR6YROR8kEMq40wH/b+gUaqb7UIx7t7HZHv9xVbHwyULu
V8YRowZ6FXMM2W25hjZJV2AIiukGy/Upy8RgeZI8On9zOj25OH48S8xPHuzW
hLjbIlXOm7BXF2QOXUILPBoKW6O4AZBIKcNhiwOYZjaZBI+YWP/EW4d2KWyx
wcWCSqg5CExx5LBml8NBzI1caGT9CEOKYUqkagNT8UihDSlOWgI8nhgkToUm
WYSVT03u2R21GmTgXpb6zuzcf/Jvw+DMhnSmzJac2Qo4rGiFEbTC4DW5ngwy
jVdBkWtfj/ZT9LN+sNrqe6+VgatYehBUblfgq2gMNXkd4mQfPvBHZb7wPwE2
Y5YZn5wpv80t+KHl9e1CNLIyjAdO3FL+LyID54K22VeP9k7FyA+IKE2WCmE2
xdhJHhcidWiJ4ALmaizSjOlJB9d9iWqpZNyhnjtOrV2zsHgm2lPLYq52AO1t
u3SKJygKpjIaou+9KSMZA7IF33NFGeufloJGF9aaZ41PME5yMDKcKyZkq5Yn
AEGVmZ8s2mnrOOlH/RDN10gx9H+jAK9VZrDcT0GsPphiiRmKFrX2rJf7t9m8
iHDZ/ReZMAcBTDIueAomHz5mDQHpqegCdGwF3bKuQKY7kS8TxfBDPmGdH52i
sF7DYPAQ+3Ah/DbDGY+xJ5exmlcOtrCHx8QYWDJrPWTI6qYtwbWk44oNtwMu
VYoxRN06oEFoAXFtKoPgAuxWfSth5aYe1G6TzZv4VSacfhMuwcrJVXPAzJaY
7XB9SVgHmNRBsFhMCznP9wBV7UJmHubwCrY3qwrDqXsBq+1RLAJjWUQ7piFs
AWxSKjMu9OkFswIRi4Sv/EjBmuQeoEHcQQv2zKXYTBosjOqfcYni56bEpOnG
c/1Is2qDAKPWMToTl13Y4hlIwabiERD+hnzOypTxPLblKkVNgW1R2JCbczpv
RN5Ig4ZHMsjcwOZPkbRUtrIZfsqqLcvFA6Rw6IWdGgD2GsudeSHmNwu6Ec84
2ImlF1zqANtRydrIaIvyaGW6x0Gj9IzP0oQ+Y+ChGBShWSQGREI6Xj9K0pqj
swBuM65/Jfi0Iu8gKsR2IgHREJ8sRgJvXJ7iGg2DVkMtAhGfQq1ImM6Gmtqp
D7BDD/9Yz2WE0uagnQXZUQQWn+kXAWTxlQwFAYem1G4lzqrj1ER3POJO/XPf
PnvfJuN+w+B8evVUXb/Bk7cxzf7pUPauOzOGc3cQ3nkccTKYXqsWPWBNKnBS
YYoQbHmmASZDnJ0YlWceZVPam6EnMba4bFy1Un0jUhNZjIinihuuobATo9Rb
I/KLty9DZMXXzJiqaKySMfV/90YEXgnmXSv3XTyYD87ywLG4oPnOcU5YNkRl
Yju9IA4A2WKSSFLEYgCRU8rqdw+gdPRnDLN5k0YwrTI+hosxqzZjFT6K7qTd
9LuxjrJnSVzx70paEEX4IFgxOchRt9coOzf3HM8KI2dwMK/2vOwA30zC+boj
KXTG2p1t20mgsOhrkD5D4baQFBa87b7+oZdRHBqgjWqE3IvebCGXZc2+RStF
n56J5BM/GCqFbgZOB01sEDdOWIxFJK02aE/O7ZQzHJpysa3nOipn/qG7QV7D
Y4KGaVAtPrq4fPW4PQuPy4gtQsciKnZNPMkWWFDWwY+8O20TZbw+pggJ2YuR
eWWovSA/AWhz6QEem3DIwQ1nrsJAatg02yIvb12JOekz0vOlxSZYWGKPEfld
+aW1A/nwe2goomK72H7+IhQopwI6OqujBEYupUmMrbrbrtKlEceBavj99pU8
1lAP/ePsbGRxnb2NtTBHX6xOM0O1vQ5p5UkfB+fSQ8EcmfJTHz29bL9pg5Gz
//7Pu3POGSwC7OzfinckD/ePyj3R5XX4J96mw0FhkN9uon8Hlg1Sjk0scAi8
ordJYg8u8qlztRaVyrfsthqQy7eBOf9j2NvCS0PutFlcnsnX/OBBtIInkeGF
UEV7kJiP3kz4ziN/nrm6llwFZs8imKmGc8vVvBJ4Q+WEiQAoHtaXJ95ZzRDA
2fY79e2bsph+QUvqlQhF2VDvMKYR6G74+q7g3TSPIq9Boewyxi4HtiujNjmw
pW/4qgivQvELyWQBe3Ufez14OtfoMAPQOrhthr60f6AHeZTrOVF1n786uzmk
aAceFOSyRrD6BvvfxcSHLPd5Wvpe/NbV0P9ktjsz2y4XzSX6L16dt/WcwTlL
72ZRYENVuNhveG6524wdgZ1GIZzufQ1DR89zyNtX9ORjoj9mrYOneUe2jfQ0
17R/pj3oq/ZxUzBgP9jC2uggF3uYsqOowNE8XFaUBiSv1OOMIhshfu9kmehI
c4mepradhoESErcY41GBbKgJ3TmzyIQ6h8qC4IS6Dy2sIkEmFb2Tz+Ycomas
hlMwXaxFUVCllEeJnZ6Su7WgC0XH/DfvtJ1z5nv6IHLGLuqCUwKVisXopPi2
S1W65FPzSBgKwZvZNd8JWOIB+gWfRqkoVsDFn/YAp1p4J2J3MpQZaWYuDRrK
L3ixxmSXEWkvcBng2/FSlcGxZ/EMS2Rwd7B/wH0g5md+02x9+YxV3CuJdjIL
o3DDgjdwv2bMJx6aFvUTn1u893jbyJgRPBEiiPvse1ZKjp1x5WG+/az9j8/j
Hpb2U1SguZFIf7ICTG5tKiS+ODPJsIs2ushCSPkGUzbdSTi0istc6uZuiDIl
EFtrVOj6TrxnBLUuM1XGF3jeozgi8WYyVHeEppVPgnkVrJUU2B4raPCFHczz
7S2Z9jw5KOr2Qn/Et0m4WstR3i0q9jybBKprugIfdWQlKCqc4mUwSOy50Fgd
Igm3dYrQ2URjt4FpQrh0d9IE2DfPvbCBJZcydyeYxcDSyqS97wGgDt8zapv7
lbOJdzMZxt/dnVkVn+vDlNa1uS7idrX1AWu/mNQeUunITOeOJYdDFv6AzNOu
wJkGNzDKzLWja0IJ69Cu7yPQBaJ2KjQyLpJOOpgi5Fs+Ytgfq9symh4PpmP8
n6t2m7auXiaYNuaoPlFiUNTxRjUS+V2lqHyS0FwKYiuxiWfc/OwRVS4ij6wx
6uL1l9jRUndc4YBm/f3XeDVwDd7g6Zv2OkO8IlAWmTuIY3vBK7fr+KE8U4Wz
KlUqu1rO5rjtXcRYZ7uxzGmq9l25/knoJ/hjx+uJ0BCCsOEN7/U9l9ym+IaF
Lyp3Xa9BGc0V3q0VOcw5MBG8A7Qqr6W57dadOyS5pQhe5H7azvWH/fPrFmRH
bwqP3584grZbLHBnKJBxAs3e1I1erdfBAM3pBvS7EH08Ad0C2IFxkDatccwy
vFlmcGD/DAnvtT0NtisR7o6oxZ0dfv+JH2SOVajiaw+gKwKEXbDEm2fSGGGN
vlFPEZV33tH8FptGtN59NLcBpfYEXuYdi2tdClOXwwlwwRLKJXu62WzKio/8
7NKKu1FsP12+VstV7SDHgBG0G+yleXhVAItgj1jbmww6fbT1bnP1LwYb1giT
oHiGCoCxLNfbdYvens8OZ4eoNoDJwtfwUBWDvVuqzXKbSVZM45XQ5r5RBtGW
wIMvudAtfoLmvDxzH2l3NV5CzYKQ/uAoW24CpIm6fUYzay6oVttrJbhcJPBL
rEW0+8k37/adkY7gT0YhkF2/vaNggAs7owxHYGNWwNyQ18VLZnOYwXzpGEPc
UfHsEmV0wX1nN5yZrTgX7la2sM4iISUR1uYYVT0+rp1tIWVGG0l31mH0GK/L
Gzt8NEgplxtrCTC2tMHjGDgl7xUp/iV+PFyLLeyREQsF1WAkGOfaqDwzt0xm
5W2Brw2U/vXG8gNd0pjHw6QDt2Hdq0Ta1LTB73iJVktJuu1M0wQKSuLS/X43
uErd0cwxlrPIztyThVTReNeruZeS71LDsFpt+9Ie1LG3EzKkrfmtFuyIwSz/
oPkdIHSlQ4RqdM+pC/qMbDgDIk5qFIUhOU21NiCJQtrKVUh5ZKNTqLQ2Bxos
UeroEW6a1agEdE30lTv0rul9o91DMrtlt4dbIlqjqxwMgIjtKXgoJjbQCUNH
ngl1M+p+/2BLbNsisOR7AKS3dBcwhq1gEQ6d/F3BibfPnas5Y3dn8Bs93NW7
4YXwGrmLP2oBz4DKD2kDIv93Io2NiOx0b+5AQ1UHJFoJdwlbyWfyzRGoO7wd
61NI6h8u9imxsMRNibi+hLZUchf4tqRGGGOPP3kY/nNKnANfYOiEUxCiaR9w
6WmLff10ZXiuya8dp3ORn3qvwfDR3rtWOIeHcq3q9hOtNiBs7/ZciBQ3iCt/
hxWgH4R1BvxOD7RK3kKBfr2vN8PvYKsxxRy+oVJ3Js7BuUyBjDRx9eEfXI2X
+ffgRZROpsbClLhF6//5HRLR6XQPzPB8wjq7yOgeyVp/v+NsdchtIr5sojnI
wyACY7zfMXSgwCqLDQt1GNjhsBOGSPCXqsFXhYVOIaCqIpuaEYYFIk4nE0Oh
870o0RzgtRrxziXafRa2cbxRwuiyqczNFjbdbybkrr/7DALH7hL4NGXi4g8e
g0XO1Y1cKxG5uvRLT8VXVLtmcq+wTPfgbycOMFQ/ok2Yla4KYlc3OCWJH1w2
c3zhrH9/Db40tF+1EKoBogWzqLlf2edorNExeDdY0d1eBJqgP+FSdF1U0Dbc
wV0Y6FVtPVW//MY7MR9aRFs+Ns5rHVNUya7s7uDM4MqCAbb8HdYwYk37Sxjn
6O6lCzHA8KkrEN2sVfAlzJYuf/O7a5Unv+VnJ9wgF8NHEPyWrDsDDtt8BHOM
IA5avLlAGKvjUAWTpvWyBbt1rTCals22BRfGpWJjSdAXg2Ewyozug/Te06B0
B3oEdWyeRprLvLz1t/q1+iDvt9O+1rB0pF0yl9HRbeCB3qWTP54G4Ts1K7Go
+RqaGHNMRtRhF+H7Xz5mINJVe37zASvvtLNhP8rVBZMgt3otM9XBb/ZeD1xa
UxV36KkqYUd9HchhDb+kgBIwWeMK5+x7M1swE1CrpkO+ObMDnnvCCiVmLuAm
QTERc5adbxyQ5uKsFP0LoanEbTQV2OcELoMABooc0R3wwAweacNmAhpszUUj
gkK40/l2SqFcrCsI/JgLj6mtP4vnXLsTMwf2h01Op3BTjBd4ThJ3DW14h2Ag
rAYBW+8kEEDOJ7j3KI8jsWowitODAe0t+UERQXANqC/a8Rrl7mGH2HnWuMxY
2B9KG59I98nYWaK90MSGQoNKCp9wxmO+tCx5gu8dyMzVjLr7ihn7FijLwVP7
BpXAmfZeaE3BVfuaElMc2C1Na/OadAOGC6x6rzfyXlxo7sV1Hg6/UMe7tY7z
z0CDc3NNnH9SMJS/NFiseTVcuooHZsjo2xfhkMYQtfctTn1ltRJePt9o762J
jk7uPZUmK2toM0te+2+/wVe90AU7XBRTD096Qq8+ynFXOKc/hy4WytzSAhbg
dk6324F+8c/W8OK0ex/W+J3Mto7r/PjN8Q4O4UwTtxTeq1fw1eI4E+7oOMVX
i+QyW5qLaf56xC/UkNm/7i1gRnLvY7dn82p3vkuZZguPgPQ2sHFVo2q879PQ
nXbTe+MOrPnX8wuOfBMPiOI62ZZNp9QUNvU1HmD4U1Po27LCCu6fylWR/FAJ
gOpXag0sCXIzl/J6kvwmgI1/aEBtgPZ6Cx+mqYDfwTYrENDLWm6w9v6lqGDr
8YpDAdP7sVws1oK14mW5+J//EgALcuW9zREtf6XmjS2IjrwoSG+UeUUmXcRn
3uDK76y06yXYB1QkyDh78L/r+6TyFIwAAA== NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
-->

</rfc>