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) <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]
