I approve. TY Deb
On Thu, Jul 10, 2025 at 12:21 PM Megan Ferguson < [email protected]> wrote: > Hi Panos, > > Thanks for sending this change along. We have incorporated it into the > previous version of the files (please refresh). > > We have also updated your status to “Approved” at the AUTH48 status page ( > https://www.rfc-editor.org/auth48/rfc9814). Once we have approvals from > each party listed, we will be ready to move forward in the publication > process. > > Thank you. > > RFC Editor/mf > > > > On Jul 9, 2025, at 9:23 PM, Kampanakis, Panos <[email protected]> wrote: > > > > Looks great Megan, thank you. > > > > Nit: Remove "with SLH-DSA" from "as it is not used to pre-hash the > message with SLH-DSA". > > > > All set from my side. > > > > > > -----Original Message----- > > From: Megan Ferguson <[email protected]> > > Sent: Tuesday, July 8, 2025 2:15 PM > > To: Kampanakis, Panos <[email protected]>; Deb Cooley < > [email protected]>; [email protected] > > Cc: Russ Housley <[email protected]>; RFC Editor < > [email protected]>; Scott Fluhrer <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected] > > Subject: RE: [EXTERNAL] [AD] 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 Panos (and *AD), > > > > Thanks for clarifying! We have updated the previously posted files to > include this change as well (please be sure to refresh). > > > > *AD - Please review and approve the changes highlighted in the “last > version to this” diffs below. > > > > 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 7, 2025, at 8:35 PM, Kampanakis, Panos <[email protected]> > wrote: > >> > >> Hi Megan, > >> > >> Almost everything looked fine, but I revamped the one paragraph below > to make sure we are not missing any of the changes. > >> > >> The digestAlgorithm MUST identify a one-way hash function. 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). The digestAlgorithm does not have any > significance when > >> signed attributes are absent as it is not used to pre-hash the > message with SLH-DSA. > >> When there is a concern for failures with legacy implementations > that > >> do not support all hash functions, signers MAY choose to always use > the > >> SHA-256 algorithm identifier as the digestAlgorithm when signed > >> attributes are absent. > >> When signed attributes are present, to ensure collision resistance, > the > >> identified hash function MUST produce a hash value that is at > >> least twice the size of the hash function used in the SLH-DSA > >> tree. The hash functions defined in [FIPS180] and [FIPS202] MUST > >> be supported for use with the variants of > >> SLH-DSA as shown below: > >> > >> > >> > >> -----Original Message----- > >> From: Megan Ferguson <[email protected]> > >> Sent: Monday, July 7, 2025 2:05 PM > >> To: Kampanakis, Panos <[email protected]>; Deb Cooley > >> <[email protected]>; [email protected] > >> Cc: Russ Housley <[email protected]>; RFC Editor > >> <[email protected]>; Scott Fluhrer <[email protected]>; > >> [email protected]; [email protected]; > >> [email protected]; [email protected] > >> Subject: RE: [EXTERNAL] [AD] 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 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 <[email protected]> > 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 <[email protected]> > >>> Sent: Sunday, June 29, 2025 1:00 PM > >>> To: Russ Housley <[email protected]> > >>> Cc: RFC Editor <[email protected]>; Scott Fluhrer > >>> <[email protected]>; Kampanakis, Panos <[email protected]>; > >>> [email protected]; [email protected]; [email protected]; > >>> [email protected]; Deb Cooley <[email protected]>; > >>> [email protected] > >>> 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 <[email protected]> > 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 -- [email protected] To unsubscribe send an email to [email protected]
