Hi Sarah, The reason is that LMS is a many-time signature method. The one before it: LM-OTS is a one-time signature method.
Thank you and Regards, Quynh. On Tue, Sep 30, 2025 at 12:46 PM Sarah Tarrant < [email protected]> wrote: > Hi Scott and Quynh, > > Regarding that update: > > Current: > 4. Additional LMS Parameter Sets > > The table below defines the Leighton-Micali (LMS) parameters that use > the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions: > > Requested: > 4. Additional LMS Parameter Sets > > The table below defines several many-time signature parameters called > Leighton-Micali Signature (LMS) parameters, using the SHA-256/192, > SHAKE256/256, and SHAKE256/192 hash functions: > > I'm struggling with "many-time". Perhaps this could be updated to "common"? > > Suggested: > 4. Additional LMS Parameter Sets > > The table below defines several common signature parameters called > Leighton-Micali Signature (LMS) parameters, using the SHA-256/192, > SHAKE256/256, and SHAKE256/192 hash functions: > > Or perhaps there is a different word you would like to suggest? > > Thank you, > Sarah Tarrant > RFC Production Center > > > On Sep 30, 2025, at 10:44 AM, Scott Fluhrer (sfluhrer) < > [email protected]> wrote: > > > > Quynh asked for one minor change (new .xml file attached) > > > > With that, it has my approvalFrom: Sarah Tarrant < > [email protected]> > > Sent: Monday, September 29, 2025 3:19 PM > > To: Scott Fluhrer (sfluhrer) <[email protected]> > > Cc: Quynh Dang <[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, > > > > Looks great! I've posted the updated files. > > > > We will await approvals from each author prior to moving forward in the > publication process: > > https://www.rfc-editor.org/auth48/rfc9858 > > > > 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. > > > > Thank you, > > Sarah Tarrant > > RFC Production Center > > > > > On Sep 29, 2025, at 10:20 AM, Scott Fluhrer (sfluhrer) < > [email protected]> wrote: > > > > > > Finally! I believe it's done. > > > > > > And thank you, Sarah, for your patience (and your careful review) > > > > > > From: Sarah Tarrant <[email protected]> > > > Sent: Friday, September 26, 2025 9:09 AM > > > To: Scott Fluhrer (sfluhrer) <[email protected]> > > > Cc: Quynh Dang <[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, > > > > > > 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. > > > > > > Done (LMOTS -> LM-OTS; LMS type stayed the same) > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > As for LMS signature, HSS signatures, yes, that is techincally > redundant, but I can't think of a way to remove the redundancy without > losing clarity (which, of course, is far more important). Hence, it stays > in. > > > > > > > > > <rfc9858.xml> > > > > <rfc9858.xml> > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
