Looks fine to me. I approve. Russ
> On Jul 7, 2025, at 2:04 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Hi Panos and *ADs, > > (*AD - please review the updates in the “last version to this” diff below as > changes to BCP 14 language and code have been requested.) > > Thanks for sending along these changes. > > We want to clarify the first change you listed as we don’t see the same text > in the document (that is, when searching “legacy” or “pre-hash content”, > nothing comes up). Can you please resend that change using a section number > and Old/New text so we can be sure to get the document updated as requested? > > We believe we have incorporated the other changes as desired, but as there is > some overlap in the changed text, please review carefully and let us know if > further updates are necessary. > > NOTE: We believe we are waiting on an author to review and confirm the use of > <sup> but that all other RPC-generated queries have been resolved. > > 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 are here (please refresh): > https://www.rfc-editor.org/authors/rfc9814-diff.html > https://www.rfc-editor.org/authors/rfc9814-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9814-auth48diff.html (all AUTH48 > changes to date) > https://www.rfc-editor.org/authors/rfc9814-auth48rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9814-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9814-lastrfcdiff.html (side by side) > > 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 Jul 3, 2025, at 8:28 PM, Kampanakis, Panos <kpa...@amazon.com> wrote: >> >> Hi Megan, >> >> This looks fine to me as well. >> >> We had a few more small changes though, which we had left for AUTH48 >> >> >> […] When signed attributes are absent, the digestAlgorithm identifier does >> not have any significance as it is not used to pre-hash the CMS content with >> SLH-DSA. So, when signed attributes are absent, verifiers MUST NOT use a >> digest algorithm to pre-hash the content before verifying the signature. >> Signers SHOULD MUST match the hash function used in the SLH-DSA tree (as >> shown in the list below) use the SHA-256 algorithm identifier when signed >> attributes are absent to prevent failures with other legacy implementations >> that do not support hashes like SHA-512 or SHAKE256. […] >> >>> The digestAlgorithm MUST identify a one-way hash function. When signed >>> attributes are absent, the digestAlgorithm identifier MUST match the hash >>> function used in the SLH-DSA tree (as shown in the list below) and does not >>> have any significance as it is not used to pre-hash the message with >>> SLH-DSA. >> >> Plus, make the MUST into SHOULDs in >> >>> When signed attributes are absent, the SLH-DSA (pure mode) signature is >>> computed over the content. When signed attributes are present, a hash >>> SHOULD be computed over the content using the same hash function that is >>> used in the SLH-DSA tree. >> >> and >> >>> When signed attributes are absent, the digestAlgorithm identifier SHOULD >>> match the hash function used in the SLH-DSA tree (as shown in the list >>> below) >> >> And two nits >> >>> […] When signed attributes are present, a hash MUST be computed over the >>> content DER encoded signed attributes using the same hash function […] >> >>> ELSE signed attributes message-digest attribute = Hash(content); >> >> >> >> -----Original Message----- >> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> >> Sent: Sunday, June 29, 2025 1:00 PM >> To: Russ Housley <hous...@vigilsec.com> >> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Scott Fluhrer >> <sfluh...@cisco.com>; Kampanakis, Panos <kpa...@amazon.com>; >> b...@westerbaan.name; lamps-...@ietf.org; lamps-cha...@ietf.org; >> tim.holleb...@digicert.com; Deb Cooley <debcool...@gmail.com>; >> auth48archive@rfc-editor.org >> Subject: RE: [EXTERNAL] AUTH48: RFC-to-be 9814 >> <draft-ietf-lamps-cms-sphincs-plus-19> for your review >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> >> 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
