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]
