Hi Flo and Chris*, *Chris (AD) - This is a friendly reminder that we await your review and approval of the added text in Section 5.
See this diff file: https://www.rfc-editor.org/authors/rfc9955-auth48diff.html Flo - Thank you for your approval. We’ve noted it here: https://queue.rfc-editor.org/final-review/rfc9955/ Thank you, Alanna Paloma RFC Production Center > On Jun 29, 2026, at 1:00 AM, Flo D <[email protected]> wrote: > > OFFICIAL > > Hi Alanna, > > I'm happy with this, thank you very much. > > 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: 26 June 2026 18:54 > To: Nina Bindel <[email protected]> > Cc: Deirdre Connolly <[email protected]>; Flo D <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; Paul Hoffman <[email protected]>; Paul Wouters > <[email protected]>; auth48archive <[email protected]>; RFC > Editor <[email protected]> > Subject: Re: [AD] AUTH48: RFC-to-be 9955 > <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review > > 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]
