Hello, Thank you very much for the time put into preparing this draft for publication. I am attaching an updating XML file with some changes. This is my first time taking part in the AUTH48 process so apologies for any mistakes in engaging.
In response to the RFC Editor Comments: 1. Done 2. I have updated this in the new XML document to a preferred version, I hope this is clearer. 3. This is fine, I've updated this. 4. This is fine. 5a. The word security is not needed in the bracketed text, I have removed it. I've also added a reference for IND-CPA and IND-CPA security. 5b. These expansions are fine. 6. I am happy for you to remove the strong element. I have not updated this as I'm not an XML expert and I didn't want to mess up the formatting. 7. I believe that the draft conforms to the inclusive language guidance. As it is a terminology document we have tried to use plain language as much as possible, while also ensuring that the nuances of the different terms are captured. We do not believe that the word "traditional" here carries any value judgement, and it is defined in the document to ensure that this intention is clear. In addition, the use of the word "traditional" to describe this mathematical concept is now well established and changing it in this document would lead to confusion and significantly reduce the effectiveness of the document. Other than the changes in the XML document and the removal of the strong element I am happy with the content, but I will appreciate the checks from my co-authors as well. Flo ________________________________________ From: [email protected] <[email protected]> Sent: Friday, May 30, 2025 01:42 To: Flo D <[email protected]>; Michael P1 <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: AUTH48: RFC-to-be 9794 <draft-ietf-pquip-pqt-hybrid-terminology-06> for your review Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [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). --> 3) <!-- [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. --> 4) <!-- [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>. --> 5) <!-- [rfced] Abbreviations: a) Regarding IND-CPA and IND-CCA in Section 2: Current: The standard security property for a PKE scheme is indistinguishability under chosen-plaintext attack (IND-CPA). IND-CPA security is not sufficient for secure communication in the presence of an active attacker. Therefore, in general, PKE schemes are not appropriate for use on the Internet, and KEMs, which provide indistiguishability under chosen-ciphertext attack (IND-CCA security), are required. - Is the word 'security' needed in 'IND-CCA security'? - We note that RFC 9771 includes references for IND-CCA and IND-CCA2. Would you like to add references to this document, or will this be sufficiently clear to the 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 items below. Please review each expansion in the document carefully to 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) --> 6) <!-- [rfced] For readability we have formatted the lists in this document with a line break between each term and its definition. We suggest removing the <strong> element (which yields bold font in the HTML and PDF, and yields asterisks in the TXT); please let us know if removing <strong> is acceptable. --> 7) <!-- [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 more precise language, which is helpful for readers. In addition, please consider whether "traditional" should be updated throughout this document for clarity. While the 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. --> Thank you. RFC Editor/kf/ar On May 29, 2025, [email protected] wrote: *****IMPORTANT***** Updated 2025/05/29 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9794.xml https://www.rfc-editor.org/authors/rfc9794.html https://www.rfc-editor.org/authors/rfc9794.pdf https://www.rfc-editor.org/authors/rfc9794.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9794-diff.html https://www.rfc-editor.org/authors/rfc9794-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9794-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9794 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9794 (draft-ietf-pquip-pqt-hybrid-terminology-06) Title : Terminology for Post-Quantum Traditional Hybrid Schemes Author(s) : F. Driscoll, M. Parsons, B. Hale WG Chair(s) : Sofia Celi, Paul E. Hoffman Area Director(s) : Deb Cooley, Paul Wouters
<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <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" updates="" obsoletes="" xml:lang="en"> <front> <title abbrev="PQ/T Hybrid Terminology">Terminology for Post-Quantum Traditional Hybrid Schemes</title> <seriesInfo name="RFC" value="9794"/> <author fullname="Florence Driscoll" initials="F." surname="Driscoll"> <organization>UK National Cyber Security Centre</organization> <address> <email>[email protected]</email> </address> </author> <author fullname="Michael Parsons" initials="M." surname="Parsons"> <organization>UK National Cyber Security Centre</organization> <address> <email>[email protected]</email> </address> </author> <author fullname="Britta Hale" initials="B." surname="Hale"> <organization>Naval Postgraduate School</organization> <address> <email>[email protected]</email> </address> </author> <date year="2025" month="June"/> <area>SEC</area> <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>cryptography</keyword> <keyword>quantum-safe</keyword> <keyword>pqc</keyword> <keyword>composite</keyword> <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> <middle> <section anchor="introduction"> <name>Introduction</name> <t>The mathematical problems of integer factorisation and discrete logarithms over finite fields or elliptic curves underpin most of the asymmetric algorithms used for key establishment and digital signatures on the Internet. These problems, and hence the algorithms based on them, will be vulnerable to attacks using Shor's Algorithm on a sufficiently large general-purpose quantum computer, known as a Cryptographically Relevant Quantum Computer (CRQC). Current predictions vary on when, or if, such a device will exist. However, it is necessary to anticipate and prepare to defend against such a development. Data encrypted today (in 2025) with an algorithm vulnerable to a quantum computer can be stored for decryption by a future attacker with a CRQC. Signing algorithms in products that are expected to be in use for many years, and that cannot be updated or replaced, are also at risk if a CRQC is developed during the operational lifetime of that product.</t> <t>Ongoing responses to the potential development of a CRQC include modifying established (or standardised) protocols to use asymmetric algorithms that are designed to be secure against quantum computers as well as today's classical computers. These algorithms are called "post-quantum", while algorithms based on integer factorisation, finite-field discrete logarithms, or elliptic-curve discrete logarithms are called "traditional cryptographic algorithms". In this document, "traditional algorithm" is also used to refer to this class of algorithms.</t> <t>At the time of publication, the term "post-quantum" is generally used to describe cryptographic algorithms that are designed to be secure against an adversary with access to a CRQC. Post-quantum algorithms can also be referred to as "quantum-resistant" or "quantum-safe" algorithms. There are merits to the different terms. For example, some prefer to use the terms quantum-resistant or quantum-safe to explicitly indicate that these algorithms are designed to be secure against quantum computers. Others disagree and prefer to use the term post-quantum, in case of compromises against such algorithms that could make the terms quantum-resistant or quantum-safe misleading. Similarly, some prefer to refer specifically to Shor's Algorithm or to the mathematical problem that is being used to prevent attacks. Post-Quantum Cryptography (PQC) is commonly used amongst the cryptography community, and so it will be used throughout this document. Similarly, the term "traditional algorithm" will be used throughout the document as, at the time of publication, it is widely used in the community, though other terms, including classical, pre-quantum, or quantum-vulnerable, are preferred by some.</t> <!-- [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>To mitigate risks, there may be a requirement for protocols that use both algorithm types, either during the transition from traditional to post-quantum algorithms, or as a genearl solution. When the risk of deploying new algorithms is above the accepted threshold for their use case, a designer may combine a post-quantum algorithm with a traditional algorithm, with the goal of adding protection against an attacker with a CRQC to the security properties provided by the traditional algorithm. They may also implement a post-quantum algorithm alongside a traditional algorithm for ease of migration from an ecosystem where only traditional algorithms are implemented and used, to one that only uses post-quantum algorithms. Examples of solutions that could use both types of algorithm include, but are not limited to, <xref target="RFC9370"/>, <xref target="I-D.ietf-tls-hybrid-design"/>, <xref target="I-D.ietf-lamps-pq-composite-kem"/>, and <xref target="RFC9763"/>.</t> <t>Schemes that combine post-quantum and traditional algorithms for key establishment or digital signatures are often called "hybrids". For example:</t> <ul spacing="normal"> <li> <!-- 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> </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 (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, in order to add clarity and consistency across different protocols, standards, and organisations. Additionally, this document aims to reduce misunderstandings about the use of the word "hybrid" and to define a shared language for different types of post-quantum and traditional hybrid constructions.</t> <!-- 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, Elliptic Curve Diffie-Hellman (ECDH), Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) (formerly known as Kyber), and Module-Lattice-Based Digital Signature Algorithm (ML-DSA) (formerly known as Dilithium). The expression "cryptographic scheme" is used to refer to a construction that uses a cryptographic algorithm or a group of cryptographic algorithms to achieve a particular cryptographic outcome, e.g., key agreement. A cryptographic scheme may be made up of a number of functions. For example, a Key Encapsulation Mechanism (KEM) is a cryptographic scheme consisting of three functions: Key Generation, Encapsulation, and Decapsulation. A cryptographic protocol incorporates one or more cryptographic schemes. For example, TLS <xref target="RFC8446"/> 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 newline="true"> <dt><strong>Traditional 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> <t>A related mathematical problem is one that can be solved by solving the integer factorisation, finite field discrete logarithm, or elliptic curve discrete logarithm problem.</t> <t>Where there is little risk of confusion, traditional asymmetric cryptographic algorithms can also be referred to as "traditional algorithms" for brevity. Traditional algorithms can also be called "classical" or "conventional" algorithms.</t> </dd> <dt><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> <t>Where there is little risk of confusion, post-quantum asymmetric cryptographic algorithms can also be referred to as "post-quantum algorithms" for brevity. Post-quantum algorithms can also be called "quantum-resistant" or "quantum-safe" algorithms.</t> <t>As with all cryptography, it always remains the case that attacks, either quantum or classical, may be found against post-quantum algorithms. Therefore, it should not be assumed that an algorithm will not be compromised just because it is designed to provide post-quantum cryptography. Should an attack be found against a post-quantum algorithm, it is commonly still referred to as a "post-quantum algorithm", as they were designed to protect against an adversary with access to a CRQC, and the labels are referring to the designed or desired properties.</t> </dd> </dl> <t>There may be asymmetric cryptographic constructions that are neither post-quantum nor asymmetric traditional algorithms according to the definitions above. These are out of scope of this document.</t> <dl newline="true"> <dt><strong>Component asymmetric algorithm</strong>:</dt> <dd> <t>Each cryptographic algorithm that forms part of a cryptographic 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 asymmetric algorithms can also be referred to as "component algorithms" for brevity, as is done in the following definitions.</t> </dd> <dt><strong>Single-algorithm scheme</strong>:</dt> <dd> <t>A cryptographic scheme with one component algorithm.</t> <t>A single-algorithm scheme could use either a traditional algorithm or a post-quantum algorithm.</t> </dd> <dt><strong>Multi-algorithm scheme</strong>:</dt> <dd> <t>A cryptographic scheme that incorporates more than one component algorithm, where the component algorithms have the same cryptographic purpose as each other and as the multi-algorithm scheme.</t> <t>For example, a multi-algorithm signature scheme may include multiple signature algorithms, or a multi-algorithm Public Key Encryption (PKE) scheme may include multiple PKE algorithms. Component algorithms could be all traditional, all post-quantum, or a mixture of the two.</t> </dd> <dt><strong>Post-Quantum Traditional (PQ/T) hybrid scheme</strong>:</dt> <dd> <t>A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm.</t> <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. 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 Key Encapsulation Mechanism (KEM)</strong>:</dt> <dd> <t>A multi-algorithm KEM made up of two or more component algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm. The component algorithms could be KEMs or other key establishment algorithms.</t> </dd> <dt><strong>PQ/T hybrid Public Key Encryption (PKE)</strong>:</dt> <dd> <t>A multi-algorithm PKE scheme made up of two or more component algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm. The component algorithms could be PKE algorithms or other key establishment algorithms.</t> <t>The standard security property for a PKE scheme is indistinguishability under chosen-plaintext attack (IND-CPA) <xref target="BDPR"/>. IND-CPA security is not sufficient for secure communication in the presence of an active attacker. Therefore, in general, PKE schemes are not appropriate for use on the Internet, and KEMs, which provide indistinguishability under chosen-ciphertext attack (IND-CCA) <xref target="BDPR"/>, are required.</t> </dd> <dt><strong>PQ/T hybrid digital signature</strong>:</dt> <dd> <t>A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t> <t>Note that there are many possible ways of constructing a PQ/T hybrid digital signature. Examples include parallel signatures, composite signatures, or nested signatures.</t> </dd> </dl> <t>PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures are all examples of PQ/T hybrid schemes.</t> <dl newline="true"> <dt><strong>Post-Quantum Traditional (PQ/T) 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, and where the resulting composite scheme is exposed as a singular interface of the same type as the component algorithms.</t> <t>A PQ/T hybrid composite can be referred to as a "PQ/T composite". An example of a PQ/T hybrid composite is a single KEM algorithm comprised of a PQ KEM component and a traditional KEM component, for which the result presents as a KEM output.</t> </dd> <dt><strong>PQ/T hybrid combiner</strong>:</dt> <dd> <t>A method that takes two or more component algorithms and combines them to form a PQ/T hybrid scheme.</t> </dd> <dt><strong>PQ/PQ hybrid scheme</strong>:</dt> <dd> <t>A multi-algorithm scheme where all components are post-quantum algorithms.</t> <t>The definitions for types of PQ/T hybrid schemes can be adapted to define types of PQ/PQ hybrid schemes, which are multi-algorithm schemes where all component algorithms are post-quantum algorithms. These are designed to mitigate risks when the two post-quantum algorithms are based on different mathematical problems. Some prefer to refer to these as PQ/PQ multi-algorithm schemes, and reserve the term "hybrid" for PQ/T hybrids.</t> </dd> </dl> <t>In cases where there is little chance of confusion between other types of hybrid cryptography (e.g., as defined in <xref target="RFC4949"/>) and where the component algorithms of a multi-algorithm scheme could be either post-quantum or traditional, it may be appropriate to use the phrase "hybrid scheme" without PQ/T or PQ/PQ preceding it.</t> <dl newline="true"> <dt><strong>Component scheme</strong>:</dt> <dd> <t>Each cryptographic scheme that makes up a PQ/T hybrid scheme or PQ/T hybrid protocol.</t> </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 newline="true"> <dt><strong>Cryptographic element</strong>:</dt> <dd> <t>Any data type (private or public) that contains an input or output value for a cryptographic algorithm or for a function making up a cryptographic algorithm.</t> <t>Types of cryptographic elements include public keys, private keys, plaintexts, ciphertexts, shared secrets, and signature values.</t> </dd> <dt><strong>Component cryptographic element</strong>:</dt> <dd> <t>A cryptographic element of a component algorithm in a multi-algorithm scheme.</t> <t>For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client's keyshare contains two component public keys: one for a post-quantum algorithm and one for a traditional algorithm.</t> </dd> <dt><strong>Composite cryptographic element</strong>:</dt> <dd> <t>A cryptographic element that incorporates multiple component cryptographic elements of the same type for use in a multi-algorithm scheme, such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements.</t> <t>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> <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> <dd> <t>A method that takes two or more component cryptographic elements of the same type and combines them to form a composite cryptographic element.</t> <t>A cryptographic element combiner could be concatenation, such as where two component public keys are concatenated to form a composite public key as in <xref target="I-D.ietf-tls-hybrid-design"/>, or something more involved such as the dualPRF defined in <xref target="BINDEL"/>.</t> </dd> </dl> </section> <section anchor="protocols"> <name>Protocols</name> <t>This section introduces terminology related to the use of post-quantum and traditional algorithms together in protocols.</t> <dl newline="true"> <dt><strong>PQ/T hybrid protocol</strong>:</dt> <dd> <t>A protocol that uses two or more component algorithms providing the same cryptographic functionality, where at least one is a post-quantum algorithm and at least one is a traditional algorithm.</t> <t>For example, a PQ/T hybrid protocol providing confidentiality could use a PQ/T hybrid KEM such as in <xref target="I-D.ietf-tls-hybrid-design"/>, or it could combine the output of a post-quantum KEM and a traditional KEM at the protocol level to generate a single shared secret, such as in <xref target="RFC9370"/>. Similarly, a PQ/T hybrid protocol providing authentication could use a PQ/T hybrid digital signature scheme, or it could include both post-quantum and traditional single-algorithm digital signature schemes.</t> <t>A protocol that can negotiate the use of either a traditional algorithm or a post-quantum algorithm, but not the use of both types of algorithm, is not a PQ/T hybrid protocol. Protocols that use two or more component algorithms but with different cryptographic functionalities, for example, a post-quantum KEM and a Pre-Shared Key (PSK), are also not PQ/T hybrid protocols.</t> </dd> <dt><strong>PQ/T hybrid protocol with 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> <t>For example, a PQ/T hybrid protocol with composite key establishment could include a single PQ/T hybrid KEM, such as in <xref target="I-D.ietf-tls-hybrid-design"/>.</t> </dd> <dt><strong>PQ/T hybrid protocol with composite 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> <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> </dd> <dt><strong>PQ/T hybrid protocol with 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> <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 newline="true"> <dt><strong>PQ/T hybrid protocol with non-composite key establishment</strong>:</dt> <dd> <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve key establishment, where at least one uses a post-quantum algorithm and at least one uses a traditional algorithm, in such a way that the formats of the component cryptographic elements are the same as when they are used as a part of a single-algorithm scheme.</t> <t>For example, a PQ/T hybrid protocol with non-composite key establishment could include a traditional key exchange scheme and a post-quantum KEM. A construction like this for the Internet Key Exchange Protocol Version 2 (IKEv2) is enabled by <xref target="RFC9370"/>.</t> </dd> <dt><strong>PQ/T hybrid protocol with non-composite authentication</strong>:</dt> <dd> <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve authentication, where at least one uses a post-quantum algorithm and at least one uses a traditional algorithm, in such a way that the formats of the component cryptographic elements are the same as when they are used as part of a single-algorithm scheme.</t> <t>For example, a PQ/T hybrid protocol with non-composite authentication could use a PQ/T parallel PKI with one traditional certificate chain and one post-quantum certificate chain.</t> </dd> </dl> <t>In a PQ/T hybrid protocol with a non-composite construction, changes are primarily made to the protocol fields, the message flow, or both, while changes to cryptographic elements are minimised. In implementations, most changes are likely to be made to the protocol libraries, with minimal changes to the cryptographic libraries.</t> <t>It is possible for a PQ/T hybrid protocol to be designed with both composite and non-composite constructions. For example, a protocol that offers both confidentiality and authentication could have composite key agreement and non-composite authentication. Similarly, it is possible for a PQ/T hybrid protocol to achieve certain cryptographic outcomes in a non-hybrid manner. For example, <xref target="I-D.ietf-tls-hybrid-design"/> describes a PQ/T hybrid protocol with composite key agreement, but with single-algorithm authentication.</t> <t>PQ/T hybrid protocols may not specify non-composite aspects, but can choose to do so for clarity, in particular, if including both composite and non-composite aspects.</t> <dl newline="true"> <dt><strong>PQ/T 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>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> <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> <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 hybrid non-composite 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, a designer or implementer will think about why they are using a PQ/T hybrid scheme. For example, a scheme that is designed for implementation security will likely require PQ/T hybrid confidentiality or PQ/T hybrid authentication, while a scheme for interoperability will require PQ/T hybrid interoperability.</t> <dl newline="true"> <dt><strong>PQ/T 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> <dd> <t>The property that authentication is achieved by a PQ/T hybrid scheme or a PQ/T hybrid protocol as long as at least one component algorithm that aims to provide this property remains secure.</t> </dd> </dl> <t>The security properties of a PQ/T hybrid scheme or protocol depend on the security of its component algorithms, the choice of PQ/T hybrid combiner, and the capability of an attacker. Changes to the security of a component algorithm can impact the security properties of a PQ/T hybrid scheme providing hybrid confidentiality or hybrid authentication. For example, if the post-quantum component algorithm of a PQ/T hybrid scheme is broken, the scheme will remain secure against an attacker with a classical computer, but will be vulnerable to an attacker with a CRQC.</t> <t>PQ/T hybrid protocols that offer both confidentiality and authentication do not necessarily offer both hybrid confidentiality and hybrid authentication. For example, <xref target="I-D.ietf-tls-hybrid-design"/> provides hybrid confidentiality but does not address hybrid authentication. Therefore, if the design in <xref target="I-D.ietf-tls-hybrid-design"/> is used with single-algorithm X.509 certificates as defined in <xref target="RFC5280"/>, only authentication with a single algorithm is achieved.</t> <dl newline="true"> <dt><strong>PQ/T 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> <t>For example, a PQ/T hybrid digital signature might achieve hybrid interoperability if the signature can be verified by either verifying the traditional or the post-quantum component, such as the approach defined in Section 7.2.2 of <xref target="ITU-T-X509-2019"/>. In this example, a verifier that has migrated to support post-quantum algorithms is required to verify only the post-quantum signature, while a verifier that has not migrated will verify only the traditional signature.</t> </dd> </dl> <t>In the case of a protocol that aims to achieve both authentication and confidentiality, PQ/T hybrid interoperability requires that at least one component authentication algorithm and at least one component algorithm for confidentiality is supported by both parties.</t> <t>It is not possible for a PQ/T hybrid scheme to achieve both PQ/T hybrid interoperability and PQ/T hybrid confidentiality without additional functionality at a protocol level. For PQ/T hybrid interoperability, a scheme needs to work whenever one component algorithm is supported by both parties, while to achieve PQ/T hybrid confidentiality, all component algorithms need to be used. However, both properties can be achieved in a PQ/T hybrid protocol by building in downgrade protection external to the cryptographic schemes. For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client uses the TLS supported groups extension to advertise support for a PQ/T hybrid scheme, and the server can select this group if it supports the scheme. This is protected using TLS's existing downgrade protection, so 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 newline="true"> <dt><strong>PQ/T 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> <t>Note that PQ/T hybrid forwards 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 newline="true"> <dt><strong>PQ/T hybrid certificate</strong>:</dt> <dd> <t>A digital certificate that contains public keys for two or more component algorithms where at least one is a traditional algorithm and at least one is a post-quantum algorithm.</t> <t>A PQ/T hybrid certificate could be used to facilitate a PQ/T hybrid authentication protocol. However, a PQ/T hybrid authentication protocol does not need to use a PQ/T hybrid certificate; separate certificates could be used for individual component algorithms.</t> <t>The component public keys in a PQ/T hybrid certificate could be included as a composite public key or as individual component public keys.</t> <t>The use of a PQ/T hybrid certificate does not necessarily achieve hybrid authentication of the identity of the sender; this is determined by properties of the chain of trust. For example, an end-entity certificate that contains a composite public key, but which is signed using a single-algorithm digital signature scheme, could be used to provide hybrid authentication of the source of a message, but would not achieve hybrid authentication of the identity of the sender.</t> </dd> <dt><strong>Post-quantum certificate</strong>:</dt> <dd> <t>A digital certificate that contains a single public key for a post-quantum digital signature algorithm.</t> </dd> <dt><strong>Traditional certificate</strong>:</dt> <dd> <t>A digital certificate that contains a single public key for a traditional digital signature algorithm.</t> </dd> </dl> <t>X.509 certificates as defined in <xref target="RFC5280"/> could be either traditional or post-quantum certificates depending on the algorithm in the Subject Public Key Info. For example, a certificate containing a ML-DSA public key, as defined in <xref target="I-D.ietf-lamps-dilithium-certificates"/>, would be a post-quantum certificate.</t> <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> <dd> <t>A certificate chain where all certificates include a public key for a traditional algorithm and are signed using a traditional digital signature scheme.</t> </dd> <dt><strong>PQ/T hybrid certificate chain</strong>:</dt> <dd> <t>A certificate chain where all certificates are PQ/T hybrid certificates and each certificate is signed with two or more component algorithms with at least one being a traditional algorithm and at least one being a post-quantum algorithm.</t> </dd> </dl> <t>A PQ/T hybrid certificate chain is one way of achieving hybrid authentication of the identity of a sender in a protocol, but it is not the only way. An alternative is to use a PQ/T parallel PKI as defined below.</t> <dl newline="true"> <dt><strong>PQ/T mixed certificate chain</strong>:</dt> <dd> <t>A certificate chain containing at least two of the three certificate types defined in this document (PQ/T hybrid certificates, post-quantum certificates, and traditional certificates).</t> <t>For example, a traditional end-entity certificate could be signed by a post-quantum intermediate certificate, which in turn could be signed by a post-quantum root certificate. This may be desirable due to the lifetimes of the certificates, the relative difficulty of rotating keys, or for efficiency reasons. The security properties of a certificate chain that mixes post-quantum and traditional algorithms would need to be analysed on a case-by-case basis.</t> </dd> <dt><strong>PQ/T parallel PKI</strong>:</dt> <dd> <t>Two certificate chains, one that is a post-quantum certificate chain and one that is a traditional certificate chain, and that are used together in a protocol.</t> <t>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> <dd> <t>Authentication that uses two or more end-entity certificates.</t> <t>For example, multi-certificate authentication may be achieved using a PQ/T parallel PKI.</t> </dd> </dl> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This document defines security-relevant terminology to be used in documents specifying PQ/T hybrid protocols and schemes. However, the document itself does not have a security impact on Internet protocols. The security considerations for each PQ/T hybrid protocol are specific to that protocol and should be discussed in the relevant specification documents. 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, 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>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>Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks</title> <author> <organization>ITU-T</organization> </author> <date year="2019" 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>NIST</organization> </author> <date 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>A Profile for U. S. Federal Cryptographic Key Management Systems</title> <author 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> <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" target="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11";> <front> <title>Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Digital Signature Algorithm (ML-DSA)</title> <author initials="J." surname="Massimo" fullname="Jake Massimo"> <organization>AWS</organization> </author> <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis"> <organization>AWS</organization> </author> <author initials="S." surname="Turner" fullname="Sean Turner"> <organization>sn3rd</organization> </author> <author initials="B. E." surname="Westerbaan" fullname="Bas Westerbaan"> <organization>Cloudflare</organization> </author> <date month="May" day="22" year="2025" /> </front> <seriesInfo name="Internet-Draft" 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="RFC9763" target="https://www.rfc-editor.org/info/rfc9763";> <front> <title>Related Certificates for Use in Multiple Authentications within a Protocol</title> <author initials="A." surname="Becker" fullname="Alison Becker"> <organization>National Security Agency</organization> </author> <author initials="R." surname="Guthrie" fullname="Rebecca Guthrie"> <organization>National Security Agency</organization> </author> <author initials="M." surname="Jenkins" fullname="Michael J. Jenkins"> <organization>National Security Agency</organization> </author> <date month='June' year='2025'/> </front> <seriesInfo name="RFC" value="9763"/> <seriesInfo name="DOI" value="10.17487/RFC9763"/> </reference> <!-- [I-D.ietf-tls-hybrid-design] draft-ietf-tls-hybrid-design-12 IESG State: I-D Exists as of 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 "long way" to match information in the header. --> <reference 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 initials="M." surname="Ounsworth" fullname="Mike Ounsworth"> <organization>Entrust Limited</organization> </author> <author initials="J." surname="Gray" fullname="John Gray"> <organization>Entrust Limited</organization> </author> <author initials="M." surname="Pala" fullname="Massimiliano Pala"> <organization>OpenCA Labs</organization> </author> <author initials="J." surname="Klaussner" fullname="Jan Klaussner"> <organization>Bundesdruckerei GmbH</organization> </author> <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer"> <organization>Cisco Systems</organization> </author> <date month="March" day="18" year="2025" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-kem-06" /> </reference> <reference anchor="BDPR" target="https://www.cs.ucdavis.edu/~rogaway/papers/relations.pdf";> <front> <title>Relations Among Notions of Security for Public-Key Encryption Schemes</title> <author initials="M." surname="Bellare"> <organization/> </author> <author initials="A." surname="Dessai"> <organization/> </author> <author initials="D." surname="Pointcheval"> <organization/> </author> <author initials="P." surname="Rogaway"> <organization/> </author> </front> </reference> <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 document is the product of numerous fruitful discussions in the IETF PQUIP group. Thank you in particular to <contact fullname="Mike Ounsworth"/>, <contact fullname="John Gray"/>, <contact fullname="Tim Hollebeek"/>, <contact fullname="Wang Guilin"/>, <contact fullname="Rebecca Guthrie"/>, <contact fullname="Stephen Farrell"/>, <contact fullname="Paul Hoffman"/>, and <contact fullname="SofÃa Celi"/> for their contributions. This document is inspired by many others from the IETF and elsewhere.</t> </section> </back> <!-- [rfced] Abbreviations: a) Regarding IND-CPA and IND-CCA in Section 2: Current: The standard security property for a PKE scheme is indistinguishability under chosen-plaintext attack (IND-CPA). IND-CPA security is not sufficient for secure communication in the presence of an active attacker. Therefore, in general, PKE schemes are not appropriate for use on the Internet, and KEMs, which provide indistiguishability under chosen-ciphertext attack (IND-CCA security), are required. - Is the word 'security' needed in 'IND-CCA security'? - We note that RFC 9771 includes references for IND-CCA and IND-CCA2. Would you like to add references to this document, or will this be sufficiently clear to the 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 items below. Please review each expansion in the document carefully to 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) --> <!-- [rfced] For readability we have formatted the lists in this document with a line break between each term and its definition. We suggest removing the <strong> element (which yields bold font in the HTML and PDF, and yields asterisks in the 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 more precise language, which is helpful for readers. In addition, please consider whether "traditional" should be updated throughout this document for clarity. While the 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>
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
