Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!--[rfced] Note that we have updated the short title, which appears in the running header In the PDF output, as follows. Original: ietf-pquip-hybrid-spectrums Current: Hybrid Signature Spectrums --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!--[rfced] We note that both of the following terms are used in the document (note "Project" vs. "Process"). Should these be made consistent? NIST Post-Quantum Cryptography Standardization Project NIST Post-Quantum Cryptography Standardization Process Original: Research has indicated that implementation-independent attacks published in 2023 or earlier had broken 48% of the proposals in Round 1 of the NIST Post-Quantum Cryptography Standardization Project, 25% of the proposals not broken in Round 1, and 36% of the proposals selected by NIST for Round 2 [QRCSP]. ... Of note, some next-generation algorithms have received considerable analysis, for example, following attention gathered during the NIST Post-Quantum Cryptography Standardization Process [NIST_PQC_FAQ]. --> 4) <!--[rfced] FYI - We updated "25% of the proposals not broken in Round 1" as follows for clarity. Original: Research has indicated that implementation-independent attacks published in 2023 or earlier had broken 48% of the proposals in Round 1 of the NIST Post-Quantum Cryptography Standardization Project, 25% of the proposals not broken in Round 1, and 36% of the proposals selected by NIST for Round 2 [QRCSP]. Perhaps: Research indicates that implementation-independent attacks published in 2023 or earlier had broken 48% of the proposals in Round 1 of the NIST Post-Quantum Cryptography Standardization Project, 25% of the proposals not broken by the end of Round 1, and 36% of the proposals selected by NIST for Round 2 [QRCSP]. --> 5) <!-- [rfced] We were unable to find the quoted text below in [RFC9794]. Is this quote from [RFC9794] or another reference? Original: This is different from [RFC9794] where the term is used as a specific instantiation of hybrid schemes such that "where multiple cryptographic algorithms are combined to form a single key or signature such that they can be treated as a single atomic object at the protocol level." --> 6) <!--[rfced] To improve readability, may we break up this long sentence into two sentences and update as follows? Original: While it often makes sense for security purposes to require that the security of the component schemes is based on the hardness of different cryptographic assumptions, in other cases hybrid schemes might be motivated, e.g., by interoperability of variants on the same scheme and as such both component schemes are based on the same hardness assumption (e.g., both post-quantum assumptions or even both the same concrete assumption such as Ring LWE). Perhaps: For security purposes, it often makes sense to require that the security of the component schemes be based on the hardness of different cryptographic assumptions, but in some cases, hybrid schemes might be motivated, e.g., by interoperability of variants on the same scheme. As such, both component schemes are based on the same hardness assumption (e.g., both post-quantum assumptions or even both the same concrete assumption, such as Ring Learning With Errors (LWE)). --> 7) <!-- [rfced] Is "CRYSTALS-DILITHIUM" another name for "ML-DSA"? Or are they separate schemes? Please review and let us know if/how this text may be clarified. Current: For example, the signature scheme Module-Lattice-Based Digital Signature Algorithm (ML-DSA) [MLDSA] (also known as CRYSTALS-DILITHIUM) follows the well- known Fiat-Shamir transform [FS] to construct the signature scheme but also relies on rejection sampling that is known to give cache side channel information (although this does not lead to a known attack). Section 1.2 of [MLDSA] (FIPS 204) states the following about ML-DSA and CRYSTALS-DILITHIUM: ML-DSA is derived from one of the selected schemes, CRYSTALS-DILITHIUM [5 , 6 ], and is intended to protect sensitive U.S. Government information well into the foreseeable future, including after the advent of cryptographically relevant quantum computers. For the differences between ML-DSA and CRYSTALS- DILITHIUM, see Appendix D. --> 8) <!-- [rfced] The second sentence below seems to be saying the same thing as the first. Should the second sentence be removed? Current: Hybrid unforgeability is a specific type of hybrid authentication, where the security assumption for the scheme (e.g., EUF-CMA) is maintained as long as at least one of the component schemes maintains that security assumption. We call this notion 'hybrid unforgeability'; it is a specific type of hybrid authentication. Perhaps: Hybrid unforgeability is a specific type of hybrid authentication, where the security assumption for the scheme (e.g., EUF-CMA) is maintained as long as at least one of the component schemes maintains that security assumption. --> 9) <!-- [rfced] For the ease of the reader, may we update "description below" and "discussion below" to a section number? If so, please confirm that Section 1.3.5 is correct. Original: There might be, however, other goals in competition with this one, such as backward-compatibility - referring to the property where a hybrid signature may be verified by only verifying one component signature (see description below). ... For more details, we refer to our discussion below. Perhaps: There might be, however, other goals in competition with this one, such as backward compatibility - referring to the property where a hybrid signature may be verified by only verifying one component signature (see Section 1.3.5). ... For more details, refer to Section 1.3.5. --> 10) <!-- [rfced] We are having trouble understanding the first part of this sentence. Would revising as shown below improve clarity while retaining the intended meaning? Original: Use cases where a hybrid scheme is used with, e.g., EUF-CMA security assumed for only one component scheme generally use hybrid techniques for their 'functional transition' pathway support. ... In contrast, use cases where a hybrid scheme is used with e.g., EUF- CMA security assumed for both component schemes without prioritisation between them can use hybrid techniques for both functional transition and security transition ... Perhaps: In some use cases, a hybrid scheme is used with (for example) EUF-CMA security assumed for only one component scheme; these cases generally use hybrid techniques for their 'functional transition' pathway support. ... In contrast, in other use cases, a hybrid scheme is used with (for example) EUF- CMA security assumed for both component schemes without prioritisation between them; these cases can use hybrid techniques for both functional transition and security transition ... --> 11) <!-- [rfced] How may we update "algorithms/the" here? Original: For instance, this can intuitively be seen in cases of a message containing a context note on hybrid authentication, that is then signed by all component algorithms/the hybrid signature scheme. Perhaps: For instance, this can intuitively be seen in cases of a message containing a context note on hybrid authentication, that is then signed by all component algorithms in the hybrid signature scheme. --> 12) <!-- [rfced] Should 'component digital signatures "categories"' be updated to use singular 'signature' as shown in Perhaps A, recast as shown in Perhaps B, or revised in some other way? Original: Hybrid generality means that a general signature combiner is defined, based on inherent and common structures of component digital signatures "categories." Perhaps A: Hybrid generality means that a general signature combiner is defined based on inherent and common structures of component digital signature "categories". Perhaps B: Hybrid generality means that a general signature combiner is defined based on inherent and common structures of "categories" of the component digital signatures. --> 13) <!-- [rfced] We could not find any mention of "space" in draft-ietf-tls-hybrid-design (RFC-to-be 9954). Please review and let us know how this citation may be updated. Original: Similarly to space considerations in [I-D.ietf-tls-hybrid-design], hybrid signature constructions are expected to be as space performant as possible. --> 14) <!-- [rfced] We made a few changes to Figures 1 and 2 (e.g., updated spacing, added articles, and included punctuation). Please review. --> 15) <!-- [rfced] Will readers understand what is meant by "hybrid" and "hybrids" (noun) in these sentences? Should these be updated to "hybrid signature" and "hybrid signatures" (or to something else), or is the current clear? Original: Under Weak Non-Separability, if one of the component signatures of a hybrid is removed artifacts of the hybrid will remain (in the message, signature, or at the protocol level, etc.). ... Note that in this latter case, it is not possible for an adversary to strip one of the component signatures or use a component of the hybrid to create a forgery for a component algorithm. ... applies equally to any guidance or policy direction that specifies that at least one component algorithm of the hybrid has passed some certification type while not specifying requirements on the other component. ... however, we use it as motivation to highlight some points that implementers of hybrids may wish to consider when following any guidance documents that specify ... ... This type of need for approval (i.e., a requirement that an implementer is looking to follow regarding approval or certification of the software module implementation of a hybrid or its component algorithms) can drive some logistical decisions on what types of hybrids an implementer should consider. ... If the hybrid signature is stripped, such that a single component signature is submitted to a verification algorithm for that component along with the message that was signed by the hybrid, the result would be an EUF-CMA forgery for the component signature. ... Thus, if EUF-CMA security for hybrids is considered to be informally defined in the straightforward way as ... --> 16) <!-- [rfced] How may we clarify "message/inner" here? Original: In another example, under nested signatures the verifier could be tricked into interpreting a new message as the message/inner signature combination and verify only the outer signature. Perhaps A: In another example, under nested signatures, the verifier could be tricked into interpreting a new message as the message and inner signature combination and verify only the outer signature. Perhaps B: In another example, under nested signatures, the verifier could be tricked into interpreting a new message as the combination of the message and inner signature and verify only the outer signature. --> 17) <!--[rfced] To improve readability, may we update the second sentence below as follows? The first sentence is included for context. Original: The verifier could indeed ignore the artifact, hence the scheme achieving only weak non-separability and not strong non-separability. It is rather that an artifact exists that could be identified if an investigation occurred, etc. Perhaps: The verifier could indeed ignore the artifact, resulting in the scheme achieving only weak non-separability and not strong non-separability. However, an existing artifact could be identified if an investigation occurred. --> 18) <!-- [rfced] Will "As can be seen" be clear to readers in these two sentences? Could it be updated to "As shown in Table 1" in the first sentence and removed in the second sentence? Original: As can be seen, while concatenation may appear to refer to a single type of combiner, there are in fact several possible artifact locations depending on implementation choices. ... However, as can be seen, this does not imply that every implementation using concatenation fails to achieve non- separability. Perhaps: As shown in Table 1, while concatenation may appear to refer to a single type of combiner, there are in fact several possible artifact locations depending on implementation choices. ... However, this does not imply that every implementation using concatenation fails to achieve non- separability. --> 19) <!-- [rfced] The quoted text below no longer appears at the URL provided for [NIST_PQC_FAQ]: https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs. That page was lasted updated on 19 November 2025. We found an archived URL from the Internet Archive from 5 July 2022 (the original date used for this reference): https://web.archive.org/web/20220705163944/https://csrc.nist.gov/Projects/ post-quantum-cryptography/faqs May we update this reference to use the archived URL? Original: Assume that in a [hybrid] signature, _one signature is generated with a NIST-approved signature scheme as specified in FIPS 186, while another signature(s) can be generated using different schemes_, e.g., ones that are not currently specified in NIST standards..._hybrid signatures can be accommodated by current standards in FIPS mode, as defined in FIPS 140, provided at least one of the component methods is a properly implemented, NIST- approved signature algorithm_. For the purposes of FIPS 140 validation, any signature that is generated by a non-approved component scheme would not be considered a security function, since the NIST-approved component is regarded as assuring the validity of the hybrid signature. [NIST_PQC_FAQ] ... [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>. --> 20) <!-- [rfced] We do not see "Generality" used elsewhere in Section 4. Should it be removed from the title of Figure 2? Original: Figure 2: Generality / Need for Approval Spectrum Perhaps: Figure 2: Need for Approval Spectrum --> 21) <!-- [rfced] Is "game" the correct word choice here? Or would "assumption" (used earlier in the paragraph) be better? Original: Namely, the most straightforward extension of the traditional EUF-CMA security game would be that an adversary can request hybrid signatures for messages of their choosing and succeeds if they are able to produce a valid hybrid signature for a message that was not part of an earlier request. --> 22) <!--[rfced] We are having difficulty parsing this sentence, particularly "is considered to be informally defined in the straightforward way as that an adversary can request...". Please review and let us know how it may be updated for clarity. Original: Thus, if EUF-CMA security for hybrids is considered to be informally defined in the straightfoward way as that an adversary can request hybrid signatures for messages of their choosing and succeeds if they are able to produce a valid hybrid signature for a message that was not part of an earlier request, implicit requirements must hold in order to avoid real-world implications. Perhaps: Thus, if the straightforward EUF-CMA security assumption for hybrids is that an adversary requests hybrid signatures for messages of their choosing and succeeds if they are able to produce a valid hybrid signature for a message that was not part of an earlier request, implicit requirements must hold in order to avoid real-world implications. --> 23) <!-- [rfced] Please review the relationship between "cross-protocol attack" and "component algorithm forgery" in the sentences below and let us know if updates are needed for consistency. Also, in the last sentence below (starts with "Otherwise"), perhaps "which can be seen as a type of cross-protocol attack" can be removed as it is mentioned in the previous sentence. Original: such as cross-protocol attacks (e.g., component algorithm forgeries). ... This is an example of a component algorithm forgery, a.k.a. a case of cross- algorithm attack or cross-protocol attack. ... Namely, either component algorithm forgeries, a.k.a. cross-protocol attacks, must be out of scope for the use case or the hybrid signature choice must be strongly non-separable. Otherwise, component algorithm forgeries, which can be seen as a type of cross-protocol attack, affect the type of EUF-CMA properties offered ... Perhaps: such as cross-protocol attacks (a.k.a. component algorithm forgeries). ... This is an example of a component algorithm forgery (a.k.a. cross- algorithm attack or cross-protocol attack). ... Namely, either component algorithm forgeries (a.k.a. cross-protocol attacks) must be out of scope for the use case or the hybrid signature choice must be strongly non-separable. Otherwise, component algorithm forgeries affect the type of EUF-CMA properties offered ... --> 24) <!--[rfced] May we update "additional" to "in addition" in this sentence? Original: Since the goal of backwards compatibility is usually to allow legacy systems without any software change to be able to process hybrid signatures, all differences between the legacy signature format and the hybrid signature format must be allowed to be ignored, including skipping verification of signatures additional to the classical signature. Perhaps: Since the goal of backwards compatibility is usually to allow legacy systems without any software change to be able to process hybrid signatures, all differences between the legacy signature format and the hybrid signature format must be allowed to be ignored, including skipping verification of signatures in addition to the classical signature. --> 25) <!-- [rfced] This reference currently points to a paper made available via Ronald L. Rivest's MIT faculty page. This paper is also available for free on ACM Digital Library (which is likely more stable). Would you like this reference to point to the version on ACM Digital Library or keep the current version? Current: [RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", <https://people.csail.mit.edu/rivest/Rsapaper.pdf>. Perhaps: [RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, vol. 21, no. 2, pp. 120-126, DOI 10.1145/359340.359342, <https://doi.org/10.1145/359340.359342>. --> 26) <!-- [rfced] We do not see "template" in ietf-tls-hybrid-design (RFC-to-be 9954). Would another term be better here? Original: This document is based on the template of [I-D.ietf-tls-hybrid-design]. Perhaps: This document is based on the hybrid key exchange defined in [RFC9954]. --> 27) <!-- [rfced] Font styling a) Use of <tt> This file lists terms enclosed in <tt> in this document: https://www.rfc-editor.org/authors/rfc9955-TT.txt Some of these terms appear both with and without <tt>. For example, we see "[hybrid] signatures" and "[hybrid]" enclosed in <tt>, but we also see instances of "[hybrid]" and "hybrid" without <tt>. Please review to ensure the usage of <tt> is correct and consistent. Let us know if any updates are needed using OLD/NEW format. Note: In the HTML and PDF outputs, <tt> yields fixed-width font. In the TXT output, there is no change. b) Use of <em> This is only used in the direct quote in Section 4. The emphasis may be difficult to see in the TXT output. Please review. Note: In the HTML and PDF outputs, <em> yields italics. In the TXT output, <em> yields an underscore before and after. --> 28) <!-- [rfced] Terminology a) Should the four instances of "scale" in the document be updated to "spectrum"? Current: Non-separability is not a singular definition but rather is a scale, representing degrees of separability hardness, visualized in Figure 1. ... Third on the scale is the Strong Non-Separability notion, in which separability detection is dependent on artifacts in the signature itself. ... In this respect, there is a scale of approval that developers may consider as to whether they are using at least one approved component algorithm implementation ... ... We provide a scale for the different nuances of approval of the hybrid combiners, where "approval" means that a software implementation of a component algorithm can be used unmodified for creation of the hybrid signature. b) In Table 2, should instances of "cert" and "certs" be updates to "certificate" and "certificates"? c) The following terms are used in the document. Please review to ensure consistent and correct usage. Let us know if any updates are needed. component message forgery attack component algorithm forgery (and component algorithm forgeries) component forgery (and component forgeries) component forgery attacks --> 29) <!-- [rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Great Multivariate Short Signature (GeMSS) Learning With Errors (LWE) Module-Lattice-Based Digital Signature Algorithm (ML-DSA) Post-Quantum Traditional (PQ/T) b) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document? Simultaneous Verification (SV) Strong Non-Separability (SNS) Weak Non-Separability (WNS) --> 30) <!-- [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. For example, please consider whether "black-box" should be updated. In addition, please consider whether "traditional" should be updated for clarity. While the NIST website indicates that this term is potentially biased, it is also ambiguous. "Traditional" is a subjective term, as it is not the same for everyone. Link to NIST website: https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1 --> Thank you. Alanna Paloma and Rebecca VanRheenen RFC Production Center On Apr 3, 2026, at 9:48 AM, [email protected] wrote: *****IMPORTANT***** Updated 2026/04/03 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/rfc9955.xml https://www.rfc-editor.org/authors/rfc9955.html https://www.rfc-editor.org/authors/rfc9955.pdf https://www.rfc-editor.org/authors/rfc9955.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9955-diff.html https://www.rfc-editor.org/authors/rfc9955-rfcdiff.html (side by side) For your convenience, we have also created an alt-diff file that will allow you to more easily view changes where text has been deleted or moved: https://www.rfc-editor.org/authors/rfc9955-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9955-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9955 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9955 (draft-ietf-pquip-hybrid-signature-spectrums-07) Title : Hybrid signature spectrums Author(s) : N. Bindel, B. Hale, D. Connolly, F. Driscoll WG Chair(s) : Paul E. Hoffman Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
