Approved from my end. Best,
B. Westerbaan > On 29 Jun 2025, at 18:59, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Hi Russ, > > Thank you for your reply and guidance. We have updated accordingly (note > that these files also include the edit revision you previously mentioned). > We believe all of our queries have been resolved except confirmation of our > update to use <sup> in the xml. > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9814.txt > https://www.rfc-editor.org/authors/rfc9814.pdf > https://www.rfc-editor.org/authors/rfc9814.html > https://www.rfc-editor.org/authors/rfc9814.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9814-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9814-auth48diff.html (AUTH48 changes > only) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9814 > > Thank you. > > RFC Editor/mf > >> On Jun 28, 2025, at 1:24 PM, Russ Housley <hous...@vigilsec.com> wrote: >> >> Dear RFC Editor: >> >>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >>> the title) for use on https://www.rfc-editor.org/search. --> >> >> Please add: >> stateless hash-based signature algorithm >> >> >>> 2) <!--[rfced] We see the following similar sentences repeated throughout >>> the document. Please review and let us know if these should be >>> made uniform. >>> >>> Original: >>> >>> SLH-DSA is a stateless hash-based signature scheme. (Abstract) >>> >>> SLH-DSA is a stateless hash-based signature algorithm. (Intro) >>> >>> SLH-DSA is a hash-based signature scheme. (Section 2) >>> >>> SLH-DSA is a stateless hash-based signature algorithm. (Section 2) >>> --> >> >> My preference is: >> SLH-DSA is a stateless hash-based signature algorithm >> >> >>> 3) <!--[rfced] Might we rephrase to avoid the repeated "using" in this >>> sentence? >>> >>> Original: >>> >>> CMS values are generated using ASN.1 [X680], using the Basic Encoding >>> Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. >>> >>> Perhaps: >>> >>> CMS values are generated with ASN.1 [X680] using the Basic Encoding >>> Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. >>> --> >> >> Yes, this is fine. >> >> >>> 4) <!--[rfced] As WOTS+ includes "one-time signature" in its expansion, >>> would this update work? >>> >>> Original: >>> >>> The FORS tree roots are signed by a WOTS+ one-time signature private >>> key. >>> >>> Perhaps: >>> The FORS tree roots are signed by a WOTS+ private key. >>> --> >> >> Yes, this is fine. >> >> >>> 5) <!--[rfced] Please review our updates to this sentence to reduce >>> redundancy to confirm we have maintained your intended meaning. >>> >>> Original: >>> A SLH-DSA signature is verified by verifying the FORS signature, the >>> WOTS+ signatures and the path to the root of each subtree. >>> >>> Current: >>> An SLH-DSA signature is verified using the FORS signature, the WOTS+ >>> signatures, and the path to the root of each subtree. >>> --> >> >> Yes, this is fine. >> >> >>> 6) <!--[rfced] There may be text missing in this sentence. If our >>> suggested text does not convey your intended meaning, please let >>> us know how we may rephrase. >>> >>> Original: >>> Although its security decreases, FORS which is used at the bottom of >>> the SLH-DSA hypertree does not collapse if the same private key used >>> to sign two or more different messages like in stateful hash-based >>> signature schemes. >>> >>> Perhaps: >>> Although its security decreases, FORS, which is used at the bottom of >>> the SLH-DSA hypertree, does not collapse if the same private key used >>> to sign two or more different messages is used (as is the case in >>> stateful hash-based signature schemes). >>> --> >> >> I suggest: >> FORS is used at the bottom of the SLH-DSA hypertree. Security decreases >> if the same private key is used to sign two or more different messages, but >> security does not collapse, as is the case in stateful hash-based signature >> algorithms. >> >> >>> 7) <!-- [rfced] FYI, we have used the <sup> element for superscript in >>> this document. Please review and let us know any objections. >>> --> >> >> Scott, you are probably the best one to perform this check. >> >> >>> 8) <!--[rfced] We note that "SHA2" does not appear in [FIPS180]. Please >>> review and confirm this citation: >>> >>> Original: >>> >>> The AlgorithmIdentifier for a SLH-DSA public key MUST use one of the >>> twelve id-slh-dsa object identifiers listed below, based on the >>> security level used to generate the SLH-DSA hypertree, the small or >>> fast version of the algorithm, and the use of SHA2 [FIPS180] or SHAKE >>> [FIPS202]. >>> >>> --> >> >> FIPS 180 defines the SHA2 family of hash functions. The SHA3 family came >> later, so it is not surprising that FIPS 180 does not use that term. It >> will not be a problem for implementers. >> >> >>> 9) <!-- [rfced] FYI - We have added expansions for abbreviations upon >>> first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please >>> review each expansion in the document carefully to ensure >>> correctness. >>> --> >> >> It looks fine to me. >> >> Russ >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
