Hello all, With regards to inclusive language:
“Traditional” is the term adopted in the community for cryptographic algorithms that are not quantum resistant. We (the IETF) have in fact stated this is the term, see RFC9794 "Terminology for Post-Quantum Traditional Hybrid Schemes”, which incidentally shares a number of authors with this document. I believe the correct answer is to continue to use “traditional”. With regards to “black-box”, is there a reason this term is the correct term? (I’m familiar with its common use in analysis and inspection; as well as white-box.) Thanks, — Chris Inacio SEC AD > On Wednesday, May 20, 2026 at 11:48 AM, Alanna Paloma > <[email protected] (mailto:[email protected])> wrote: > 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> > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
