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]
