Hi Nina, Thank you for your reply. No need to submit your approval anywhere else, replying in this email thread is perfect!
We have noted your approval here: https://queue.rfc-editor.org/final-review/rfc9955/ We will await approvals from Britta, Deirdre, Flo, and Chris (AD). Best regards, Alanna Paloma RFC Production Center > On Jun 26, 2026, at 5:02 AM, Nina Bindel <[email protected]> wrote: > > Dear all, > > You have my approval. Do I need to submit it somewhere formally in addition? > > Thank you for all the work you have done, especially thanks to Flo, Britta > and Alanna for pushing this over the finish line! > > Best, > Nina > > > > On June 25, 2026 4:56:19 p.m. GMT+01:00, Alanna Paloma > <[email protected]> wrote: > Hi Flo and Deirdre, > > Thank you for your replies. We have updated the files accordingly. > > We will await approvals from each author and Chris (AD) prior to moving this > document forward in the publication process. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9955.xml > https://www.rfc-editor.org/authors/rfc9955.txt > https://www.rfc-editor.org/authors/rfc9955.html > https://www.rfc-editor.org/authors/rfc9955.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (Final Review > changes) > https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (Final Review > changes side by side) > https://www.rfc-editor.org/authors/rfc9955-lastdiff.html (last version to > this one) > https://www.rfc-editor.org/authors/rfc9955-lastrfcdiff.html (rfcdiff between > last version and this) > > For the Final Review status of this document, please see: > https://queue.rfc-editor.org/final-review/rfc9955/ > > Thank you, > Alanna Paloma > RFC Production Center > >> On Jun 24, 2026, at 8:06 AM, Deirdre Connolly <[email protected]> >> wrote: >> >> One nit, >> >> 'Component message algorithm forgery attacks:' >> >> I would write 'Component algorithm message forgery attacks', in several >> locations in section 1.1. >> >> > We call this notion 'hybrid unforgeability'; it is a specific type of >> > hybrid authentication. >> >> This definition is used later in the document. >> >> >> >> >> >> On Mon, Jun 22, 2026 at 7:35 PM Alanna Paloma <[email protected]> >> wrote: >> Hi Authors and Chris*, >> >> *Chris - As the AD, pleases review and approve of the added text in Section >> 5. >> >> See this diff file: >> https://www.rfc-editor.org/authors/rfc9955-auth48diff.html >> >> Authors - Thank you for your reply. The files have been updated accordingly. >> >> We will await approvals from each party listed on the Final Review status >> page below prior to moving this document forward in the publication process. >> >> Note: If you would like to send any further updates by way of an updated XML >> file, please make changes to the most recent XML file (provided below). >> >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9955.xml >> https://www.rfc-editor.org/authors/rfc9955.txt >> https://www.rfc-editor.org/authors/rfc9955.html >> https://www.rfc-editor.org/authors/rfc9955.pdf >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (Final Review >> changes) >> https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (Final Review >> changes side by side) >> https://www.rfc-editor.org/authors/rfc9955-lastdiff.html (last version to >> this one) >> https://www.rfc-editor.org/authors/rfc9955-lastrfcdiff.html (rfcdiff between >> last version and this) >> >> For the Final Review status of this document, please see: >> https://queue.rfc-editor.org/final-review/rfc9955/ >> >> Thank you, >> Alanna Paloma >> RFC Production Center >> >> > On Jun 18, 2026, at 6:48 AM, Flo D <[email protected]> wrote: >> > >> > OFFICIAL >> > >> > Hi Alanna, >> > >> > Britta and I have had another look at the document, I'm attaching the >> > newest commented version. >> > >> > We've now addressed the leftover query - I've made the changes and the >> > rationale is under the comment. >> > >> > There are a few additional changes and suggestions following Britta's >> > review. These are labelled as [BH] in the document. >> > >> > Thank you! >> > Flo >> > >> > Flo D >> > Deputy CTO for Cyber Policy >> > and Assessments >> > [email protected] >> > Pronouns: she/her >> > http://www.ncsc.gov.uk/ >> > >> > >> > >> > >> > OFFICIAL >> > -----Original Message----- >> > From: Alanna Paloma <[email protected]> >> > Sent: 20 May 2026 16:48 >> > To: Flo D <[email protected]> >> > Cc: [email protected]; [email protected]; Nina Bindel >> > <[email protected]>; [email protected]; [email protected]; Paul >> > Hoffman <[email protected]>; Paul Wouters <[email protected]>; >> > auth48archive <[email protected]>; RFC Editor >> > <[email protected]> >> > Subject: Re: AUTH48: RFC-to-be 9955 >> > <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review >> > >> > Hi Flo, >> > >> > We’ve updated the files with that change. Note that we are awaiting your >> > response to this query: >> > >> >> 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 >> > >> > >> > The files have been posted here (please refresh): >> > https://www.rfc-editor.org/authors/rfc9955.xml >> > https://www.rfc-editor.org/authors/rfc9955.txt >> > https://www.rfc-editor.org/authors/rfc9955.html >> > https://www.rfc-editor.org/authors/rfc9955.pdf >> > >> > The relevant diff files have been posted here: >> > https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff) >> > https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (AUTH48 changes) >> > https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (AUTH48 >> > changes side by side) >> > https://www.rfc-editor.org/authors/rfc9955-lastdiff.html (last version to >> > this one) >> > https://www.rfc-editor.org/authors/rfc9955-lastrfcdiff.html (rfcdiff >> > between last version and this) >> > >> > For the AUTH48 status of this document, please see: >> > https://www.rfc-editor.org/auth48/rfc9955 >> > >> > Thank you, >> > Alanna Paloma >> > RFC Production Center >> > >> >> On May 20, 2026, at 12:20 AM, Flo D <[email protected]> wrote: >> >> >> >> OFFICIAL >> >> >> >> Hi Alanna, >> >> >> >> That change sounds fine, thank you. >> >> >> >> Flo >> >> >> >> Flo D >> >> Deputy CTO for Cyber Policy >> >> and Assessments >> >> [email protected] >> >> Pronouns: she/her >> >> http://www.ncsc.gov.uk/ >> >> >> >> >> >> OFFICIAL >> >> -----Original Message----- >> >> From: Alanna Paloma <[email protected]> >> >> Sent: 19 May 2026 19:20 >> >> To: Flo D <[email protected]> >> >> Cc: [email protected]; [email protected]; Nina Bindel >> >> <[email protected]>; [email protected]; [email protected]; Paul >> >> Hoffman <[email protected]>; Paul Wouters <[email protected]>; >> >> auth48archive <[email protected]>; RFC Editor >> >> <[email protected]> >> >> Subject: Re: AUTH48: RFC-to-be 9955 >> >> <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review >> >> >> >> Hi Flo, >> >> >> >> Thank you for your reply. We have updated as requested. Note that we >> >> have one follow-up question. >> >> >> >> ) May we clarify “an example of” by updating it to “which is a type of”? >> >> >> >> Current: >> >> This is an example of a component algorithm forgery, an >> >> example of a cross-algorithm attack or cross-protocol attack. >> >> >> >> Perhaps: >> >> This is an example of a component algorithm forgery, which is >> >> a type of a cross-algorithm attack or cross-protocol attack. >> >> >> >> >> >> The files have been posted here (please refresh): >> >> https://www.rfc-editor.org/authors/rfc9955.xml >> >> https://www.rfc-editor.org/authors/rfc9955.txt >> >> https://www.rfc-editor.org/authors/rfc9955.html >> >> https://www.rfc-editor.org/authors/rfc9955.pdf >> >> >> >> The relevant diff files have been posted here: >> >> https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff) >> >> https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (AUTH48 >> >> changes) >> >> https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (AUTH48 >> >> changes side by side) >> >> >> >> Please review the document carefully and contact us with any further >> >> updates you may have. Note that we do not make changes once a document >> >> is published as an RFC. >> >> >> >> We will await your response to our follow-up question above as well the >> >> remaining terminology query. >> >> >> >> For the AUTH48 status of this document, please see: >> >> https://www.rfc-editor.org/auth48/rfc9955 >> >> >> >> Thank you, >> >> Alanna Paloma >> >> RFC Production Center >> >> >> >> >> >>> On May 19, 2026, at 1:00 AM, Flo D <[email protected]> wrote: >> >>> >> >>> OFFICIAL >> >>> >> >>> Hi Alanna, >> >>> >> >>> Sorry for the delay on this. Attached is an updated version. One >> >>> comments remains to be addressed (terminology (c)), but we will aim to >> >>> get on this soon. >> >>> >> >>> Please let me know if there are any other issues. >> >>> >> >>> Flo >> >>> >> >>> >> >>> OFFICIAL >> >>> -----Original Message----- >> >>> From: Alanna Paloma <[email protected]> >> >>> Sent: 18 May 2026 17:45 >> >>> To: Flo D <[email protected]>; [email protected]; >> >>> [email protected]; [email protected] >> >>> Cc: [email protected]; [email protected]; Paul Hoffman >> >>> <[email protected]>; Paul Wouters <[email protected]>; >> >>> auth48archive <[email protected]>; RFC Editor >> >>> <[email protected]> >> >>> Subject: Re: AUTH48: RFC-to-be 9955 >> >>> <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review >> >>> >> >>> [You don't often get email from [email protected]. Learn why >> >>> this is important at https://aka.ms/LearnAboutSenderIdentification ] >> >>> >> >>> Hi Authors, >> >>> >> >>> We're still awaiting your responses to our previous questions before >> >>> this document can move forward in the publication process. Please let us >> >>> know if you have any questions. >> >>> >> >>> The AUTH48 status page for this document is located here: >> >>> https://www.rfc-editor.org/auth48/rfc9955 >> >>> >> >>> Thank you, >> >>> Alanna Paloma >> >>> RFC Production Center >> >>> >> >>>> On May 11, 2026, at 8:22 AM, Alanna Paloma >> >>>> <[email protected]> wrote: >> >>>> >> >>>> Hi Authors, >> >>>> >> >>>> This is another friendly reminder that we await your response to our >> >>>> previously sent questions. Please let us know if you have any questions. >> >>>> >> >>>> The AUTH48 status page for this document is located here: >> >>>> https://www/. >> >>>> rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7CFlo.D%40ncsc.gov.uk%7 >> >>>> C54dd52367c1c4e24663d08deb4fce7c2%7C14aa5744ece1474ea2d734f46dda64a1%7 >> >>>> C0%7C0%7C639147195984001873%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> >>>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 >> >>>> D%3D%7C0%7C%7C%7C&sdata=SLUDLYOj2lEJXyirGjNHdz8rhFpzeT7DhBCk7RZSyi8%3D >> >>>> &reserved=0 >> >>>> >> >>>> Thank you, >> >>>> Alanna Paloma >> >>>> RFC Production Center >> >>>> >> >>>>> On May 4, 2026, at 8:41 AM, Alanna Paloma >> >>>>> <[email protected]> wrote: >> >>>>> >> >>>>> Hi Authors, >> >>>>> >> >>>>> This is a friendly reminder that we are awaiting your response to our >> >>>>> previously sent questions. >> >>>>> >> >>>>> We will wait to hear from you before continuing with the publication >> >>>>> process. >> >>>>> >> >>>>> The AUTH48 status page for this document is located here: >> >>>>> https://www/ >> >>>>> .rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7CFlo.D%40ncsc.gov.uk >> >>>>> %7C54dd52367c1c4e24663d08deb4fce7c2%7C14aa5744ece1474ea2d734f46dda64a >> >>>>> 1%7C0%7C0%7C639147195984182179%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG >> >>>>> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo >> >>>>> yfQ%3D%3D%7C0%7C%7C%7C&sdata=HRdVL6Vq9h5NKqJ4z5kCMqxIBQAVq7cZrBj9FqWR >> >>>>> ylw%3D&reserved=0 >> >>>>> >> >>>>> Thank you, >> >>>>> Alanna Paloma >> >>>>> RFC Production Center >> >>>>> >> >>>>>> On Apr 14, 2026, at 12:52 AM, Flo D <[email protected]> wrote: >> >>>>>> >> >>>>>> OFFICIAL >> >>>>>> >> >>>>>> >> >>>>>> Hi Alanna, >> >>>>>> >> >>>>>> Thank you. We are discussing amongst the authors and will be able to >> >>>>>> get back to you soon. >> >>>>>> >> >>>>>> Flo >> >>>>>> >> >>>>>> >> >>>>>> OFFICIAL >> >>>>>> -----Original Message----- >> >>>>>> From: Alanna Paloma <[email protected]> >> >>>>>> Sent: 13 April 2026 17:39 >> >>>>>> To: [email protected]; [email protected]; >> >>>>>> [email protected]; Flo D <[email protected]> >> >>>>>> Cc: [email protected]; [email protected]; Paul Hoffman >> >>>>>> <[email protected]>; Paul Wouters <[email protected]>; >> >>>>>> auth48archive <[email protected]>; RFC Editor >> >>>>>> <[email protected]> >> >>>>>> Subject: Re: AUTH48: RFC-to-be 9955 >> >>>>>> <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review >> >>>>>> >> >>>>>> [You don't often get email from [email protected]. Learn >> >>>>>> why this is important at >> >>>>>> https://aka.ms/LearnAboutSenderIdentification ] >> >>>>>> >> >>>>>> Greetings, >> >>>>>> >> >>>>>> We do not believe we have heard from you regarding this document's >> >>>>>> readiness for publication. Please review our previous messages >> >>>>>> describing the AUTH48 process and containing any document-specific >> >>>>>> questions we may have had. >> >>>>>> >> >>>>>> We will wait to hear from you before continuing with the publication >> >>>>>> process. >> >>>>>> >> >>>>>> The AUTH48 status page for this document is located here: >> >>>>>> https://ww/ >> >>>>>> w.rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7CFlo.D%40ncsc.gov. >> >>>>>> uk%7C54dd52367c1c4e24663d08deb4fce7c2%7C14aa5744ece1474ea2d734f46dda >> >>>>>> 64a1%7C0%7C0%7C639147195984205503%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> >>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl >> >>>>>> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DSxJz0KRJhcfkl85nS7rl96ouEf4uIe9cE >> >>>>>> RnBBAWhdQ%3D&reserved=0 >> >>>>>> >> >>>>>> Thank you, >> >>>>>> Alanna Paloma >> >>>>>> RFC Production Center >> >>>>>> >> >>>>>>> On Apr 3, 2026, at 9:53 AM, [email protected] wrote: >> >>>>>>> >> >>>>>>> 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%2Fsearch&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100 >> >>>>>>> d6f >> >>>>>>> 75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0% >> >>>>>>> 7C6 >> >>>>>>> 39116952142108314%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI >> >>>>>>> lYi >> >>>>>>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C >> >>>>>>> 400 >> >>>>>>> 00%7C%7C%7C&sdata=VBi8v52NykkpgSEnXnipU97KOPrxj01Do91EFkablEU%3D&re >> >>>>>>> ser >> >>>>>>> ved=0. --> >> >>>>>>> >> >>>>>>> >> >>>>>>> 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%2Fweb%2F20220705163944%2Fhttps%3A%2F%2Fcsrc.nist.gov%2F >> >>>>>>> Pro >> >>>>>>> jects%2F&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e260 >> >>>>>>> 8de >> >>>>>>> 997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6391169521421 >> >>>>>>> 503 >> >>>>>>> 52%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw >> >>>>>>> MCI >> >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C& >> >>>>>>> sda >> >>>>>>> ta=NjyLiA1Mk5tY1A1Tzo18PUuBBsregK0DrcIQ8TCv5CU%3D&reserved=0 >> >>>>>>> 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%2Fauthors%2Frfc9955-TT.txt&data=05%7C02%7Cflo.d%40ncsc. >> >>>>>>> gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f >> >>>>>>> 46d >> >>>>>>> da64a1%7C0%7C0%7C639116952142225842%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >> >>>>>>> 0eU >> >>>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI >> >>>>>>> ldU >> >>>>>>> IjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=LhwRtGzgINulI5KXwwS3%2B7wmmpXJ5 >> >>>>>>> lEK >> >>>>>>> sa1WPvzUEzQ%3D&reserved=0 >> >>>>>>> >> >>>>>>> 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%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=0 >> >>>>>>> 5%7 >> >>>>>>> C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa >> >>>>>>> 574 >> >>>>>>> 4ece1474ea2d734f46dda64a1%7C0%7C0%7C639116952142243485%7CUnknown%7C >> >>>>>>> TWF >> >>>>>>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi >> >>>>>>> IsI >> >>>>>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=OAKGJ1JUFGfG >> >>>>>>> 4S7 F5JNLrFZvMbNeMhgI%2BBlrSEfJwPU%3D&reserved=0> >> >>>>>>> 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%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.gov%2Fn >> >>>>>>> ist >> >>>>>>> -research-library%2Fnist-technical-series-publications-author-instr >> >>>>>>> uct >> >>>>>>> ions%23table1&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a >> >>>>>>> 7e2 >> >>>>>>> 608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C63911695 >> >>>>>>> 214 >> >>>>>>> 2266275%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA >> >>>>>>> uMD >> >>>>>>> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7 >> >>>>>>> C%7 >> >>>>>>> C&sdata=KjcOH4cMH6dmM13%2B13OD%2BAjDTx1XlYsjUKX%2BJC65ue4%3D&reserv >> >>>>>>> ed= >> >>>>>>> 0 >> >>>>>>> --> >> >>>>>>> >> >>>>>>> >> >>>>>>> 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://mail/ >> >>>>>>> archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P >> >>>>>>> 8O4Zc&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997 >> >>>>>>> b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C639116952142368582% >> >>>>>>> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >> >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata= >> >>>>>>> 3hJ9a0AMEsdhemsdTdZX038KHPoEQJUpQooAVBOY4O4%3D&reserved=0 >> >>>>>>> >> >>>>>>> * The archive itself: >> >>>>>>> >> >>>>>>> https://mail/ >> >>>>>>> archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cflo >> >>>>>>> .d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474e >> >>>>>>> a2d734f46dda64a1%7C0%7C0%7C639116952142387914%7CUnknown%7CTWFpbGZsb3d8 >> >>>>>>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >> >>>>>>> FpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=sj%2F9zuIGXxz0auXp1vt54j >> >>>>>>> LYrSA5NPJ8qA1jJ1jsqlQ%3D&reserved=0 >> >>>>>>> >> >>>>>>> * 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%2Fauthors%2Frfc9955.xml&data=05%7C02%7Cflo.d%40ncsc.gov >> >>>>>>> .uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda6 >> >>>>>>> 4a1%7C0%7C0%7C639116952142405899%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> >>>>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo >> >>>>>>> yfQ%3D%3D%7C40000%7C%7C%7C&sdata=KOQhY%2B3XJtN7WaLVCzJa3OovpKDCJJ2yHj6 >> >>>>>>> AHiH%2FsmQ%3D&reserved=0 >> >>>>>>> >> >>>>>>> https://www/. >> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955.html&data=05%7C02%7Cflo.d%40ncsc.go >> >>>>>>> v.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda >> >>>>>>> 64a1%7C0%7C0%7C639116952142432157%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h >> >>>>>>> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> >>>>>>> oyfQ%3D%3D%7C40000%7C%7C%7C&sdata=zxgKqtprdwS2sHEk17d%2BKKsHZWVkxuBcL4 >> >>>>>>> WN81ZCYpg%3D&reserved=0 >> >>>>>>> >> >>>>>>> https://www/. >> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955.pdf&data=05%7C02%7Cflo.d%40ncsc.gov >> >>>>>>> .uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda6 >> >>>>>>> 4a1%7C0%7C0%7C639116952142459846%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> >>>>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo >> >>>>>>> yfQ%3D%3D%7C40000%7C%7C%7C&sdata=bDvmccc%2BmfGnu7k80hHgsLkzgBNRvt0cIiA >> >>>>>>> p7UZkjpU%3D&reserved=0 >> >>>>>>> >> >>>>>>> https://www/. >> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955.txt&data=05%7C02%7Cflo.d%40ncsc.gov >> >>>>>>> .uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda6 >> >>>>>>> 4a1%7C0%7C0%7C639116952142486506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> >>>>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo >> >>>>>>> yfQ%3D%3D%7C40000%7C%7C%7C&sdata=oz%2F3t8aS%2Bol6jhMCJDN508JUPjkk%2Fy6 >> >>>>>>> nKicgTo%2BW6%2Fk%3D&reserved=0 >> >>>>>>> >> >>>>>>> Diff file of the text: >> >>>>>>> >> >>>>>>> https://www/. >> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-diff.html&data=05%7C02%7Cflo.d%40nc >> >>>>>>> sc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f >> >>>>>>> 46dda64a1%7C0%7C0%7C639116952142512918%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >> >>>>>>> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI >> >>>>>>> ldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Fx%2BITXyW6bFaTeaFmVPPnupd9902a >> >>>>>>> kTw2JFdrjT09es%3D&reserved=0 >> >>>>>>> >> >>>>>>> https://www/. >> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-rfcdiff.html&data=05%7C02%7Cflo.d%4 >> >>>>>>> 0ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d7 >> >>>>>>> 34f46dda64a1%7C0%7C0%7C639116952142539728%7CUnknown%7CTWFpbGZsb3d8eyJF >> >>>>>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC >> >>>>>>> IsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Rrg9A8rLNoF0O4aA3%2FFXla2kIS >> >>>>>>> 84N5wH4et%2BUVV%2BaOY%3D&reserved=0 (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%2Fauthors%2Frfc9955-alt-diff.html&data=05%7C02%7Cflo.d% >> >>>>>>> 40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d >> >>>>>>> 734f46dda64a1%7C0%7C0%7C639116952142568667%7CUnknown%7CTWFpbGZsb3d8eyJ >> >>>>>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> >>>>>>> CIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=p5YqLFBllkeyZ%2BeRTVIcPGSHH >> >>>>>>> LB30Qxdwc%2BwnHL8nfo%3D&reserved=0 >> >>>>>>> >> >>>>>>> Diff of the XML: >> >>>>>>> >> >>>>>>> https://www/. >> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-xmldiff1.html&data=05%7C02%7Cflo.d% >> >>>>>>> 40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d >> >>>>>>> 734f46dda64a1%7C0%7C0%7C639116952142596842%7CUnknown%7CTWFpbGZsb3d8eyJ >> >>>>>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> >>>>>>> CIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2B%2FpHzQbW2TvbBYwEEYGSDLG >> >>>>>>> qPkZA1mNjZSNA6eZSpMg%3D&reserved=0 >> >>>>>>> >> >>>>>>> >> >>>>>>> Tracking progress >> >>>>>>> ----------------- >> >>>>>>> >> >>>>>>> The details of the AUTH48 status of your document are here: >> >>>>>>> >> >>>>>>> https://www/. >> >>>>>>> rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7 >> >>>>>>> Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7 >> >>>>>>> C0%7C0%7C639116952142624430%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> >>>>>>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 >> >>>>>>> D%3D%7C40000%7C%7C%7C&sdata=it6iMYLF4xipV5dn6vO82p6dBDn4yKYBOgCye%2FM9 >> >>>>>>> Ccg%3D&reserved=0 >> >>>>>>> >> >>>>>>> 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 >> >>>>> >> >>>>> >> >>>> >> >>> >> >>> <rfc9955_fdchanges.xml> >> >> >> > >> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
