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]
