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://www.rfc-editor.org/auth48/rfc9955 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%7Cb6e100d6f > 75c462a7e2608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6 > 39116952142108314%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C400 > 00%7C%7C%7C&sdata=VBi8v52NykkpgSEnXnipU97KOPrxj01Do91EFkablEU%3D&reser > 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%2FPro > jects%2F&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de > 997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6391169521421503 > 52%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > 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%7C14aa5744ece1474ea2d734f46d > da64a1%7C0%7C0%7C639116952142225842%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU > IjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=LhwRtGzgINulI5KXwwS3%2B7wmmpXJ5lEK > 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=05%7 > C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2608de997b26cb%7C14aa574 > 4ece1474ea2d734f46dda64a1%7C0%7C0%7C639116952142243485%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=OAKGJ1JUFGfG4S7 > 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%2Fnist > -research-library%2Fnist-technical-series-publications-author-instruct > ions%23table1&data=05%7C02%7Cflo.d%40ncsc.gov.uk%7Cb6e100d6f75c462a7e2 > 608de997b26cb%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C63911695214 > 2266275%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7 > C&sdata=KjcOH4cMH6dmM13%2B13OD%2BAjDTx1XlYsjUKX%2BJC65ue4%3D&reserved= > 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 > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
