Hi Scott, No worries! I'll be on the lookout for your email.
Thank you, Sarah Tarrant RFC Production Center > On Sep 26, 2025, at 8:04 AM, Scott Fluhrer (sfluhrer) <[email protected]> > wrote: > > Oh, and I should have warned you - both Quynh and I are at a conference. I > was hoping I would have been able to work on this in the evenings - > obviously, that plan failed. > > I'll get it to you by Monday (honest) > > From: Scott Fluhrer (sfluhrer) <[email protected]> > Sent: Tuesday, September 23, 2025 10:13 AM > To: Sarah Tarrant <[email protected]>; Quynh Dang > <[email protected]> > Cc: [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9858 <draft-fluhrer-lms-more-parm-sets-19> for > your review > > See SRF > > From: Sarah Tarrant <[email protected]> > Sent: Monday, September 22, 2025 11:20 AM > To: Quynh Dang <[email protected]>; Scott Fluhrer (sfluhrer) > <[email protected]> > Cc: [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9858 <draft-fluhrer-lms-more-parm-sets-19> for > your review > > Hi Scott and Quynh, > > Thank you for your replies. We have updated the document accordingly. > > We have a few followup questions/comments: > > A) Regarding: > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. > > --> > We note that there were no keywords in the attached xml file, so we just > wanted to double-check in case you wanted to add any keywords. > > SRF: That is correct - I honestly could not think of any appropriate keywords > that we're already in the title > > That > > > B) Regarding: > > 12) <!-- [rfced] Questions about IANA values > > ... > > b) Some of these values also appear in Appendix A but without the "0x" > > prefix. Please confirm that this is correct. > > > > Example: > > > > Appendix A: > > 0000000a > > > > "Numeric Identifier" column of "LM-OTS Signatures" registry: > > 0x0000000A > > --> > Just double-checking that this question was considered, as it doesn't appear > to have been changed in the attached xml. > > SRF: That is correct. The test vectors in A has a long list of hex values > (with their meanings on the right side) - none of the other values have an 0x > value, hence I thought it would be inappropriate to add them in a few cases. > > > C) Regarding: > > 19) <!-- [rfced] Terminology > > > > a) The first two sentences below use "LM-OTS" and "LM", while the third > > sentence uses "LMOTS" and "LMS" when discussing Tables 1 and 2. Please > > review > > and let us know if updates are needed for consistency. > > > > Original: > > Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) > > parameters defined that use the above hashes: > > ... > > Here is a table with the Leighton-Micali (LM) parameters defined that > > use SHA-256/192, SHAKE256/256 SHAKE256/256, and SHAKE256/192 hash > > functions: > > ... > > To use the additional hash functions within HSS, one would use the > > appropriate LMOTS id from Table 1 and the appropriate LMS id from > > Table 2, ... > > SRF: Oops, I believe you're right. I thought I went through all those cases > - I guess I missed a few. > > > > > b) Please also review the following (which appear in Appendix A) and let us > > know > > if any updates are needed to align with the choice for the question above. > > > > LMS type > > LMOTS type > > LMOTS signature > > SRF: I know I saw those, and decided not to change them - on second thought, > I think you're right. > > > > > > > c) Please review the the following and let us know if any updates are > > needed. These are used in RFC 8445, but we note that there is redundancy > > with > > "signature" when expanded (i.e., "Leighton-Micali Signature signature" and > > "Hierarchical Signature System signature"). > > > > LMS signature > > HSS signature > > --> > Could you take a second look at these acronyms (a, b, and c) and let us know > how we may update for consistency? > > SRF: Thank you, I will > > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9858.txt > https://www.rfc-editor.org/authors/rfc9858.pdf > https://www.rfc-editor.org/authors/rfc9858.html > https://www.rfc-editor.org/authors/rfc9858.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9858-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9858-auth48diff.html (AUTH48 changes > only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9858 > > Thank you, > Sarah Tarrant > RFC Production Center > > > On Sep 22, 2025, at 7:29 AM, Quynh Dang <[email protected]> wrote: > > > > I checked the changes and I think they addressed the comments. > > > > Regards, > > Quynh. > > > > On Fri, Sep 19, 2025 at 2:07 PM Scott Fluhrer (sfluhrer) > > <[email protected]> wrote: > > I believe I have addressed your comments. > > > > Quynh, do you want to take a look over it? > > From: Sarah Tarrant <[email protected]> > > Sent: Thursday, September 18, 2025 2:57 PM > > To: Scott Fluhrer (sfluhrer) <[email protected]>; [email protected] > > <[email protected]> > > Cc: Quynh Dang <[email protected]>; [email protected] > > <[email protected]>; [email protected] <[email protected]> > > Subject: [Document Shepherd] Re: AUTH48: RFC-to-be 9858 > > <draft-fluhrer-lms-more-parm-sets-19> for your review Hi Scott and > > Stanislav, > > > > Scott - I believe this would be a question for the Document Shepherd. > > > > Stanislav - Could you better direct Scott on this? > > > > Thank you, > > Sarah Tarrant > > RFC Production Center > > > > > On Sep 17, 2025, at 4:35 PM, Scott Fluhrer (sfluhrer) > > > <[email protected]> wrote: > > > > > > Quick question: RFC 5743 asks: > > > > > > The breadth of review the document has received must also be > > > noted. For example, was this document read by all the active > > > research group members, only three people, or folks who are not > > > "in" the RG but are expert in the area? > > > > > > > > > Actually, I'm not sure of the breadth. I do know some people reviewed it > > > (and we did get a few comments), but I would be quite surprised if the > > > majority of the research group did. How do I note that? > > > From: Sarah Tarrant <[email protected]> > > > Sent: Wednesday, September 17, 2025 8:59 AM > > > To: Scott Fluhrer (sfluhrer) <[email protected]> > > > Cc: [email protected] <[email protected]>; > > > [email protected] <[email protected]>; [email protected] <[email protected]>; > > > [email protected] <[email protected]>; [email protected] > > > <[email protected]> > > > Subject: Re: AUTH48: RFC-to-be 9858 <draft-fluhrer-lms-more-parm-sets-19> > > > for your review > > > > > > Hi Scott, > > > > > > Regarding: > > > > What version of the draft should we be basing our changes on? Is it > > > > the -19 version in data tracker? Or, is it some version that the RFC > > > > editor has modified? > > > > > > > > > I'm not sure what you mean by "basing our changes on". > > > draft-fluhrer-lms-more-parm-sets-19 has now entered AUTH48 as RFC-to-be > > > 9858. And we await answers to the questions below. > > > > > > Here are those links again: > > > > > > The files are available here: > > > https://www.rfc-editor.org/authors/rfc9858.xml > > > https://www.rfc-editor.org/authors/rfc9858.html > > > https://www.rfc-editor.org/authors/rfc9858.pdf > > > https://www.rfc-editor.org/authors/rfc9858.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9858-diff.html > > > https://www.rfc-editor.org/authors/rfc9858-rfcdiff.html (side by side) > > > > > > Alt-diff of the text (allows you to more easily view changes > > > where text has been deleted or moved): > > > https://www.rfc-editor.org/authors/rfc9858-alt-diff.html > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9858-xmldiff1.html > > > > > > Please let me know if I can be of further assistance. > > > > > > Sincerely, > > > Sarah Tarrant > > > RFC Production Center > > > > > > > On Sep 17, 2025, at 7:28 AM, Scott Fluhrer (sfluhrer) > > > > <[email protected]> wrote: > > > > > > > > What version of the draft should we be basing our changes on? Is it > > > > the -19 version in data tracker? Or, is it some version that the RFC > > > > editor has modified? > > > > > > > > From: [email protected] <[email protected]> > > > > Sent: Monday, September 15, 2025 10:05 PM > > > > To: Scott Fluhrer (sfluhrer) <[email protected]>; [email protected] > > > > <[email protected]> > > > > Cc: [email protected] <[email protected]>; > > > > [email protected] <[email protected]>; [email protected] <[email protected]>; > > > > [email protected] <[email protected]> > > > > Subject: Re: AUTH48: RFC-to-be 9858 > > > > <draft-fluhrer-lms-more-parm-sets-19> for your review > > > > > > > > Authors, > > > > > > > > While reviewing this document during AUTH48, please resolve (as > > > > necessary) the following questions, which are also in the source file. > > > > > > > > > > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > > the title) for use on https://www.rfc-editor.org/search. > > > > --> > > > > > > > > > > > > 2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 > > > > of > > > > RFC 5743 have been adhered to in this document. See > > > > https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1. > > > > --> > > > > > > > > > > > > 3) <!-- [rfced] Please clarify "by defining parameter sets by including > > > > additional hash functions" in the first sentence below. Also, would it > > > > be > > > > helpful to update "These include hash functions that result" in the > > > > second sentence in one of the following ways? Or is the current correct? > > > > > > > > Original: > > > > This note extends HSS/LMS (RFC 8554) by defining parameter sets by > > > > including additional hash functions. These include hash functions > > > > that result in signatures with significantly smaller size than the > > > > signatures using the current parameter sets, and should have > > > > sufficient security. > > > > > > > > Perhaps: > > > > This document extends HSS/LMS (RFC 8554) by defining additional > > > > parameter sets > > > > and hash functions. The hash functions > > > > result in signatures with significantly smaller sizes than the > > > > signatures using the current parameter sets, and they should have > > > > sufficient security. > > > > > > > > Or: > > > > This document extends HSS/LMS (RFC 8554) by defining additional > > > > parameter sets > > > > and hash functions that > > > > result in signatures with significantly smaller sizes than the > > > > signatures using the current parameter sets and they should have > > > > sufficient security. > > > > --> > > > > > > > > > > > > 4) <!-- [rfced] Please clarify "a set of parameter sets to". > > > > > > > > Original: > > > > What this draft > > > > explores is a set of parameter sets to the HSS/LMS (RFC8554) stateful > > > > hash based signature method that reduce the size of the signature > > > > significantly or rely on a hash function other than SHA-256 (to > > > > increase cryptodiversity). > > > > > > > > Perhaps: > > > > This document > > > > explores parameter sets for the HSS/LMS stateful > > > > hash-based signature method [RFC8554] that reduce the size of the > > > > signature > > > > significantly or rely on a hash function other than SHA-256 (to > > > > increase cryptodiversity). > > > > --> > > > > > > > > > > > > 5) <!-- [rfced] May we update "that will be used in Section 3 and > > > > Section 4" as > > > > follows? > > > > > > > > Original: > > > > This section defines three hash functions that will be used in > > > > Section 3 and Section 4. > > > > > > > > Perhaps: > > > > This section defines three hash functions that are used with the > > > > parameter sets defined in Sections 3 and 4. > > > > --> > > > > > > > > > > > > 6) <!-- [rfced] We recommend updating these sentences as follows. > > > > Please review > > > > and let us know your thoughts. > > > > > > > > Original: > > > > Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) > > > > parameters defined that use the above hashes: > > > > ... > > > > Here is a table with the Leighton-Micali (LM) parameters defined that > > > > use SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions: > > > > ... > > > > Here is a table that gives the space used by both the 256 bit > > > > parameter sets and the 192 bit parameter sets, for a range of > > > > plausible Winternitz parameters and tree heights: > > > > > > > > Perhaps: > > > > The table below defines the Leighton-Micali One-Time Signature (LM- > > > > OTS) parameters that use the hashes defined in Section 2: > > > > ... > > > > The table below defines the Leighton-Micali (LM) parameters that use > > > > the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions: > > > > ... > > > > The table below gives the space used by both the 256-bit > > > > and 192-bit parameter sets for a range of > > > > plausible Winternitz parameters and tree heights: > > > > --> > > > > > > > > > > > > 7) <!-- [rfced] How may we revise the parenthetical here to improve > > > > clarity? > > > > > > > > Current: > > > > For signature length, both effects are relevant (because the > > > > signature consists of a series of hashes and each hash is shorter, > > > > and because we need fewer Winternitz chains, we need fewer hashes in > > > > each LM-OTS signature). > > > > > > > > Perhaps: > > > > For signature length, both effects are relevant. The first is > > > > relevant because > > > > the signature consists of a series of hashes and each hash is > > > > shorter. The second > > > > is relevant because when we need fewer Winternitz chains, we need > > > > fewer hashes in > > > > each LM-OTS signature. > > > > > > > > Or: > > > > For signature length, both effects are relevant (i.e., because the > > > > signature consists of a series of hashes and each hash is shorter > > > > and because we need fewer Winternitz chains and thus fewer hashes in > > > > each LM-OTS signature). > > > > --> > > > > > > > > > > > > 8) <!-- [rfced] Will readers understand what "reason 2 above" refers to? > > > > > > > > Original: > > > > For SHA-256/192, there is a smaller (circa 20%) reduction in the > > > > amount of computation required for a signature operation with a 192 > > > > bit hash (for reason 2 listed above). > > > > > > > > Perhaps: > > > > For SHA-256/192, there is a smaller (circa 20%) reduction in the > > > > amount of computation required for a signature operation with a > > > > 192-bit hash (for effect 2 listed above). > > > > > > > > Or: > > > > For SHA-256/192, there is a smaller (circa 20%) reduction in the > > > > amount of computation required for a signature operation with a > > > > 192-bit hash (for reason 2 listed in Section 6). > > > > --> > > > > > > > > > > > > 9) <!-- [rfced] Would updating "will need to be performed, performing > > > > the > > > > computations on" to "will need to be performed on" make this sentence > > > > easier to follow? > > > > > > > > Original: > > > > For example, if the adversary is > > > > willing to wait for 2**64 times the time taken by a hash computation > > > > (which is over 50 years if a Quantum Computer can compute a hash in > > > > 0.1 nsec), this implies that a total of 2**(192-64) = 2**128 hash > > > > computations will need to be performed, performing the computations > > > > on 2**64 (18 quintillion) separate Quantum Computers, each of which > > > > computes 2**64 hash evaluations. > > > > > > > > Perhaps: > > > > For example, if the adversary is > > > > willing to wait for 2**64 times the time taken by a hash computation > > > > (which is over 50 years if a quantum computer can compute a hash in > > > > 0.1 nanoseconds), this implies that a total of 2**(192-64) = 2**128 > > > > hash > > > > computations will need to be performed > > > > on 2**64 (18 quintillion) separate quantum computers, each of which > > > > computes 2**64 hash evaluations. > > > > --> > > > > > > > > > > > > 10) <!-- [rfced] Should "standard SHA256" here include a hyphen (i.e., > > > > "standard > > > > SHA-256")? > > > > > > > > Original: > > > > In addition, to perform a length extension attack on SHA-256/192, the > > > > attacker has to guess the 64 omitted bits (because the attack > > > > requires all 256 bits of the hash value); hence that is even less of > > > > a concern than it is for the standard SHA256. > > > > --> > > > > > > > > > > > > 11) <!-- [rfced] The text after the semicolon is a fragment. How may we > > > > update to > > > > connect this text to the rest of the sentence? > > > > > > > > Original: > > > > However, if the application needs to > > > > assume that it is infeasible for the signer to generate such a > > > > signature, then the security strength assumptions are reduced; 128 > > > > bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. > > > > > > > > Perhaps: > > > > However, if the application needs to > > > > assume that it is infeasible for the signer to generate such a > > > > signature, then the security strength assumptions are reduced to 128 > > > > bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. > > > > > > > > Or: > > > > However, if the application needs to > > > > assume that it is infeasible for the signer to generate such a > > > > signature, then the security strength assumptions are reduced (128 > > > > bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192). > > > > --> > > > > > > > > > > > > 12) <!-- [rfced] Questions about IANA values > > > > > > > > a) Should the values in the "id" column in Tables 1 and 2 be updated to > > > > exactly match the values in the "Numeric Identifier" column of the > > > > "LM-OTS > > > > Signatures" and "Leighton-Micali Signatures (LMS)" registries in regard > > > > to > > > > capitalization and leading zeroes? We understand that these hex values > > > > are the > > > > same. > > > > > > > > Examples: > > > > > > > > "id" column of Table 1: > > > > 0x0005 > > > > 0x000a > > > > > > > > "Numeric Identifier" column of "LM-OTS Signatures" registry: > > > > 0x00000005 > > > > 0x0000000A > > > > > > > > Links to registries: > > > > https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#leighton-micali-signatures-1 > > > > > > > > https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#lm-ots-signatures > > > > > > > > > > > > b) Some of these values also appear in Appendix A but without the "0x" > > > > prefix. Please confirm that this is correct. > > > > > > > > Example: > > > > > > > > Appendix A: > > > > 0000000a > > > > > > > > "Numeric Identifier" column of "LM-OTS Signatures" registry: > > > > 0x0000000A > > > > > > > > > > > > c) In Appendix A, we believe the names below should be updated as > > > > follows to > > > > align with the parameter set names in Tables 1 and 2 (and in the IANA > > > > registries). Please confirm. Note that there are two instances of of > > > > each in > > > > Appendix A. > > > > > > > > Original: > > > > LMS type 00000014 # LMS_SHAKE256_N24_H5 > > > > LMOTS type 00000010 # LMOTS_SHAKE256_N24_W8 > > > > LMS type 0000000f # LMS_SHAKE256_N32_H5 > > > > LMOTS type 0000000c # LMOTS_SHAKE256_N32_W8 > > > > > > > > Perhaps: > > > > LMS type 00000014 # LMS_SHAKE_M24_H5 > > > > LMOTS type 00000010 # LMOTS_SHAKE_N24_W8 > > > > LMS type 0000000f # LMS_SHAKE_M32_H5 > > > > LMOTS type 0000000c # LMOTS_SHAKE_N32_W8 > > > > --> > > > > > > > > > > > > 13) <!-- [rfced] The following reference entries appeared in the > > > > Normative > > > > References section but were not cited in the text. We have removed them; > > > > however, if they should be cited in the text, please let us know where > > > > to > > > > include them. > > > > > > > > [RFC2119] > > > > [RFC3979] > > > > [RFC4879] > > > > [RFC5226] > > > > [RFC8174] > > > > --> > > > > > > > > > > > > 14) <!-- [rfced] FYI - For [Grover96], we found the following URL from > > > > the ACM > > > > Digital Library: > > > > > > > > https://dl.acm.org/doi/10.1145/237814.237866 > > > > > > > > We have updated this reference to match the information provided at this > > > > URL. Please let us know if you have any objections. > > > > > > > > Current: > > > > [Grover96] Grover, L., "A fast quantum mechanical algorithm for > > > > database search", Proceedings of the twenty-eighth annual > > > > ACM symposium on Theory of Computing (STOC '96), pp. > > > > 212-219, DOI 10.1145/237814.237866, July 1996, > > > > <https://doi.org/10.1145/237814.237866>. > > > > --> > > > > > > > > > > > > 15) <!-- [rfced] Appendix A > > > > > > > > a) Appendix A includes four test cases, not three as indicated in the > > > > sentence > > > > below. We updated as follows for accuracy. Please let us know any > > > > objections. > > > > > > > > Original: > > > > This section provides three test cases that can be used to verify or > > > > debug an implementation, one for each hash function. > > > > > > > > Updated: > > > > This appendix provides four test cases that can be used to verify or > > > > debug an implementation. > > > > > > > > > > > > b) FYI - Note that we used figure titles to label the test cases for > > > > clarity, > > > > even though we see that figure titles were not used in a similar > > > > appendix in > > > > RFC 8554. Let us know any concerns. > > > > > > > > > > > > c) For the ease of the reader, we suggest adding subsections to > > > > Appendix A > > > > for each test case. Let us know your thoughts. > > > > > > > > Current: > > > > Appendix A. Test Cases > > > > > > > > Perhaps: > > > > Appendix A. Test Cases > > > > A.1. Test Case 1 > > > > A.2. Test Case 2 > > > > A.3. Test Case 3 > > > > A.4. Test Case 4 > > > > > > > > If we update like this, we could also remove "Test Case 1", "Test Case > > > > 2", > > > > etc. from the figure titles if you wish. > > > > --> > > > > > > > > > > > > 16) <!-- [rfced] In Section 2.1, we updated <artwork> to <sourcecode > > > > type="test-vectors">. Please let us know any concerns. > > > > > > > > Also, please review each artwork element in Appendix A. Should these be > > > > tagged > > > > as sourcecode or another element? > > > > > > > > If these are updated to sourcecode, please let us know how/if to set > > > > the type > > > > attribute. The current list of preferred values for the "type" > > > > attribute for <sourcecode> is available here: > > > > > > > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types > > > > > > > > If this list does not contain an applicable type, then feel free to > > > > suggest a > > > > new one. Also, it is acceptable to leave the "type" attribute not set. > > > > --> > > > > > > > > > > > > 17) <!-- [rfced] Does "**" indicate superscript? Some examples: > > > > > > > > 2**192 > > > > 2**96 > > > > 2**t > > > > 2**(192-t) > > > > 2**(192/2) > > > > > > > > If so, would you like to make use of <sup> for superscript in this > > > > document? > > > > As an example, we updated "2**192" in the fourth paragraph of Section 8 > > > > to use > > > > <sup>. If this is acceptable, we will update the other instances; if you > > > > choose not to use <sup>, we will revert this change. > > > > > > > > Note: In the HTML and PDF, it appears as superscript. In the text > > > > output, > > > > <sup> generates a^b instead of a**b, which was used in the original > > > > document. > > > > --> > > > > > > > > > > > > 18) <!-- [rfced] We updated "1k - 4kbytes" and "0.1 nsec" as follows for > > > > clarity. Let us know any concerns. > > > > > > > > Original: > > > > One disadvantage is that the signatures they produce tend > > > > to be somewhat large (possibly 1k - 4kbytes). > > > > ... > > > > (which is over 50 years if a Quantum Computer can compute a hash in > > > > 0.1 nsec) > > > > > > > > Updated: > > > > One disadvantage is that the signatures they produce tend > > > > to be somewhat large (possibly 1-4 kilobytes). > > > > ... > > > > (which is over 50 years, if a quantum computer can compute a hash in > > > > 0.1 nanoseconds) > > > > --> > > > > > > > > > > > > 19) <!-- [rfced] Terminology > > > > > > > > a) The first two sentences below use "LM-OTS" and "LM", while the third > > > > sentence uses "LMOTS" and "LMS" when discussing Tables 1 and 2. Please > > > > review > > > > and let us know if updates are needed for consistency. > > > > > > > > Original: > > > > Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) > > > > parameters defined that use the above hashes: > > > > ... > > > > Here is a table with the Leighton-Micali (LM) parameters defined that > > > > use SHA-256/192, SHAKE256/256 SHAKE256/256, and SHAKE256/192 hash > > > > functions: > > > > ... > > > > To use the additional hash functions within HSS, one would use the > > > > appropriate LMOTS id from Table 1 and the appropriate LMS id from > > > > Table 2, ... > > > > > > > > > > > > b) Please also review the following (which appear in Appendix A) and > > > > let us know > > > > if any updates are needed to align with the choice for the question > > > > above. > > > > > > > > LMS type > > > > LMOTS type > > > > LMOTS signature > > > > > > > > > > > > c) Please review the the following and let us know if any updates are > > > > needed. These are used in RFC 8445, but we note that there is > > > > redundancy with > > > > "signature" when expanded (i.e., "Leighton-Micali Signature signature" > > > > and > > > > "Hierarchical Signature System signature"). > > > > > > > > LMS signature > > > > HSS signature > > > > --> > > > > > > > > > > > > 20) <!-- [rfced] Abbreviations: > > > > > > > > a) FYI - We have added expansions for the following abbreviation(s) > > > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > > expansion in the document carefully to ensure correctness. > > > > > > > > extendable-output function (XOF) > > > > > > > > > > > > b) How may we expand "IV" in the following? As "Initialization > > > > Vector (IV)"? This the only instance of IV in the document. > > > > > > > > Original: > > > > We use the same IV as the untruncated SHA-256, rather than defining a > > > > distinct one, so that we can use a standard SHA-256 hash > > > > implementation without modification. > > > > > > > > Perhaps: > > > > We use the same initialization vector as the untruncated SHA-256, > > > > rather than defining a > > > > distinct one, so that we can use a standard SHA-256 hash > > > > implementation without modification. > > > > --> > > > > > > > > > > > > 21) <!-- [rfced] Please review the "Inclusive Language" portion of the > > > > online > > > > Style Guide > > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > > and let us know if any changes are needed. Updates of this nature > > > > typically > > > > result in more precise language, which is helpful for readers. > > > > > > > > Note that our script did not flag any words in particular, but this > > > > should > > > > still be reviewed as a best practice. > > > > --> > > > > > > > > > > > > Thank you. > > > > > > > > Sarah Tarrant and Rebecca VanRheenen > > > > RFC Production Center > > > > > > > > > > > > > > > > On Sep 15, 2025, at 6:59 PM, [email protected] wrote: > > > > > > > > *****IMPORTANT***** > > > > > > > > Updated 2025/09/15 > > > > > > > > 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > > > > > * The archive itself: > > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > > > > > * 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/authors/rfc9858.xml > > > > https://www.rfc-editor.org/authors/rfc9858.html > > > > https://www.rfc-editor.org/authors/rfc9858.pdf > > > > https://www.rfc-editor.org/authors/rfc9858.txt > > > > > > > > Diff file of the text: > > > > https://www.rfc-editor.org/authors/rfc9858-diff.html > > > > https://www.rfc-editor.org/authors/rfc9858-rfcdiff.html (side by side) > > > > > > > > Alt-diff of the text (allows you to more easily view changes > > > > where text has been deleted or moved): > > > > https://www.rfc-editor.org/authors/rfc9858-alt-diff.html > > > > > > > > Diff of the XML: > > > > https://www.rfc-editor.org/authors/rfc9858-xmldiff1.html > > > > > > > > > > > > Tracking progress > > > > ----------------- > > > > > > > > The details of the AUTH48 status of your document are here: > > > > https://www.rfc-editor.org/auth48/rfc9858 > > > > > > > > Please let us know if you have any questions. > > > > > > > > Thank you for your cooperation, > > > > > > > > RFC Editor > > > > > > > > -------------------------------------- > > > > RFC9858 (draft-fluhrer-lms-more-parm-sets-19) > > > > > > > > Title : Additional Parameter sets for HSS/LMS Hash-Based > > > > Signatures > > > > Author(s) : S. Fluhrer, Q. Dang > > > > WG Chair(s) : > > > > Area Director(s) : > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
