OFFICIAL
Hi Alanna,
I'm happy with this, thank you very much.
Flo
Flo D
Deputy CTO for Cyber Policy
and Assessments
[email protected]
Pronouns: she/her
http://www.ncsc.gov.uk/
OFFICIAL
-----Original Message-----
From: Alanna Paloma <[email protected]>
Sent: 26 June 2026 18:54
To: Nina Bindel <[email protected]>
Cc: Deirdre Connolly <[email protected]>; Flo D <[email protected]>;
[email protected]; [email protected]; [email protected];
[email protected]; Paul Hoffman <[email protected]>; Paul Wouters
<[email protected]>; auth48archive <[email protected]>; RFC
Editor <[email protected]>
Subject: Re: [AD] AUTH48: RFC-to-be 9955
<draft-ietf-pquip-hybrid-signature-spectrums-07> for your review
Hi Nina,
Thank you for your reply. No need to submit your approval anywhere else,
replying in this email thread is perfect!
We have noted your approval here:
https://queue.rfc-editor.org/final-review/rfc9955/
We will await approvals from Britta, Deirdre, Flo, and Chris (AD).
Best regards,
Alanna Paloma
RFC Production Center
> On Jun 26, 2026, at 5:02 AM, Nina Bindel <[email protected]> wrote:
>
> Dear all,
>
> You have my approval. Do I need to submit it somewhere formally in addition?
>
> Thank you for all the work you have done, especially thanks to Flo, Britta
> and Alanna for pushing this over the finish line!
>
> Best,
> Nina
>
>
>
> On June 25, 2026 4:56:19 p.m. GMT+01:00, Alanna Paloma
> <[email protected]> wrote:
> Hi Flo and Deirdre,
>
> Thank you for your replies. We have updated the files accordingly.
>
> We will await approvals from each author and Chris (AD) prior to moving this
> document forward in the publication process.
>
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9955.xml
> https://www.rfc-editor.org/authors/rfc9955.txt
> https://www.rfc-editor.org/authors/rfc9955.html
> https://www.rfc-editor.org/authors/rfc9955.pdf
>
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (Final Review
> changes)
> https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (Final Review
> changes side by side)
> https://www.rfc-editor.org/authors/rfc9955-lastdiff.html (last version to
> this one)
> https://www.rfc-editor.org/authors/rfc9955-lastrfcdiff.html (rfcdiff between
> last version and this)
>
> For the Final Review status of this document, please see:
> https://queue.rfc-editor.org/final-review/rfc9955/
>
> Thank you,
> Alanna Paloma
> RFC Production Center
>
>> On Jun 24, 2026, at 8:06 AM, Deirdre Connolly <[email protected]>
>> wrote:
>>
>> One nit,
>>
>> 'Component message algorithm forgery attacks:'
>>
>> I would write 'Component algorithm message forgery attacks', in several
>> locations in section 1.1.
>>
>> > We call this notion 'hybrid unforgeability'; it is a specific type of
>> > hybrid authentication.
>>
>> This definition is used later in the document.
>>
>>
>>
>>
>>
>> On Mon, Jun 22, 2026 at 7:35 PM Alanna Paloma <[email protected]>
>> wrote:
>> Hi Authors and Chris*,
>>
>> *Chris - As the AD, pleases review and approve of the added text in Section
>> 5.
>>
>> See this diff file:
>> https://www.rfc-editor.org/authors/rfc9955-auth48diff.html
>>
>> Authors - Thank you for your reply. The files have been updated accordingly.
>>
>> We will await approvals from each party listed on the Final Review status
>> page below prior to moving this document forward in the publication process.
>>
>> Note: If you would like to send any further updates by way of an updated XML
>> file, please make changes to the most recent XML file (provided below).
>>
>> The files have been posted here (please refresh):
>> https://www.rfc-editor.org/authors/rfc9955.xml
>> https://www.rfc-editor.org/authors/rfc9955.txt
>> https://www.rfc-editor.org/authors/rfc9955.html
>> https://www.rfc-editor.org/authors/rfc9955.pdf
>>
>> The relevant diff files have been posted here:
>> https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff)
>> https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (Final Review
>> changes)
>> https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (Final Review
>> changes side by side)
>> https://www.rfc-editor.org/authors/rfc9955-lastdiff.html (last version to
>> this one)
>> https://www.rfc-editor.org/authors/rfc9955-lastrfcdiff.html (rfcdiff between
>> last version and this)
>>
>> For the Final Review status of this document, please see:
>> https://queue.rfc-editor.org/final-review/rfc9955/
>>
>> Thank you,
>> Alanna Paloma
>> RFC Production Center
>>
>> > On Jun 18, 2026, at 6:48 AM, Flo D <[email protected]> wrote:
>> >
>> > OFFICIAL
>> >
>> > Hi Alanna,
>> >
>> > Britta and I have had another look at the document, I'm attaching the
>> > newest commented version.
>> >
>> > We've now addressed the leftover query - I've made the changes and the
>> > rationale is under the comment.
>> >
>> > There are a few additional changes and suggestions following Britta's
>> > review. These are labelled as [BH] in the document.
>> >
>> > Thank you!
>> > Flo
>> >
>> > Flo D
>> > Deputy CTO for Cyber Policy
>> > and Assessments
>> > [email protected]
>> > Pronouns: she/her
>> > http://www.ncsc.gov.uk/
>> >
>> >
>> >
>> >
>> > OFFICIAL
>> > -----Original Message-----
>> > From: Alanna Paloma <[email protected]>
>> > Sent: 20 May 2026 16:48
>> > To: Flo D <[email protected]>
>> > Cc: [email protected]; [email protected]; Nina Bindel
>> > <[email protected]>; [email protected]; [email protected]; Paul
>> > Hoffman <[email protected]>; Paul Wouters <[email protected]>;
>> > auth48archive <[email protected]>; RFC Editor
>> > <[email protected]>
>> > Subject: Re: AUTH48: RFC-to-be 9955
>> > <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review
>> >
>> > Hi Flo,
>> >
>> > We’ve updated the files with that change. Note that we are awaiting your
>> > response to this query:
>> >
>> >> c) The following terms are used in the document. Please review to ensure
>> >> consistent and correct usage. Let us know if any updates are needed.
>> >>
>> >> component message forgery attack
>> >> component algorithm forgery (and component algorithm forgeries)
>> >> component forgery (and component forgeries)
>> >> component forgery attacks
>> >
>> >
>> > The files have been posted here (please refresh):
>> > https://www.rfc-editor.org/authors/rfc9955.xml
>> > https://www.rfc-editor.org/authors/rfc9955.txt
>> > https://www.rfc-editor.org/authors/rfc9955.html
>> > https://www.rfc-editor.org/authors/rfc9955.pdf
>> >
>> > The relevant diff files have been posted here:
>> > https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff)
>> > https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (AUTH48 changes)
>> > https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (AUTH48
>> > changes side by side)
>> > https://www.rfc-editor.org/authors/rfc9955-lastdiff.html (last version to
>> > this one)
>> > https://www.rfc-editor.org/authors/rfc9955-lastrfcdiff.html (rfcdiff
>> > between last version and this)
>> >
>> > For the AUTH48 status of this document, please see:
>> > https://www.rfc-editor.org/auth48/rfc9955
>> >
>> > Thank you,
>> > Alanna Paloma
>> > RFC Production Center
>> >
>> >> On May 20, 2026, at 12:20 AM, Flo D <[email protected]> wrote:
>> >>
>> >> OFFICIAL
>> >>
>> >> Hi Alanna,
>> >>
>> >> That change sounds fine, thank you.
>> >>
>> >> Flo
>> >>
>> >> Flo D
>> >> Deputy CTO for Cyber Policy
>> >> and Assessments
>> >> [email protected]
>> >> Pronouns: she/her
>> >> http://www.ncsc.gov.uk/
>> >>
>> >>
>> >> OFFICIAL
>> >> -----Original Message-----
>> >> From: Alanna Paloma <[email protected]>
>> >> Sent: 19 May 2026 19:20
>> >> To: Flo D <[email protected]>
>> >> Cc: [email protected]; [email protected]; Nina Bindel
>> >> <[email protected]>; [email protected]; [email protected]; Paul
>> >> Hoffman <[email protected]>; Paul Wouters <[email protected]>;
>> >> auth48archive <[email protected]>; RFC Editor
>> >> <[email protected]>
>> >> Subject: Re: AUTH48: RFC-to-be 9955
>> >> <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review
>> >>
>> >> Hi Flo,
>> >>
>> >> Thank you for your reply. We have updated as requested. Note that we
>> >> have one follow-up question.
>> >>
>> >> ) May we clarify “an example of” by updating it to “which is a type of”?
>> >>
>> >> Current:
>> >> This is an example of a component algorithm forgery, an
>> >> example of a cross-algorithm attack or cross-protocol attack.
>> >>
>> >> Perhaps:
>> >> This is an example of a component algorithm forgery, which is
>> >> a type of a cross-algorithm attack or cross-protocol attack.
>> >>
>> >>
>> >> The files have been posted here (please refresh):
>> >> https://www.rfc-editor.org/authors/rfc9955.xml
>> >> https://www.rfc-editor.org/authors/rfc9955.txt
>> >> https://www.rfc-editor.org/authors/rfc9955.html
>> >> https://www.rfc-editor.org/authors/rfc9955.pdf
>> >>
>> >> The relevant diff files have been posted here:
>> >> https://www.rfc-editor.org/authors/rfc9955-diff.html (comprehensive diff)
>> >> https://www.rfc-editor.org/authors/rfc9955-auth48diff.html (AUTH48
>> >> changes)
>> >> https://www.rfc-editor.org/authors/rfc9955-auth48rfcdiff.html (AUTH48
>> >> changes side by side)
>> >>
>> >> Please review the document carefully and contact us with any further
>> >> updates you may have. Note that we do not make changes once a document
>> >> is published as an RFC.
>> >>
>> >> We will await your response to our follow-up question above as well the
>> >> remaining terminology query.
>> >>
>> >> For the AUTH48 status of this document, please see:
>> >> https://www.rfc-editor.org/auth48/rfc9955
>> >>
>> >> Thank you,
>> >> Alanna Paloma
>> >> RFC Production Center
>> >>
>> >>
>> >>> On May 19, 2026, at 1:00 AM, Flo D <[email protected]> wrote:
>> >>>
>> >>> OFFICIAL
>> >>>
>> >>> Hi Alanna,
>> >>>
>> >>> Sorry for the delay on this. Attached is an updated version. One
>> >>> comments remains to be addressed (terminology (c)), but we will aim to
>> >>> get on this soon.
>> >>>
>> >>> Please let me know if there are any other issues.
>> >>>
>> >>> Flo
>> >>>
>> >>>
>> >>> OFFICIAL
>> >>> -----Original Message-----
>> >>> From: Alanna Paloma <[email protected]>
>> >>> Sent: 18 May 2026 17:45
>> >>> To: Flo D <[email protected]>; [email protected];
>> >>> [email protected]; [email protected]
>> >>> Cc: [email protected]; [email protected]; Paul Hoffman
>> >>> <[email protected]>; Paul Wouters <[email protected]>;
>> >>> auth48archive <[email protected]>; RFC Editor
>> >>> <[email protected]>
>> >>> Subject: Re: AUTH48: RFC-to-be 9955
>> >>> <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review
>> >>>
>> >>> [You don't often get email from [email protected]. Learn why
>> >>> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>> >>>
>> >>> Hi Authors,
>> >>>
>> >>> We're still awaiting your responses to our previous questions before
>> >>> this document can move forward in the publication process. Please let us
>> >>> know if you have any questions.
>> >>>
>> >>> The AUTH48 status page for this document is located here:
>> >>> https://www.rfc-editor.org/auth48/rfc9955
>> >>>
>> >>> Thank you,
>> >>> Alanna Paloma
>> >>> RFC Production Center
>> >>>
>> >>>> On May 11, 2026, at 8:22 AM, Alanna Paloma
>> >>>> <[email protected]> wrote:
>> >>>>
>> >>>> Hi Authors,
>> >>>>
>> >>>> This is another friendly reminder that we await your response to our
>> >>>> previously sent questions. Please let us know if you have any questions.
>> >>>>
>> >>>> The AUTH48 status page for this document is located here:
>> >>>> https://www/.
>> >>>> rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7CFlo.D%40ncsc.gov.uk%7
>> >>>> C54dd52367c1c4e24663d08deb4fce7c2%7C14aa5744ece1474ea2d734f46dda64a1%7
>> >>>> C0%7C0%7C639147195984001873%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
>> >>>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
>> >>>> D%3D%7C0%7C%7C%7C&sdata=SLUDLYOj2lEJXyirGjNHdz8rhFpzeT7DhBCk7RZSyi8%3D
>> >>>> &reserved=0
>> >>>>
>> >>>> Thank you,
>> >>>> Alanna Paloma
>> >>>> RFC Production Center
>> >>>>
>> >>>>> On May 4, 2026, at 8:41 AM, Alanna Paloma
>> >>>>> <[email protected]> wrote:
>> >>>>>
>> >>>>> Hi Authors,
>> >>>>>
>> >>>>> This is a friendly reminder that we are awaiting your response to our
>> >>>>> previously sent questions.
>> >>>>>
>> >>>>> We will wait to hear from you before continuing with the publication
>> >>>>> process.
>> >>>>>
>> >>>>> The AUTH48 status page for this document is located here:
>> >>>>> https://www/
>> >>>>> .rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7CFlo.D%40ncsc.gov.uk
>> >>>>> %7C54dd52367c1c4e24663d08deb4fce7c2%7C14aa5744ece1474ea2d734f46dda64a
>> >>>>> 1%7C0%7C0%7C639147195984182179%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
>> >>>>> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
>> >>>>> yfQ%3D%3D%7C0%7C%7C%7C&sdata=HRdVL6Vq9h5NKqJ4z5kCMqxIBQAVq7cZrBj9FqWR
>> >>>>> ylw%3D&reserved=0
>> >>>>>
>> >>>>> Thank you,
>> >>>>> Alanna Paloma
>> >>>>> RFC Production Center
>> >>>>>
>> >>>>>> On Apr 14, 2026, at 12:52 AM, Flo D <[email protected]> wrote:
>> >>>>>>
>> >>>>>> OFFICIAL
>> >>>>>>
>> >>>>>>
>> >>>>>> Hi Alanna,
>> >>>>>>
>> >>>>>> Thank you. We are discussing amongst the authors and will be able to
>> >>>>>> get back to you soon.
>> >>>>>>
>> >>>>>> Flo
>> >>>>>>
>> >>>>>>
>> >>>>>> OFFICIAL
>> >>>>>> -----Original Message-----
>> >>>>>> From: Alanna Paloma <[email protected]>
>> >>>>>> Sent: 13 April 2026 17:39
>> >>>>>> To: [email protected]; [email protected];
>> >>>>>> [email protected]; Flo D <[email protected]>
>> >>>>>> Cc: [email protected]; [email protected]; Paul Hoffman
>> >>>>>> <[email protected]>; Paul Wouters <[email protected]>;
>> >>>>>> auth48archive <[email protected]>; RFC Editor
>> >>>>>> <[email protected]>
>> >>>>>> Subject: Re: AUTH48: RFC-to-be 9955
>> >>>>>> <draft-ietf-pquip-hybrid-signature-spectrums-07> for your review
>> >>>>>>
>> >>>>>> [You don't often get email from [email protected]. Learn
>> >>>>>> why this is important at
>> >>>>>> https://aka.ms/LearnAboutSenderIdentification ]
>> >>>>>>
>> >>>>>> Greetings,
>> >>>>>>
>> >>>>>> We do not believe we have heard from you regarding this document's
>> >>>>>> readiness for publication. Please review our previous messages
>> >>>>>> describing the AUTH48 process and containing any document-specific
>> >>>>>> questions we may have had.
>> >>>>>>
>> >>>>>> We will wait to hear from you before continuing with the publication
>> >>>>>> process.
>> >>>>>>
>> >>>>>> The AUTH48 status page for this document is located here:
>> >>>>>> https://ww/
>> >>>>>> w.rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7CFlo.D%40ncsc.gov.
>> >>>>>> uk%7C54dd52367c1c4e24663d08deb4fce7c2%7C14aa5744ece1474ea2d734f46dda
>> >>>>>> 64a1%7C0%7C0%7C639147195984205503%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
>> >>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
>> >>>>>> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DSxJz0KRJhcfkl85nS7rl96ouEf4uIe9cE
>> >>>>>> RnBBAWhdQ%3D&reserved=0
>> >>>>>>
>> >>>>>> Thank you,
>> >>>>>> Alanna Paloma
>> >>>>>> RFC Production Center
>> >>>>>>
>> >>>>>>> On Apr 3, 2026, at 9:53 AM, [email protected] wrote:
>> >>>>>>>
>> >>>>>>> Authors,
>> >>>>>>>
>> >>>>>>> While reviewing this document during AUTH48, please resolve (as
>> >>>>>>> necessary) the following questions, which are also in the source
>> >>>>>>> file.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 1) <!--[rfced] Note that we have updated the short title, which
>> >>>>>>> appears in the running header In the PDF output, as follows.
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> ietf-pquip-hybrid-spectrums
>> >>>>>>>
>> >>>>>>> Current:
>> >>>>>>> Hybrid Signature Spectrums
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that
>> >>>>>>> appear in the title) for use on https://www/.
>> >>>>>>> rfc-editor.org%2Fsearch&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100
>> >>>>>>> d6f
>> >>>>>>> 75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%
>> >>>>>>> 7C6
>> >>>>>>> 39116952142108314%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
>> >>>>>>> lYi
>> >>>>>>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C
>> >>>>>>> 400
>> >>>>>>> 00%7C%7C%7C&sdata=VBi8v52NykkpgSEnXnipU97KOPrxj01Do91EFkablEU%3D&re
>> >>>>>>> ser
>> >>>>>>> ved=0. -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 3) <!--[rfced] We note that both of the following terms are used in
>> >>>>>>> the document (note "Project" vs. "Process"). Should these be made
>> >>>>>>> consistent?
>> >>>>>>>
>> >>>>>>> NIST Post-Quantum Cryptography Standardization Project NIST
>> >>>>>>> Post-Quantum Cryptography Standardization Process
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Research has indicated
>> >>>>>>> that implementation-independent attacks published in 2023 or
>> >>>>>>> earlier had broken 48% of the proposals in Round 1 of the NIST
>> >>>>>>> Post-Quantum Cryptography Standardization Project, 25% of the
>> >>>>>>> proposals not broken in Round 1, and 36% of the proposals selected
>> >>>>>>> by NIST for Round 2 [QRCSP].
>> >>>>>>> ...
>> >>>>>>> Of note, some next-generation algorithms have received considerable
>> >>>>>>> analysis, for example, following attention gathered during the NIST
>> >>>>>>> Post-Quantum Cryptography Standardization Process [NIST_PQC_FAQ].
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 4) <!--[rfced] FYI - We updated "25% of the proposals not broken in
>> >>>>>>> Round 1" as follows for clarity.
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Research has indicated
>> >>>>>>> that implementation-independent attacks published in 2023 or
>> >>>>>>> earlier had broken 48% of the proposals in Round 1 of the NIST
>> >>>>>>> Post-Quantum Cryptography Standardization Project, 25% of the
>> >>>>>>> proposals not broken in Round 1, and 36% of the proposals selected
>> >>>>>>> by NIST for Round 2 [QRCSP].
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> Research indicates
>> >>>>>>> that implementation-independent attacks published in 2023 or
>> >>>>>>> earlier had broken 48% of the proposals in Round 1 of the NIST
>> >>>>>>> Post-Quantum Cryptography Standardization Project, 25% of the
>> >>>>>>> proposals not broken by the end of Round 1, and 36% of the
>> >>>>>>> proposals selected by NIST for Round 2 [QRCSP].
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 5) <!-- [rfced] We were unable to find the quoted text below in
>> >>>>>>> [RFC9794].
>> >>>>>>> Is this quote from [RFC9794] or another reference?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> This is different from [RFC9794] where the term is used as a
>> >>>>>>> specific instantiation of hybrid schemes such that "where multiple
>> >>>>>>> cryptographic algorithms are combined to form a single key or
>> >>>>>>> signature such that they can be treated as a single atomic object
>> >>>>>>> at the protocol level."
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 6) <!--[rfced] To improve readability, may we break up this long
>> >>>>>>> sentence into two sentences and update as follows?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> While it often makes sense for security purposes to require that
>> >>>>>>> the security of the component schemes is based on the hardness of
>> >>>>>>> different cryptographic assumptions, in other cases hybrid schemes
>> >>>>>>> might be motivated, e.g., by interoperability of variants on the
>> >>>>>>> same scheme and as such both component schemes are based on the
>> >>>>>>> same hardness assumption (e.g., both post-quantum assumptions or
>> >>>>>>> even both the same concrete assumption such as Ring LWE).
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> For security purposes, it often makes sense to require that the
>> >>>>>>> security of the component schemes be based on the hardness of
>> >>>>>>> different cryptographic assumptions, but in some cases, hybrid
>> >>>>>>> schemes might be motivated, e.g., by interoperability of variants
>> >>>>>>> on the same scheme. As such, both component schemes are based on
>> >>>>>>> the same hardness assumption (e.g., both post-quantum assumptions
>> >>>>>>> or even both the same concrete assumption, such as Ring Learning
>> >>>>>>> With Errors (LWE)).
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 7) <!-- [rfced] Is "CRYSTALS-DILITHIUM" another name for "ML-DSA"?
>> >>>>>>> Or are they separate schemes? Please review and let us know if/how
>> >>>>>>> this text may be clarified.
>> >>>>>>>
>> >>>>>>> Current:
>> >>>>>>> For example, the
>> >>>>>>> signature scheme Module-Lattice-Based Digital Signature Algorithm
>> >>>>>>> (ML-DSA) [MLDSA] (also known as CRYSTALS-DILITHIUM) follows the
>> >>>>>>> well- known Fiat-Shamir transform [FS] to construct the signature
>> >>>>>>> scheme but also relies on rejection sampling that is known to give
>> >>>>>>> cache side channel information (although this does not lead to a
>> >>>>>>> known attack).
>> >>>>>>>
>> >>>>>>> Section 1.2 of [MLDSA] (FIPS 204) states the following about ML-DSA
>> >>>>>>> and CRYSTALS-DILITHIUM:
>> >>>>>>> ML-DSA is derived from one of the selected schemes,
>> >>>>>>> CRYSTALS-DILITHIUM
>> >>>>>>> [5 , 6 ], and is intended to protect sensitive U.S. Government
>> >>>>>>> information well into the foreseeable future, including after the
>> >>>>>>> advent of cryptographically relevant quantum computers. For the
>> >>>>>>> differences between ML-DSA and CRYSTALS- DILITHIUM, see Appendix D.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 8) <!-- [rfced] The second sentence below seems to be saying the
>> >>>>>>> same thing as the first. Should the second sentence be removed?
>> >>>>>>>
>> >>>>>>> Current:
>> >>>>>>> Hybrid unforgeability is a specific type of hybrid authentication,
>> >>>>>>> where the security assumption for the scheme (e.g., EUF-CMA) is
>> >>>>>>> maintained as long as at least one of the component schemes
>> >>>>>>> maintains that security assumption. We call this notion 'hybrid
>> >>>>>>> unforgeability'; it is a specific type of hybrid authentication.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> Hybrid unforgeability is a specific type of hybrid authentication,
>> >>>>>>> where the security assumption for the scheme (e.g., EUF-CMA) is
>> >>>>>>> maintained as long as at least one of the component schemes
>> >>>>>>> maintains that security assumption.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 9) <!-- [rfced] For the ease of the reader, may we update
>> >>>>>>> "description below" and "discussion below" to a section number? If
>> >>>>>>> so, please confirm that Section 1.3.5 is correct.
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> There might be, however, other goals in competition with this one,
>> >>>>>>> such as backward-compatibility - referring to the property where a
>> >>>>>>> hybrid signature may be verified by only verifying one component
>> >>>>>>> signature (see description below).
>> >>>>>>> ...
>> >>>>>>> For more details, we refer to our discussion below.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> There might be, however, other goals in competition with this one,
>> >>>>>>> such as backward compatibility - referring to the property where a
>> >>>>>>> hybrid signature may be verified by only verifying one component
>> >>>>>>> signature (see Section 1.3.5).
>> >>>>>>> ...
>> >>>>>>> For more details, refer to Section 1.3.5.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 10) <!-- [rfced] We are having trouble understanding the first part
>> >>>>>>> of this sentence. Would revising as shown below improve clarity
>> >>>>>>> while retaining the intended meaning?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Use cases where a hybrid scheme is used with, e.g., EUF-CMA
>> >>>>>>> security assumed for only one component scheme generally use hybrid
>> >>>>>>> techniques for their 'functional transition' pathway support.
>> >>>>>>> ...
>> >>>>>>> In contrast, use cases where a hybrid scheme is used with e.g.,
>> >>>>>>> EUF- CMA security assumed for both component schemes without
>> >>>>>>> prioritisation between them can use hybrid techniques for both
>> >>>>>>> functional transition and security transition ...
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> In some use cases, a hybrid scheme is used with (for example)
>> >>>>>>> EUF-CMA security assumed for only one component scheme; these cases
>> >>>>>>> generally use hybrid techniques for their 'functional transition'
>> >>>>>>> pathway support.
>> >>>>>>> ...
>> >>>>>>> In contrast, in other use cases, a hybrid scheme is used with (for
>> >>>>>>> example) EUF- CMA security assumed for both component schemes
>> >>>>>>> without prioritisation between them; these cases can use hybrid
>> >>>>>>> techniques for both functional transition and security transition ...
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 11) <!-- [rfced] How may we update "algorithms/the" here?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> For instance, this can intuitively be seen in cases of a message
>> >>>>>>> containing a context note on hybrid authentication, that is then
>> >>>>>>> signed by all component algorithms/the hybrid signature scheme.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> For instance, this can intuitively be seen in cases of a message
>> >>>>>>> containing a context note on hybrid authentication, that is then
>> >>>>>>> signed by all component algorithms in the hybrid signature scheme.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 12) <!-- [rfced] Should 'component digital signatures "categories"'
>> >>>>>>> be updated to use singular 'signature' as shown in Perhaps A,
>> >>>>>>> recast as shown in Perhaps B, or revised in some other way?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Hybrid generality means that a general signature combiner is
>> >>>>>>> defined, based on inherent and common structures of component
>> >>>>>>> digital signatures "categories."
>> >>>>>>>
>> >>>>>>> Perhaps A:
>> >>>>>>> Hybrid generality means that a general signature combiner is
>> >>>>>>> defined based on inherent and common structures of component
>> >>>>>>> digital signature "categories".
>> >>>>>>>
>> >>>>>>> Perhaps B:
>> >>>>>>> Hybrid generality means that a general signature combiner is
>> >>>>>>> defined based on inherent and common structures of "categories" of
>> >>>>>>> the component digital signatures.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 13) <!-- [rfced] We could not find any mention of "space" in
>> >>>>>>> draft-ietf-tls-hybrid-design (RFC-to-be 9954). Please review and
>> >>>>>>> let us know how this citation may be updated.
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Similarly to space considerations in [I-D.ietf-tls-hybrid-design],
>> >>>>>>> hybrid signature constructions are expected to be as space
>> >>>>>>> performant as possible.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 14) <!-- [rfced] We made a few changes to Figures 1 and 2 (e.g.,
>> >>>>>>> updated spacing, added articles, and included punctuation). Please
>> >>>>>>> review.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 15) <!-- [rfced] Will readers understand what is meant by "hybrid"
>> >>>>>>> and "hybrids"
>> >>>>>>> (noun) in these sentences? Should these be updated to "hybrid
>> >>>>>>> signature"
>> >>>>>>> and "hybrid signatures" (or to something else), or is the current
>> >>>>>>> clear?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Under Weak
>> >>>>>>> Non-Separability, if one of the component signatures of a hybrid is
>> >>>>>>> removed artifacts of the hybrid will remain (in the message,
>> >>>>>>> signature, or at the protocol level, etc.).
>> >>>>>>> ...
>> >>>>>>> Note that in this latter case, it is not possible for an adversary
>> >>>>>>> to strip one of the component signatures or use a component of the
>> >>>>>>> hybrid to create a forgery for a component algorithm.
>> >>>>>>> ...
>> >>>>>>> applies equally to any guidance or
>> >>>>>>> policy direction that specifies that at least one component
>> >>>>>>> algorithm of the hybrid has passed some certification type while
>> >>>>>>> not specifying requirements on the other component.
>> >>>>>>> ...
>> >>>>>>> however, we use it as motivation to highlight some points that
>> >>>>>>> implementers of hybrids may wish to consider when following any
>> >>>>>>> guidance documents that specify ...
>> >>>>>>> ...
>> >>>>>>> This type of need for approval (i.e., a requirement that an
>> >>>>>>> implementer is looking to follow regarding approval or
>> >>>>>>> certification of the software module implementation of a hybrid or
>> >>>>>>> its component
>> >>>>>>> algorithms) can drive some logistical decisions on what types of
>> >>>>>>> hybrids an implementer should consider.
>> >>>>>>> ...
>> >>>>>>> If the hybrid signature is
>> >>>>>>> stripped, such that a single component signature is submitted to a
>> >>>>>>> verification algorithm for that component along with the message
>> >>>>>>> that was signed by the hybrid, the result would be an EUF-CMA
>> >>>>>>> forgery for the component signature.
>> >>>>>>> ...
>> >>>>>>> Thus, if EUF-CMA security for hybrids is considered to be
>> >>>>>>> informally defined in the straightforward way as ...
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 16) <!-- [rfced] How may we clarify "message/inner" here?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> In another example, under nested signatures the verifier could be
>> >>>>>>> tricked into interpreting a new message as the message/inner
>> >>>>>>> signature combination and verify only the outer signature.
>> >>>>>>>
>> >>>>>>> Perhaps A:
>> >>>>>>> In another example, under nested signatures, the verifier could be
>> >>>>>>> tricked into interpreting a new message as the message and inner
>> >>>>>>> signature combination and verify only the outer signature.
>> >>>>>>>
>> >>>>>>> Perhaps B:
>> >>>>>>> In another example, under nested signatures, the verifier could be
>> >>>>>>> tricked into interpreting a new message as the combination of the
>> >>>>>>> message and inner signature and verify only the outer signature.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 17) <!--[rfced] To improve readability, may we update the second
>> >>>>>>> sentence below as follows? The first sentence is included for
>> >>>>>>> context.
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> The verifier could indeed ignore the artifact, hence the scheme
>> >>>>>>> achieving only weak non-separability and not strong
>> >>>>>>> non-separability. It is rather that an artifact exists that could
>> >>>>>>> be identified if an investigation occurred, etc.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> The verifier could indeed ignore the artifact, resulting in the
>> >>>>>>> scheme achieving only weak non-separability and not strong
>> >>>>>>> non-separability. However, an existing artifact could be identified
>> >>>>>>> if an investigation occurred.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 18) <!-- [rfced] Will "As can be seen" be clear to readers in these
>> >>>>>>> two sentences?
>> >>>>>>> Could it be updated to "As shown in Table 1" in the first sentence
>> >>>>>>> and removed in the second sentence?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> As can be seen, while concatenation may appear to refer to a single
>> >>>>>>> type of combiner, there are in fact several possible artifact
>> >>>>>>> locations depending on implementation choices.
>> >>>>>>> ...
>> >>>>>>> However, as can be seen, this does not imply that every
>> >>>>>>> implementation using concatenation fails to achieve non-
>> >>>>>>> separability.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> As shown in Table 1, while concatenation may appear to refer to a
>> >>>>>>> single type of combiner, there are in fact several possible
>> >>>>>>> artifact locations depending on implementation choices.
>> >>>>>>> ...
>> >>>>>>> However, this does not imply that
>> >>>>>>> every implementation using concatenation fails to achieve non-
>> >>>>>>> separability.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 19) <!-- [rfced] The quoted text below no longer appears at the URL
>> >>>>>>> provided for
>> >>>>>>> [NIST_PQC_FAQ]:
>> >>>>>>> https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs.
>> >>>>>>> That page was lasted updated on 19 November 2025.
>> >>>>>>>
>> >>>>>>> We found an archived URL from the Internet Archive from 5 July 2022
>> >>>>>>> (the original date used for this reference):
>> >>>>>>> https://web/.
>> >>>>>>> archive.org%2Fweb%2F20220705163944%2Fhttps%3A%2F%2Fcsrc.nist.gov%2F
>> >>>>>>> Pro
>> >>>>>>> jects%2F&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e260
>> >>>>>>> 8de
>> >>>>>>> 997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6391169521421
>> >>>>>>> 503
>> >>>>>>> 52%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
>> >>>>>>> MCI
>> >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&
>> >>>>>>> sda
>> >>>>>>> ta=NjyLiA1Mk5tY1A1Tzo18PUuBBsregK0DrcIQ8TCv5CU%3D&reserved=0
>> >>>>>>> post-quantum-cryptography/faqs
>> >>>>>>>
>> >>>>>>> May we update this reference to use the archived URL?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Assume that in a [hybrid] signature, _one signature is generated
>> >>>>>>> with a NIST-approved signature scheme as specified in FIPS 186,
>> >>>>>>> while another signature(s) can be generated using different
>> >>>>>>> schemes_, e.g., ones that are not currently specified in NIST
>> >>>>>>> standards..._hybrid signatures can be accommodated by current
>> >>>>>>> standards in FIPS mode, as defined in FIPS 140, provided at least
>> >>>>>>> one of the component methods is a properly implemented, NIST-
>> >>>>>>> approved signature algorithm_. For the purposes of FIPS 140
>> >>>>>>> validation, any signature that is generated by a non-approved
>> >>>>>>> component scheme would not be considered a security function, since
>> >>>>>>> the NIST-approved component is regarded as assuring the validity of
>> >>>>>>> the hybrid signature. [NIST_PQC_FAQ] ...
>> >>>>>>> [NIST_PQC_FAQ]
>> >>>>>>> National Institute of Standards and Technology (NIST),
>> >>>>>>> "Post-Quantum Cryptography FAQs", 5 July 2022,
>> >>>>>>> <https://csrc.nist.gov/Projects/post-quantum-cryptography/
>> >>>>>>> faqs>.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 20) <!-- [rfced] We do not see "Generality" used elsewhere in
>> >>>>>>> Section 4. Should it be removed from the title of Figure 2?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Figure 2: Generality / Need for Approval Spectrum
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> Figure 2: Need for Approval Spectrum
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 21) <!-- [rfced] Is "game" the correct word choice here? Or would
>> >>>>>>> "assumption"
>> >>>>>>> (used earlier in the paragraph) be better?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Namely, the most straightforward extension of the traditional
>> >>>>>>> EUF-CMA security game would be that an adversary can request hybrid
>> >>>>>>> signatures for messages of their choosing and succeeds if they are
>> >>>>>>> able to produce a valid hybrid signature for a message that was not
>> >>>>>>> part of an earlier request.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 22) <!--[rfced] We are having difficulty parsing this sentence,
>> >>>>>>> particularly "is considered to be informally defined in the
>> >>>>>>> straightforward way as that an adversary can request...". Please
>> >>>>>>> review and let us know how it may be updated for clarity.
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Thus, if EUF-CMA security for hybrids is considered to be
>> >>>>>>> informally defined in the straightfoward way as that an adversary
>> >>>>>>> can request hybrid signatures for messages of their choosing and
>> >>>>>>> succeeds if they are able to produce a valid hybrid signature for a
>> >>>>>>> message that was not part of an earlier request, implicit
>> >>>>>>> requirements must hold in order to avoid real-world implications.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> Thus, if the straightforward EUF-CMA security assumption for
>> >>>>>>> hybrids is that an adversary requests hybrid signatures for
>> >>>>>>> messages of their choosing and succeeds if they are able to produce
>> >>>>>>> a valid hybrid signature for a message that was not part of an
>> >>>>>>> earlier request, implicit requirements must hold in order to avoid
>> >>>>>>> real-world implications.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 23) <!-- [rfced] Please review the relationship between
>> >>>>>>> "cross-protocol attack"
>> >>>>>>> and "component algorithm forgery" in the sentences below and let us
>> >>>>>>> know if updates are needed for consistency. Also, in the last
>> >>>>>>> sentence below (starts with "Otherwise"), perhaps "which can be
>> >>>>>>> seen as a type of cross-protocol attack" can be removed as it is
>> >>>>>>> mentioned in the previous sentence.
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> such as cross-protocol attacks (e.g., component algorithm
>> >>>>>>> forgeries).
>> >>>>>>> ...
>> >>>>>>> This is an
>> >>>>>>> example of a component algorithm forgery, a.k.a. a case of cross-
>> >>>>>>> algorithm attack or cross-protocol attack.
>> >>>>>>> ...
>> >>>>>>> Namely, either component
>> >>>>>>> algorithm forgeries, a.k.a. cross-protocol attacks, must be out of
>> >>>>>>> scope for the use case or the hybrid signature choice must be
>> >>>>>>> strongly non-separable. Otherwise, component algorithm forgeries,
>> >>>>>>> which can be seen as a type of cross-protocol attack, affect the
>> >>>>>>> type of EUF-CMA properties offered ...
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> such as cross-protocol attacks (a.k.a. component algorithm
>> >>>>>>> forgeries).
>> >>>>>>> ...
>> >>>>>>> This is an
>> >>>>>>> example of a component algorithm forgery (a.k.a. cross- algorithm
>> >>>>>>> attack or cross-protocol attack).
>> >>>>>>> ...
>> >>>>>>> Namely, either component
>> >>>>>>> algorithm forgeries (a.k.a. cross-protocol attacks) must be out of
>> >>>>>>> scope for the use case or the hybrid signature choice must be
>> >>>>>>> strongly non-separable. Otherwise, component algorithm forgeries
>> >>>>>>> affect the type of EUF-CMA properties offered ...
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 24) <!--[rfced] May we update "additional" to "in addition" in this
>> >>>>>>> sentence?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> Since the goal of backwards compatibility is usually to allow
>> >>>>>>> legacy systems without any software change to be able to process
>> >>>>>>> hybrid signatures, all differences between the legacy signature
>> >>>>>>> format and the hybrid signature format must be allowed to be
>> >>>>>>> ignored, including skipping verification of signatures additional
>> >>>>>>> to the classical signature.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> Since the goal of backwards compatibility is usually to allow
>> >>>>>>> legacy systems without any software change to be able to process
>> >>>>>>> hybrid signatures, all differences between the legacy signature
>> >>>>>>> format and the hybrid signature format must be allowed to be
>> >>>>>>> ignored, including skipping verification of signatures in addition
>> >>>>>>> to the classical signature.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 25) <!-- [rfced] This reference currently points to a paper made
>> >>>>>>> available via Ronald L. Rivest's MIT faculty page. This paper is
>> >>>>>>> also available for free on ACM Digital Library (which is likely
>> >>>>>>> more stable). Would you like this reference to point to the version
>> >>>>>>> on ACM Digital Library or keep the current version?
>> >>>>>>>
>> >>>>>>> Current:
>> >>>>>>> [RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
>> >>>>>>> Obtaining Digital Signatures and Public-Key
>> >>>>>>> Cryptosystems",
>> >>>>>>> <https://people.csail.mit.edu/rivest/Rsapaper.pdf>.
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> [RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
>> >>>>>>> Obtaining Digital Signatures and Public-Key
>> >>>>>>> Cryptosystems", Communications of the ACM, vol. 21, no. 2,
>> >>>>>>> pp. 120-126, DOI 10.1145/359340.359342,
>> >>>>>>> <https://doi.org/10.1145/359340.359342>.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 26) <!-- [rfced] We do not see "template" in ietf-tls-hybrid-design
>> >>>>>>> (RFC-to-be 9954). Would another term be better here?
>> >>>>>>>
>> >>>>>>> Original:
>> >>>>>>> This document is based on the template of
>> >>>>>>> [I-D.ietf-tls-hybrid-design].
>> >>>>>>>
>> >>>>>>> Perhaps:
>> >>>>>>> This document is based on the hybrid key exchange defined in
>> >>>>>>> [RFC9954].
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 27) <!-- [rfced] Font styling
>> >>>>>>>
>> >>>>>>> a) Use of <tt>
>> >>>>>>>
>> >>>>>>> This file lists terms enclosed in <tt> in this document:
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-TT.txt&data=05%7C02%7Cflo.d%40ncsc.
>> >>>>>>> gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f
>> >>>>>>> 46d
>> >>>>>>> da64a1%7C0%7C0%7C639116952142225842%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
>> >>>>>>> 0eU
>> >>>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
>> >>>>>>> ldU
>> >>>>>>> IjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=LhwRtGzgINulI5KXwwS3%2B7wmmpXJ5
>> >>>>>>> lEK
>> >>>>>>> sa1WPvzUEzQ%3D&reserved=0
>> >>>>>>>
>> >>>>>>> Some of these terms appear both with and without <tt>. For example,
>> >>>>>>> we see "[hybrid] signatures" and "[hybrid]" enclosed in <tt>, but
>> >>>>>>> we also see instances of "[hybrid]" and "hybrid" without <tt>.
>> >>>>>>> Please review to ensure the usage of <tt> is correct and
>> >>>>>>> consistent. Let us know if any updates are needed using OLD/NEW
>> >>>>>>> format.
>> >>>>>>>
>> >>>>>>> Note: In the HTML and PDF outputs, <tt> yields fixed-width font. In
>> >>>>>>> the
>> >>>>>>> TXT output, there is no change.
>> >>>>>>>
>> >>>>>>> b) Use of <em>
>> >>>>>>>
>> >>>>>>> This is only used in the direct quote in Section 4. The emphasis
>> >>>>>>> may be difficult to see in the TXT output. Please review.
>> >>>>>>>
>> >>>>>>> Note: In the HTML and PDF outputs, <em> yields italics. In the TXT
>> >>>>>>> output,
>> >>>>>>> <em> yields an underscore before and after.
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 28) <!-- [rfced] Terminology
>> >>>>>>>
>> >>>>>>> a) Should the four instances of "scale" in the document be updated
>> >>>>>>> to "spectrum"?
>> >>>>>>>
>> >>>>>>> Current:
>> >>>>>>> Non-separability is not a singular definition but rather is a
>> >>>>>>> scale, representing degrees of separability hardness, visualized in
>> >>>>>>> Figure 1.
>> >>>>>>> ...
>> >>>>>>> Third on the scale is the Strong Non-Separability notion, in which
>> >>>>>>> separability detection is dependent on artifacts in the signature
>> >>>>>>> itself.
>> >>>>>>> ...
>> >>>>>>> In this respect, there is a scale of approval that developers may
>> >>>>>>> consider as to whether they are using at least one approved
>> >>>>>>> component algorithm implementation ...
>> >>>>>>> ...
>> >>>>>>> We provide a scale for the different nuances of approval of the
>> >>>>>>> hybrid combiners, where "approval" means that a software
>> >>>>>>> implementation of a component algorithm can be used unmodified for
>> >>>>>>> creation of the hybrid signature.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> b) In Table 2, should instances of "cert" and "certs" be updates to
>> >>>>>>> "certificate" and "certificates"?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> c) The following terms are used in the document. Please review to
>> >>>>>>> ensure consistent and correct usage. Let us know if any updates are
>> >>>>>>> needed.
>> >>>>>>>
>> >>>>>>> component message forgery attack
>> >>>>>>> component algorithm forgery (and component algorithm forgeries)
>> >>>>>>> component forgery (and component forgeries) component forgery
>> >>>>>>> attacks
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 29) <!-- [rfced] Abbreviations
>> >>>>>>>
>> >>>>>>> a) FYI - We have added expansions for the following abbreviations
>> >>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>> >>>>>>> expansion in the document carefully to ensure correctness.
>> >>>>>>>
>> >>>>>>> Great Multivariate Short Signature (GeMSS) Learning With Errors
>> >>>>>>> (LWE) Module-Lattice-Based Digital Signature Algorithm (ML-DSA)
>> >>>>>>> Post-Quantum Traditional (PQ/T)
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> b) Both the expansion and the acronym for the following terms are
>> >>>>>>> used throughout the document. Would you like to update to using the
>> >>>>>>> expansion upon first usage and the acronym for the rest of the
>> >>>>>>> document?
>> >>>>>>>
>> >>>>>>> Simultaneous Verification (SV)
>> >>>>>>> Strong Non-Separability (SNS)
>> >>>>>>> Weak Non-Separability (WNS)
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 30) <!-- [rfced] Please review the "Inclusive Language" portion of
>> >>>>>>> the online Style Guide <https://www/
>> >>>>>>> .rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=0
>> >>>>>>> 5%7
>> >>>>>>> C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa
>> >>>>>>> 574
>> >>>>>>> 4ece1474ea2d734f46dda64a1%7C0%7C0%7C639116952142243485%7CUnknown%7C
>> >>>>>>> TWF
>> >>>>>>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
>> >>>>>>> IsI
>> >>>>>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=OAKGJ1JUFGfG
>> >>>>>>> 4S7 F5JNLrFZvMbNeMhgI%2BBlrSEfJwPU%3D&reserved=0>
>> >>>>>>> and let us know if any changes are needed. Updates of this nature
>> >>>>>>> typically result in more precise language, which is helpful for
>> >>>>>>> readers.
>> >>>>>>>
>> >>>>>>> For example, please consider whether "black-box" should be updated.
>> >>>>>>>
>> >>>>>>> In addition, please consider whether "traditional" should be
>> >>>>>>> updated for clarity. While the NIST website indicates that this
>> >>>>>>> term is potentially biased, it is also ambiguous. "Traditional" is
>> >>>>>>> a subjective term, as it is not the same for everyone.
>> >>>>>>>
>> >>>>>>> Link to NIST website:
>> >>>>>>> https://web/.
>> >>>>>>> archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.gov%2Fn
>> >>>>>>> ist
>> >>>>>>> -research-library%2Fnist-technical-series-publications-author-instr
>> >>>>>>> uct
>> >>>>>>> ions%23table1&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a
>> >>>>>>> 7e2
>> >>>>>>> 608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C63911695
>> >>>>>>> 214
>> >>>>>>> 2266275%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA
>> >>>>>>> uMD
>> >>>>>>> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7
>> >>>>>>> C%7
>> >>>>>>> C&sdata=KjcOH4cMH6dmM13%2B13OD%2BAjDTx1XlYsjUKX%2BJC65ue4%3D&reserv
>> >>>>>>> ed=
>> >>>>>>> 0
>> >>>>>>> -->
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Thank you.
>> >>>>>>>
>> >>>>>>> Alanna Paloma and Rebecca VanRheenen RFC Production Center
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Apr 3, 2026, at 9:48 AM, [email protected] wrote:
>> >>>>>>>
>> >>>>>>> *****IMPORTANT*****
>> >>>>>>>
>> >>>>>>> Updated 2026/04/03
>> >>>>>>>
>> >>>>>>> RFC Author(s):
>> >>>>>>> --------------
>> >>>>>>>
>> >>>>>>> Instructions for Completing AUTH48
>> >>>>>>>
>> >>>>>>> Your document has now entered AUTH48. Once it has been reviewed and
>> >>>>>>> approved by you and all coauthors, it will be published as an RFC.
>> >>>>>>> If an author is no longer available, there are several remedies
>> >>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>> >>>>>>>
>> >>>>>>> You and you coauthors are responsible for engaging other parties
>> >>>>>>> (e.g., Contributors or Working Group) as necessary before providing
>> >>>>>>> your approval.
>> >>>>>>>
>> >>>>>>> Planning your review
>> >>>>>>> ---------------------
>> >>>>>>>
>> >>>>>>> Please review the following aspects of your document:
>> >>>>>>>
>> >>>>>>> * RFC Editor questions
>> >>>>>>>
>> >>>>>>> Please review and resolve any questions raised by the RFC Editor
>> >>>>>>> that have been included in the XML file as comments marked as
>> >>>>>>> follows:
>> >>>>>>>
>> >>>>>>> <!-- [rfced] ... -->
>> >>>>>>>
>> >>>>>>> These questions will also be sent in a subsequent email.
>> >>>>>>>
>> >>>>>>> * Changes submitted by coauthors
>> >>>>>>>
>> >>>>>>> Please ensure that you review any changes submitted by your
>> >>>>>>> coauthors. We assume that if you do not speak up that you agree to
>> >>>>>>> changes submitted by your coauthors.
>> >>>>>>>
>> >>>>>>> * Content
>> >>>>>>>
>> >>>>>>> Please review the full content of the document, as this cannot
>> >>>>>>> change once the RFC is published. Please pay particular attention
>> >>>>>>> to:
>> >>>>>>> - IANA considerations updates (if applicable)
>> >>>>>>> - contact information
>> >>>>>>> - references
>> >>>>>>>
>> >>>>>>> * Copyright notices and legends
>> >>>>>>>
>> >>>>>>> Please review the copyright notice and legends as defined in RFC
>> >>>>>>> 5378 and the Trust Legal Provisions (TLP –
>> >>>>>>> https://trustee.ietf.org/license-info).
>> >>>>>>>
>> >>>>>>> * Semantic markup
>> >>>>>>>
>> >>>>>>> Please review the markup in the XML file to ensure that elements of
>> >>>>>>> content are correctly tagged. For example, ensure that <sourcecode>
>> >>>>>>> and <artwork> are set correctly. See details at
>> >>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>> >>>>>>>
>> >>>>>>> * Formatted output
>> >>>>>>>
>> >>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>> >>>>>>> formatted output, as generated from the markup in the XML file, is
>> >>>>>>> reasonable. Please note that the TXT will have formatting
>> >>>>>>> limitations compared to the PDF and HTML.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Submitting changes
>> >>>>>>> ------------------
>> >>>>>>>
>> >>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as
>> >>>>>>> all
>> >>>>>>> the parties CCed on this message need to see your changes. The
>> >>>>>>> parties
>> >>>>>>> include:
>> >>>>>>>
>> >>>>>>> * your coauthors
>> >>>>>>>
>> >>>>>>> * [email protected] (the RPC team)
>> >>>>>>>
>> >>>>>>> * other document participants, depending on the stream (e.g.,
>> >>>>>>> IETF Stream participants are your working group chairs, the
>> >>>>>>> responsible ADs, and the document shepherd).
>> >>>>>>>
>> >>>>>>> * [email protected], which is a new archival mailing list
>> >>>>>>> to preserve AUTH48 conversations; it is not an active discussion
>> >>>>>>> list:
>> >>>>>>>
>> >>>>>>> * More info:
>> >>>>>>>
>> >>>>>>> https://mail/
>> >>>>>>> archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P
>> >>>>>>> 8O4Zc&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997
>> >>>>>>> b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C639116952142368582%
>> >>>>>>> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
>> >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=
>> >>>>>>> 3hJ9a0AMEsdhemsdTdZX038KHPoEQJUpQooAVBOY4O4%3D&reserved=0
>> >>>>>>>
>> >>>>>>> * The archive itself:
>> >>>>>>>
>> >>>>>>> https://mail/
>> >>>>>>> archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cflo
>> >>>>>>> .d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474e
>> >>>>>>> a2d734f46dda64a1%7C0%7C0%7C639116952142387914%7CUnknown%7CTWFpbGZsb3d8
>> >>>>>>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
>> >>>>>>> FpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=sj%2F9zuIGXxz0auXp1vt54j
>> >>>>>>> LYrSA5NPJ8qA1jJ1jsqlQ%3D&reserved=0
>> >>>>>>>
>> >>>>>>> * Note: If only absolutely necessary, you may temporarily opt out
>> >>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>> >>>>>>> If needed, please add a note at the top of the message that you
>> >>>>>>> have dropped the address. When the discussion is concluded,
>> >>>>>>> [email protected] will be re-added to the CC list and
>> >>>>>>> its addition will be noted at the top of the message.
>> >>>>>>>
>> >>>>>>> You may submit your changes in one of two ways:
>> >>>>>>>
>> >>>>>>> An update to the provided XML file
>> >>>>>>> — OR —
>> >>>>>>> An explicit list of changes in this format
>> >>>>>>>
>> >>>>>>> Section # (or indicate Global)
>> >>>>>>>
>> >>>>>>> OLD:
>> >>>>>>> old text
>> >>>>>>>
>> >>>>>>> NEW:
>> >>>>>>> new text
>> >>>>>>>
>> >>>>>>> You do not need to reply with both an updated XML file and an
>> >>>>>>> explicit
>> >>>>>>> list of changes, as either form is sufficient.
>> >>>>>>>
>> >>>>>>> We will ask a stream manager to review and approve any changes that
>> >>>>>>> seem beyond editorial in nature, e.g., addition of new text, deletion
>> >>>>>>> of text, and technical changes. Information about stream managers
>> >>>>>>> can
>> >>>>>>> be found in the FAQ. Editorial changes do not require approval from
>> >>>>>>> a stream manager.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Approving for publication
>> >>>>>>> --------------------------
>> >>>>>>>
>> >>>>>>> To approve your RFC for publication, please reply to this email
>> >>>>>>> stating that you approve this RFC for publication. Please use ‘REPLY
>> >>>>>>> ALL’, as all the parties CCed on this message need to see your
>> >>>>>>> approval.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Files
>> >>>>>>> -----
>> >>>>>>>
>> >>>>>>> The files are available here:
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955.xml&data=05%7C02%7Cflo.d%40ncsc.gov
>> >>>>>>> .uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda6
>> >>>>>>> 4a1%7C0%7C0%7C639116952142405899%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
>> >>>>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
>> >>>>>>> yfQ%3D%3D%7C40000%7C%7C%7C&sdata=KOQhY%2B3XJtN7WaLVCzJa3OovpKDCJJ2yHj6
>> >>>>>>> AHiH%2FsmQ%3D&reserved=0
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955.html&data=05%7C02%7Cflo.d%40ncsc.go
>> >>>>>>> v.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda
>> >>>>>>> 64a1%7C0%7C0%7C639116952142432157%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h
>> >>>>>>> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
>> >>>>>>> oyfQ%3D%3D%7C40000%7C%7C%7C&sdata=zxgKqtprdwS2sHEk17d%2BKKsHZWVkxuBcL4
>> >>>>>>> WN81ZCYpg%3D&reserved=0
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955.pdf&data=05%7C02%7Cflo.d%40ncsc.gov
>> >>>>>>> .uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda6
>> >>>>>>> 4a1%7C0%7C0%7C639116952142459846%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
>> >>>>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
>> >>>>>>> yfQ%3D%3D%7C40000%7C%7C%7C&sdata=bDvmccc%2BmfGnu7k80hHgsLkzgBNRvt0cIiA
>> >>>>>>> p7UZkjpU%3D&reserved=0
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955.txt&data=05%7C02%7Cflo.d%40ncsc.gov
>> >>>>>>> .uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda6
>> >>>>>>> 4a1%7C0%7C0%7C639116952142486506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
>> >>>>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
>> >>>>>>> yfQ%3D%3D%7C40000%7C%7C%7C&sdata=oz%2F3t8aS%2Bol6jhMCJDN508JUPjkk%2Fy6
>> >>>>>>> nKicgTo%2BW6%2Fk%3D&reserved=0
>> >>>>>>>
>> >>>>>>> Diff file of the text:
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-diff.html&data=05%7C02%7Cflo.d%40nc
>> >>>>>>> sc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f
>> >>>>>>> 46dda64a1%7C0%7C0%7C639116952142512918%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
>> >>>>>>> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
>> >>>>>>> ldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Fx%2BITXyW6bFaTeaFmVPPnupd9902a
>> >>>>>>> kTw2JFdrjT09es%3D&reserved=0
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-rfcdiff.html&data=05%7C02%7Cflo.d%4
>> >>>>>>> 0ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d7
>> >>>>>>> 34f46dda64a1%7C0%7C0%7C639116952142539728%7CUnknown%7CTWFpbGZsb3d8eyJF
>> >>>>>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC
>> >>>>>>> IsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Rrg9A8rLNoF0O4aA3%2FFXla2kIS
>> >>>>>>> 84N5wH4et%2BUVV%2BaOY%3D&reserved=0 (side by side)
>> >>>>>>>
>> >>>>>>> For your convenience, we have also created an alt-diff file that will
>> >>>>>>> allow you to more easily view changes where text has been deleted or
>> >>>>>>> moved:
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-alt-diff.html&data=05%7C02%7Cflo.d%
>> >>>>>>> 40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d
>> >>>>>>> 734f46dda64a1%7C0%7C0%7C639116952142568667%7CUnknown%7CTWFpbGZsb3d8eyJ
>> >>>>>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
>> >>>>>>> CIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=p5YqLFBllkeyZ%2BeRTVIcPGSHH
>> >>>>>>> LB30Qxdwc%2BwnHL8nfo%3D&reserved=0
>> >>>>>>>
>> >>>>>>> Diff of the XML:
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauthors%2Frfc9955-xmldiff1.html&data=05%7C02%7Cflo.d%
>> >>>>>>> 40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d
>> >>>>>>> 734f46dda64a1%7C0%7C0%7C639116952142596842%7CUnknown%7CTWFpbGZsb3d8eyJ
>> >>>>>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
>> >>>>>>> CIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2B%2FpHzQbW2TvbBYwEEYGSDLG
>> >>>>>>> qPkZA1mNjZSNA6eZSpMg%3D&reserved=0
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Tracking progress
>> >>>>>>> -----------------
>> >>>>>>>
>> >>>>>>> The details of the AUTH48 status of your document are here:
>> >>>>>>>
>> >>>>>>> https://www/.
>> >>>>>>> rfc-editor.org%2Fauth48%2Frfc9955&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7
>> >>>>>>> Cb6e100d6f75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7
>> >>>>>>> C0%7C0%7C639116952142624430%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
>> >>>>>>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
>> >>>>>>> D%3D%7C40000%7C%7C%7C&sdata=it6iMYLF4xipV5dn6vO82p6dBDn4yKYBOgCye%2FM9
>> >>>>>>> Ccg%3D&reserved=0
>> >>>>>>>
>> >>>>>>> Please let us know if you have any questions.
>> >>>>>>>
>> >>>>>>> Thank you for your cooperation,
>> >>>>>>>
>> >>>>>>> RFC Editor
>> >>>>>>>
>> >>>>>>> --------------------------------------
>> >>>>>>> RFC9955 (draft-ietf-pquip-hybrid-signature-spectrums-07)
>> >>>>>>>
>> >>>>>>> Title : Hybrid signature spectrums
>> >>>>>>> Author(s) : N. Bindel, B. Hale, D. Connolly, F. Driscoll
>> >>>>>>> WG Chair(s) : Paul E. Hoffman
>> >>>>>>>
>> >>>>>>> Area Director(s) : Deb Cooley, Paul Wouters
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>> <rfc9955_fdchanges.xml>
>> >>
>> >
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
