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]
