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> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
