<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.0.2) -->
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-reddy-cose-jose-pqc-hybrid-hpke-05" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 -->
  <front>
    <title abbrev="PQ/T Hybrid KEM: HPKE with JOSE/COSE">PQ/T Hybrid KEM: HPKE with JOSE/COSE</title>
    <seriesInfo name="Internet-Draft" value="draft-reddy-cose-jose-pqc-hybrid-hpke-05"/>
    <author fullname="Tirumaleswar Reddy">
      <organization>Nokia</organization>
      <address>
        <postal>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Hannes Tschofenig">
      <organization/>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>
    <date year="2024" month="December" day="09"/>
    <area>Security</area>
    <workgroup>COSE</workgroup>
    <keyword>PQC</keyword>
    <keyword>COSE</keyword>
    <keyword>JOSE</keyword>
    <keyword>Hybrid</keyword>
    <keyword>HPKE</keyword>
    <abstract>
      <?line 63?>

<t>This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE.</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-reddy-cose-jose-pqc-hybrid/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        cose Working Group mailing list (<eref target="mailto:cose@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cose/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cose/"/>.
      </t>
    </note>
  </front>
  <middle>
    <?line 67?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The migration to Post-Quantum Cryptography (PQC) is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required data lifetimes. The traditional algorithms, such as RSA and elliptic curve, will fall to quantum cryptalanysis, while the post-quantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs.</t>
      <t>During the transition from traditional to post-quantum algorithms, there is a desire or a requirement for protocols that use both algorithm types. 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.</t>
      <t>HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. The specifications for the use of HPKE with JOSE and COSE are described in <xref target="I-D.ietf-jose-hpke-encrypt"/> and <xref target="I-D.ietf-cose-hpke"/>, respectively. HPKE can be extended to support PQ/T Hybrid KEM as defined in <xref target="I-D.connolly-cfrg-xwing-kem"/>. This specification defines PQ/T Hybrid KEM in HPKE for use with JOSE and COSE.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>This document makes use of the terms defined in <xref target="I-D.ietf-pquip-pqt-hybrid-terminology"/>. For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes:</t>
      <t>"Traditional Algorithm":  An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. In the context of JOSE, examples of traditional key exchange algorithms include Elliptic Curve Diffie-Hellman Ephemeral Static <xref target="RFC6090"/> <xref target="RFC8037"/>. In the context of COSE, examples of traditional key exchange algorithms include Ephemeral-Static (ES) DH and Static-Static (SS) DH <xref target="RFC9052"/>.</t>
      <t>"Post-Quantum Algorithm":  An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Examples of PQC key exchange algorithms include ML-KEM.</t>
      <t>"Post-Quantum Traditional (PQ/T) Hybrid Scheme":  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>"PQ/T Hybrid Key Encapsulation Mechanism":  A multi-algorithm KEM made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t>
    </section>
    <section anchor="construction">
      <name>Construction</name>
      <t>ML-KEM is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's ML-KEM public key. Three parameters sets for ML-KEMs are specified by <xref target="FIPS203"/>. In order of increasing security strength (and decreasing performance), these parameter sets
are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. X-Wing <xref target="I-D.connolly-cfrg-xwing-kem"/> uses a multi-algorithm scheme,
where one component algorithm is a post-quantum algorithm and another one is a traditional algorithm. X-Wing uses the final version of ML-KEM-768 and X25519. The Combiner function defined in Section 5.3 of <xref target="I-D.connolly-cfrg-xwing-kem"/> combines the output of a post-quantum KEM and a traditional KEM to generate a single shared secret.</t>
    </section>
    <section anchor="ciphersuite-registration">
      <name>Ciphersuite Registration</name>
      <t>This specification registers a number of PQ/T Hybrid KEMs for use with HPKE. A ciphersuite is thereby a combination of several algorithm configurations:</t>
      <ul spacing="normal">
        <li>
          <t>KEM algorithm (PQ KEM + Traditional Algorithm,  for example, MLKEM768 + X25519 defined as "X-Wing" in <xref target="I-D.connolly-cfrg-xwing-kem"/>)</t>
        </li>
        <li>
          <t>KDF algorithm</t>
        </li>
        <li>
          <t>AEAD algorithm</t>
        </li>
      </ul>
      <t>The "KEM", "KDF", and "AEAD" values are conceptually taken from the HPKE IANA registry <xref target="HPKE-IANA"/>. Hence, JOSE and COSE cannot use an algorithm combination that is not already available with HPKE.</t>
      <t>For readability the algorithm ciphersuites labels are built according to the following scheme:</t>
      <artwork><![CDATA[
   HPKE-<KEM>-<KDF>-<AEAD>
]]></artwork>
      <t>The HPKE PQ/T hybrid ciphersuites for JOSE and COSE are defined in <xref target="IANA"/>. Note that the PQ/T Hybrid KEM in HPKE is not an authenticated KEM. The HPKE Base mode can only be supported with the PQ/T Hybrid KEM.</t>
    </section>
    <section anchor="akp-key-for-x-wing">
      <name>AKP Key for X-Wing</name>
      <t>This section describes the required parameters for an "AKP" key type, as defined in <xref target="I-D.ietf-cose-dilithium"/>, and its use with the X-Wing algorithms, as defined in {#XWING}. An example JWK is also provided for illustration.</t>
      <section anchor="required-parameters">
        <name>Required Parameters</name>
        <t>A JSON Web Key (JWK) or COSE_Key with a key type ("kty") for use with the "X-Wing" algorithm includes the following parameters:</t>
        <ul spacing="normal">
          <li>
            <t>kty (Key Type)<br/>
The key type parameter <bcp14>MUST</bcp14> be present and set to "AKP".</t>
          </li>
          <li>
            <t>alg (Algorithm)<br/>
The algorithm parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> represent the X-Wing algorithm, as defined in {#XWING}. X-Wing algorithms are those registered in the "JSON Web Signature and Encryption Algorithms" and "COSE Algorithms" registries, derived from the KEM identifier in the HPKE IANA registry.</t>
          </li>
          <li>
            <t>pub (Public Key)<br/>
The public key parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> contain the X-Wing encapsulation key (pk) as defined in Section 5.2 of <xref target="I-D.connolly-cfrg-xwing-kem"/>. When represented as a JWK, this value <bcp14>MUST</bcp14> be base64url-encoded.</t>
          </li>
          <li>
            <t>priv (Private Key)<br/>
The private key parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> contain the X-Wing decapsulation key (sk) as defined in Section 5.2 of <xref target="I-D.connolly-cfrg-xwing-kem"/>. When represented as a JWK, this value <bcp14>MUST</bcp14> be base64url-encoded.</t>
          </li>
        </ul>
        <section anchor="example">
          <name>Example</name>
          <t>The following is an example JWK representation of an "AKP" key for the "HPKE-XWING-SHA256-AES256GCM" algorithm:</t>
          <artwork><![CDATA[
{
    "kty"  : "AKP", 
    "alg"  : "HPKE-XWING-SHA256-AES256GCM", 
    "pub"  : "4iNrNajCSz...tmrrIzQSQQO9lNA", 
    "priv" : "f5wrpOiP...rPpm7yY" 
}
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations in <xref target="I-D.connolly-cfrg-xwing-kem"/> and <xref target="I-D.ietf-jose-hpke-encrypt"/> are to be taken into account.</t>
      <t>The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. PQC KEMs used in the manner described in this document <bcp14>MUST</bcp14> explicitly be designed to be secure in the event that the public key is reused, such as achieving IND-CCA2 security. ML-KEM has such security properties.</t>
      <section anchor="post-quantum-security-for-multiple-recipients">
        <name>Post-Quantum Security for Multiple Recipients</name>
        <t>In HPKE JWE Key Encryption, when encrypting the Content Encryption Key (CEK) for multiple recipients, it is crucial to consider the security requirements of the message to safeguard against "Harvest Now, Decrypt Later" attack. For messages requiring post-quantum security, all recipients <bcp14>MUST</bcp14> use algorithms supporting post-quantum cryptographic methods, such as PQC KEMs or Hybrid PQ/T KEMs. Using traditional algorithms (e.g., ECDH-ES) for any recipient in these scenarios compromises the overall security of the message.</t>
      </section>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <section anchor="jose">
        <name>JOSE</name>
        <t>This document requests IANA to add new values to the "JSON Web Signature and Encryption Algorithms" registry.</t>
        <section anchor="XWING">
          <name>JOSE Algorithms Registry</name>
          <ul spacing="normal">
            <li>
              <t>Algorithm Name: HPKE-XWING-SHA256-AES256GCM</t>
            </li>
            <li>
              <t>Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the XWING Hybrid 
KEM, the HKDF-SHA256 KDF, and the AES-256-GCM AEAD.</t>
            </li>
            <li>
              <t>Algorithm Usage Location(s): "alg"</t>
            </li>
            <li>
              <t>JOSE Implementation Requirements: Optional</t>
            </li>
            <li>
              <t>Change Controller: IANA</t>
            </li>
            <li>
              <t>Specification Document(s): [[TBD: This RFC]]</t>
            </li>
            <li>
              <t>Algorithm Analysis Documents(s): TODO</t>
            </li>
            <li>
              <t>Algorithm Name: HPKE-XWING-SHA256-ChaCha20Poly1305</t>
            </li>
            <li>
              <t>Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the XWING Hybrid<br/>
KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.</t>
            </li>
            <li>
              <t>Algorithm Usage Location(s): "alg"</t>
            </li>
            <li>
              <t>JOSE Implementation Requirements: Optional</t>
            </li>
            <li>
              <t>Change Controller: IANA</t>
            </li>
            <li>
              <t>Specification Document(s): [[TBD: This RFC]]</t>
            </li>
            <li>
              <t>Algorithm Analysis Documents(s): TODO</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="cose">
        <name>COSE</name>
        <t>This document requests IANA to add new values to the 'COSE Algorithms' registry.</t>
        <section anchor="cose-algorithms-registry">
          <name>COSE Algorithms Registry</name>
          <ul spacing="normal">
            <li>
              <t>Name: HPKE-Base-XWING-SHA256-AES256GCM</t>
            </li>
            <li>
              <t>Value: TBD1</t>
            </li>
            <li>
              <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the XWING Hybrid KEM, the<br/>
HKDF-SHA256 KDF, and the AES-256-GCM AEAD.</t>
            </li>
            <li>
              <t>Capabilities: [kty]</t>
            </li>
            <li>
              <t>Change Controller: IANA</t>
            </li>
            <li>
              <t>Reference: [[TBD: This RFC]]</t>
            </li>
            <li>
              <t>Name: HPKE-Base-XWING-SHA256-ChaCha20Poly1305</t>
            </li>
            <li>
              <t>Value: TBD2</t>
            </li>
            <li>
              <t>Description: Cipher suite for COSE-HPKE in Base Mode that uses the XWING Hybrid    <br/>
KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.</t>
            </li>
            <li>
              <t>Capabilities: [kty]</t>
            </li>
            <li>
              <t>Change Controller: IANA</t>
            </li>
            <li>
              <t>Reference: [[TBD: This RFC]]</t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to Ilari Liusvaara and Orie Steele for the discussion and comments.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="I-D.ietf-cose-dilithium">
          <front>
            <title>ML-DSA for JOSE and COSE</title>
            <author fullname="Michael Prorock" initials="M." surname="Prorock">
              <organization>mesur.io</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization>Transmute</organization>
            </author>
            <author fullname="Rafael Misoczki" initials="R." surname="Misoczki">
              <organization>Google</organization>
            </author>
            <author fullname="Michael Osborne" initials="M." surname="Osborne">
              <organization>IBM</organization>
            </author>
            <author fullname="Christine Cloostermans" initials="C." surname="Cloostermans">
              <organization>NXP</organization>
            </author>
            <date day="20" month="October" year="2024"/>
            <abstract>
              <t>   This document describes JSON Object Signing and Encryption (JOSE) and
   CBOR Object Signing and Encryption (COSE) serializations for Module-
   Lattice-Based Digital Signature Standard (ML-DSA), which was derived
   from Dilithium, a Post-Quantum Cryptography (PQC) based digital
   signature scheme.

   This document does not define any new cryptography, only
   seralizations of existing cryptographic systems described in
   [FIPS-204].

   Note to RFC Editor: This document should not proceed to AUTH48 until
   NIST completes paramater tuning and selection as a part of the PQC
   (https://csrc.nist.gov/projects/post-quantum-cryptography)
   standardization process.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-dilithium-04"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="FIPS203" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf">
          <front>
            <title>Module-Lattice-based Key-Encapsulation Mechanism Standard</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="HPKE-IANA" target="https://www.iana.org/assignments/hpke/hpke.xhtml">
          <front>
            <title>Hybrid Public Key Encryption (HPKE) IANA Registry</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-jose-hpke-encrypt">
          <front>
            <title>Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)</title>
            <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
              <organization>Nokia</organization>
            </author>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
         </author>
            <author fullname="Aritra Banerjee" initials="A." surname="Banerjee">
              <organization>Nokia</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization>Transmute</organization>
            </author>
            <author fullname="Michael B. Jones" initials="M. B." surname="Jones">
              <organization>Self-Issued Consulting</organization>
            </author>
            <date day="5" month="December" year="2024"/>
            <abstract>
              <t>   This specification defines Hybrid Public Key Encryption (HPKE) for
   use with JSON Object Signing and Encryption (JOSE).  HPKE offers a
   variant of public key encryption of arbitrary-sized plaintexts for a
   recipient public key.

   HPKE works for any combination of an asymmetric key encapsulation
   mechanism (KEM), key derivation function (KDF), and authenticated
   encryption with additional data (AEAD) function.  Authentication for
   HPKE in JOSE is provided by JOSE-native security mechanisms or by one
   of the authenticated variants of HPKE.

   This document defines the use of the HPKE with JOSE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-jose-hpke-encrypt-03"/>
        </reference>
        <reference anchor="I-D.ietf-cose-hpke">
          <front>
            <title>Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)</title>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization>Transmute</organization>
            </author>
            <author fullname="Ajitomi, Daisuke" initials="A." surname="Daisuke">
              <organization>bibital</organization>
            </author>
            <author fullname="Laurence Lundblade" initials="L." surname="Lundblade">
              <organization>Security Theory LLC</organization>
            </author>
            <date day="12" month="July" year="2024"/>
            <abstract>
              <t>   This specification defines hybrid public-key encryption (HPKE) for
   use with CBOR Object Signing and Encryption (COSE).  HPKE offers a
   variant of public-key encryption of arbitrary-sized plaintexts for a
   recipient public key.

   HPKE works for any combination of an asymmetric key encapsulation
   mechanism (KEM), key derivation function (KDF), and authenticated
   encryption with additional data (AEAD) function.  Authentication for
   HPKE in COSE is provided by COSE-native security mechanisms or by one
   of the authenticated variants of HPKE.

   This document defines the use of the HPKE with COSE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-hpke-09"/>
        </reference>
        <reference anchor="I-D.connolly-cfrg-xwing-kem">
          <front>
            <title>X-Wing: general-purpose hybrid post-quantum KEM</title>
            <author fullname="Deirdre Connolly" initials="D." surname="Connolly">
              <organization>SandboxAQ</organization>
            </author>
            <author fullname="Peter Schwabe" initials="P." surname="Schwabe">
              <organization>MPI-SP &amp; Radboud University</organization>
            </author>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <date day="21" month="October" year="2024"/>
            <abstract>
              <t>   This memo defines X-Wing, a general-purpose post-quantum/traditional
   hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML-
   KEM-768.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-connolly-cfrg-xwing-kem-06"/>
        </reference>
        <reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="Florence D" initials="F." surname="D">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Michael P" initials="M." surname="P">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Britta Hale" initials="B." surname="Hale">
              <organization>Naval Postgraduate School</organization>
            </author>
            <date day="10" month="September" year="2024"/>
            <abstract>
              <t>   One aspect of the transition to post-quantum algorithms in
   cryptographic protocols is the development of hybrid schemes that
   incorporate both post-quantum and traditional asymmetric algorithms.
   This document defines terminology for such schemes.  It is intended
   to be used as a reference and, hopefully, to ensure consistency and
   clarity across different protocols, standards, and organisations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-04"/>
        </reference>
        <reference anchor="RFC6090">
          <front>
            <title>Fundamental Elliptic Curve Cryptography Algorithms</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="K. Igoe" initials="K." surname="Igoe"/>
            <author fullname="M. Salter" initials="M." surname="Salter"/>
            <date month="February" year="2011"/>
            <abstract>
              <t>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6090"/>
          <seriesInfo name="DOI" value="10.17487/RFC6090"/>
        </reference>
        <reference anchor="RFC8037">
          <front>
            <title>CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)</title>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8037"/>
          <seriesInfo name="DOI" value="10.17487/RFC8037"/>
        </reference>
        <reference anchor="RFC9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA91abXPbNrb+zl+BVT7U3jXl2EnaRtPbriI5tfNiO5GzaaeT
2YFISMKaIlkAtKJm0t9yf8v9ZfucA5AiZblJu7dzZ24mY5EgCJz385wDxnEc
Oe0yNRC9y1eHV+J0PTU6Fc9PXg7E6eXzE7HSbiGeXUxODkf404vkdGrUzWdP
T6RT88KsB8K6NIrSIsnlErulRs5cbFSaruOksCr+F/0pf07iBS8ZL8prFdlq
utTW6iJ36xJvnZ1cPY3yajlVZhClWHoQJUVuVW4rOxDOVCoCaQ8iaZQEiROV
VEa7dS9aFeZ6boqqxKgn7FqtMZgOIhGLy1cj+qEH9Pss/Hrm+AqsRdGNyivs
KES9EhHew70nrvcWm+h8Lr6nxzS+lDoL0/6ulZv1CzOncWmSBcYXzpV2cHhI
02hI36h+Pe2QBg6nplhZdUgLHNKLUWSdzNN/yqzIseNa2ajUA/GTK5IDYQvj
jJpZXK2X4cIZnbgDkRTLpcodRqCApSxLkPkuimTlFoUhEWBtIWZVlnntXGlT
LWWm7Eoa8ZqUxBNAl8z1L9JBIQNxXlxryeMJZDwQT2Q+B2FG8ZhRc571XJpc
OnkdZhZV7sgazvI0vKyClK6LPHXa/H1O931Q3LtN16nMc2XFlU0WxUzlen6b
rA1B3Q2/V2Yp83VnywUv13fNctj8fT9XrhdFIsoLvOGglEEU6Xy2uRNY5OnZ
5eT4/gO/iahd6GWRVpmKX0jndKLiqbQKzqHW8UmeyNJWGdMoXqoEW2u7FBNS
pzRpL6wjzVy5gagtI7/Jympq+5jr+vPi5pAuaOSQ9j88P5tc9emqD1L6ZTrz
q7BjiJnMLKmCbDc+G54PA62N0sM/SA/qwPMOK8GxL6tpphNiQYAFsy6Z/j1a
c59fgnXMQZNZ72ZgtVr1tcylN2l48jxnQzwk9+Y//fcLt8xuE+5HojiOhZxi
A5m4KLpaaEsmXNEioqhcpske3EIJigMIAAkTWMyEFJ0A5RnYqYM9RK99ofMu
z/FunmEGmIqYZvwyTbwTUCRHkL44c8KWKtEzHWirnM6CfRJp0wLvgKNU04jM
+NXLwrr4VSVzVy3FiHYtsEe5WIs9hKd9ITOEUWy2hBPDuZVB7BSuENKKrUh8
wESBnyAWp9472rZLZcSiXeo0zSDse3BIZ2C9LD8StMKzmkls8ynyoJcq1z9X
SoSNoSmHuE8bL4tUmVykeq4duE3ab/Ns6USuQLMy/GpHNA3bAv7Ij0si5edA
Sus5gj6HijUlAuu8eEpTOJU4Mi3JyqMVjPq50iQ/Hs30TDm9RCAQV3fujlha
JQuS9uvJkKWoskzDNBKBHHOjSOhZRrab0bY1ecyrzBB4rMYaq4XO1G8yMZMJ
7CVPlHESdraG8cPMvRXlEGO2pgyDSLRQFI4Sy8G9zOBkeBG5slIYqvLrvFjl
4qbKcmXkFObnND1YINasSFDEgS1mjm80FlDkUqxu6zWykDcKMqcLTK1mM51o
8jpsi6QKIkhmxKtByCNfFElGHp7UKobbZ2sSEKKhTK4t79ndSkyruYUpjsOK
Xvy5ZfmLmSmWHXWQPnfL7YDeJU6wi0iVhXYR2HAdVM3xgtRP9lAkRRaYrKzy
7tgsxckcphD8CTBBqPcUKubK+50lMirLaqgyp8FPd1ZLm1bTFJmrorKwSxIA
tDXVec2tUQhIzkcRup8XYBMuAzJvdEqzbMAwQgF+CI3ABgubQtpAADTTO/my
xC1YbO0NUQA+XKucAxLulgXSlyS/mK7bYt6Wats/+4AcjOuKGbMuxY00sDUO
KKUPlMz8JlBS7DVTjQ3MOrb6F+xXZmTLCEOWdUBaSXTJ1uTXIAF67wuBMwmW
WHss6QkLdyFmE8zY9aH1xOgptkNM+fDhu7N4zGjKI0tKNXGg8uNHfrM9J6nn
fPxI4ZWooFyfgSreM5GwVQUdOwUv5Mhiq7IE4tqOvhQiUjVDXmoTgjCcFwhN
cTIz8/j9CpqF3JYfPxLX0E2H7fD+rcDOOYqoIamQRHYlH4rloyKHsXgJ0pMx
rcfKtj60k8oI/VpAljeTq96B/xXnF3z9+uTVm7PXJ2O6npwOX7xoLqIwY3J6
8ebFeHO1eXN08fLlyfnYv4xR0RmKei+HP+IJUdW7uLw6uzgfvuj5LNBO7aRQ
yHiqONma0iiyW2mjjpafjC7/57+PHkLIf3n9dHR8dPQYqvU3Xx999RA3q4XK
/W5FDgf0tzCodQQQrCTlcnYoIAPKTYgjUJ9dUOykeILQ9NefSDLvBuKbaVIe
Pfw2DBDDncFaZp1BltntkVsveyHuGNqxTSPNzviWpLv0Dn/s3Ndybw1+8x0h
KREfff3dt9E2zlrKaxhjcEGO0cDSu6ycXalEwC3x19WVHM3WsP5iviZ7f1qn
8cog7GBhXrS134HQHK8WKiuRz4MdyGnGJpFqBEbVDlKUYVphL8cktyp8NlIW
4L131cohw3pqbyDEENpHsbRUVCfdtabwMB5+ycAPIAVJGthGW/bWA8HOBeyh
VQZIoWGgsFYBfmWdnLpYYfcciMWojOPzJr2DYKQCsL5ESjrbCemw+ntJWdVL
ssXqXVlJ50lWQYYnNVUjpmqskeNVfApiUSmJkxI0ADxkVKTQLCgZjvXl/cf3
2cvo5uv7D74ind6mbPSfUVbvHYe9904m+2J8yp7sh5onE//EE/T4/qNjIghK
7yDWP6B1xgeURFWmkXvTYIecj0H0HCnNugbbeEDQpFAk5MpxwrRiBYHSbwse
1Y/74qQlIQDpT0rm5YsYmaC/zV/bwvcobezXeWOSkCiZbY9X4g2Llp9RVCSO
nMiUtB5Y7EAUHlvtxl+sl84CPHknlGbaP6802001ZcKlhCyqku0Kvg7fWRam
TTZn4o34drD4v8cOJ9ym+IwiryP/Dl6OS+hd7FE5pGKsHCN9A3an+1umt2wq
UgZJQFIGFVMuHQXMIhgekpgFBCE7CYWAAh7jINmGVd4cPcIMY1/YYDxbmMso
xGJpJNyBDNaqgNL8ZF9W1eUsQ8cPH0LzI3g+cARiIjQBGzWQWAe1QiwqnwOm
7JFMU9XMKJXhlgrKln1OybZFBlNBXbxARfzo6Pigvv7qy699Sg/3R/ePH/bF
D/FbWvZTeIvSGOlltyscRN5Q/rALoF6iKvYTJlMTy7SQkpBBMOEG8g8IesMq
r/vD8aNHR489Qh5xAUFZCGViCy5yIp4oP/So/4CW+aQ0fDUSqEANV1bON086
TLIzEXsdfmgUZjdXVGIimUlBikWWtqgyQY4lZbuASDUiurEV5cnQMZJ1p+EW
/DU8wZcbvtnro2MHDNsuCiZc3EewSFobaeurQtisDJw2PRiLkG7aSqHkNdPz
ytNFsCHuBhGKqzzyN7ETTxwIpiikPLJWTCYF/i2or9ETckHPW0Dvc0qEfaJk
/HRDCe6HJ8Nxa4BBfQ/7EejG3Bph07QeSrasUt6RsUmiSldJbpMA19VVNt7n
0oJ7eib09EBa0z0kZz9FAQXOurUXSiPqEpAmZN6R50bgdS6liTJDCEihkhtq
exOq2ygQ0PMp4yCZ+qbFmilrLbpRrxV4W2Wer2mlUUbLJEEw4shXeL+CQIsV
ByT2b2j1119/pdYi8/UNJPYt/o6f4i/J6lt+zNJkabDNeRjb3Zo0vasEbSHi
WmjnhVNeAETRXSVdLZyc+7NUvCUMBSnZi4aeJ0Ci3E7jgpRLGoIkvhLF7KaP
sLUNCfaeGD6/5GxLxIcIVPufqiOJr65st03WSg8hNfWwVo/BCrVLDm4VvX/p
VtYp6XKhqyWV19wGcnbju7RXoKfd0dla894Pb8/Ov4dAAd+Ck4lnb59znM1s
EVommMwt2iyr6hhDGfrePYSdwM1lw00UDcWzycW5eKumLJk9LLhPaIJU+k8a
YQJlw6nY6127dW+/G3yIgcajW9nCYza7ZYobaXKQwXpij7a6wvr7gg4X6hKd
d9wkRa47oW9Uw5bzEvXwlCNjZ3306YAoJgLEXhOWNituCPvtJXnMqHpol3bu
Vs4tPfpSfgEraOK6f4eF1kh/ouc5NRZ9Z7LVd28YsT0f09jb2qMhWnF/E0hE
E1Zvghr7WEr+BPhi6n1vh7ogO0AjxPnm0GMjvA1m+hzpUSEkw15BIqoDcWmd
vfJ6f0uOm/R9/Dnpuy/eIlRsdOVziyS3OPA1NYf+hk4qZL98WJmMOmGIImmf
eYbIwLTh5uAW12Hwj7MNxLfNtv2/Z1v4kBCKLx/wNw5KEaUbY5qtGvzQiYF1
l7LHWYVdIZ6cDo8ffRkPTyb4+X70shUYQhb6wEdcHE+EGPjlDoQfxFw/+Fsr
1pNhm37yQ31uzuW/RpNf+v2+Wxpz9suryatXF4+z8+FmNnTao9mzRytTXuhL
zDWX5fKr9Y89EX30GfCeqM/OubaBBwVc5GXVwPuk8/Bz0Myt1uvO9mzT/vMY
hZs6lN2r3PUDCW2QaeuSuoksix3te7soqiylVduzpVjJtU/QMllQqe8Dds8v
0aPEgmKFTrg3HftQ42Br4dMnRy5AkoKCn+0Wj7e69HcW+XSIVjftqRvAOLey
G7aWdGJtur3ubueUjV69LxGttPP4gM5D5vl2ByOsSMcKboNPWnEOqxpFm2/O
vryAiPmz83E8Gg2PG1Po19XlgjqoNL8xkiBABGhOxd2zxMbOuOasD1Re11Wr
haueBYz07O3J1kn0AXd0m9OHUPKOqA0FplpZhJP76OS5T9zNuU1THNu66Zig
ig/1dG3bvGbDTOtAydaaXSpr5ZxN1sqZmleo7psOUe9UGtiUAxBcHYixYprE
Cyrce6F95JuiYRUbtmCo0K7CahIOuGO9Id2rnPF36+TJY8Jbi2y3HJCZ09bh
ZmN0oKc+DicoSWN98cZ3FXYfz+6p/rx/IE5G49OYunUeKa5bTQlvcaDTJiqX
RhfebZGqdV0IF1yVZRtxdyXMzRbO292oBADCcJvNiz/f2Wphk0ihA+tfpmCS
piJXq7o2CvXC78QjDXjw6eRZF5k0n0Y08IiybfNcnPtPWu4O8J3ZY3b50n96
48tp4cvcuhaJfSGR+yrhJVUJ9RmnFy7vUqsVyYC/FWA4hAoo7E6Vpofo9ACk
xEQSiOGSs98h6Q0b/YvCl+17dn/gE1fkP6ESZ92z3tctzxmIi9KbECaPfCAk
tzXIGcqE71FiMen0BcZBm7zTTz9dPRkP/OnZ66ejd+86pA3p7NniUf2O5Zeu
LsYXn6cE0IT/x/cvi2x99OD+oz9VF5+njG2S/h9pBM4z+uNe+8VWSfDFtmOO
7nLMKPqraJsAaesuZ8TMf9C2oPnJ+EjQ/W/bweh320FjAwzVfodXgpaRLJvv
PKALoMp3PHyHJvHoNX3NQB2dXar7pGBuOUhHPsd/hnj8F2HiP/CVP0FO98Qw
oY9tMpXO2ayjD4PQtVTpf/X4Y7beR7JsmV+zyZ5lyH3iha7sjURNxTRfoHwV
E6dUpppqgk4JK/74tf5whNfvR/8GcPiKkbUrAAA=

-->

</rfc>
