Hi Ben, Thank you for your review. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9882>. We have received all of the needed approvals and will continue with publication shortly.
Thank you, Sandy Ginoza RFC Production Center > On Oct 27, 2025, at 1:23 AM, Ben S3 <[email protected]> wrote: > > OFFICIAL > > Hi Sandy, > > I approve this for publication. > > Thanks! > Ben > > > OFFICIAL > -----Original Message----- > From: Sandy Ginoza <[email protected]> > Sent: 25 October 2025 02:45 > To: Ben S3 <[email protected]> > Cc: Adam R <[email protected]>; Daniel Van Geest > <[email protected]>; RFC Editor > <[email protected]>; [email protected]; [email protected]; > [email protected]; Deb Cooley <[email protected]>; Russ Housley > <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> for your > review > > [You don't often get email from [email protected]. Learn why this > is important at https://aka.ms/LearnAboutSenderIdentification ] > > Hi Ben, > > Thank you for your review. We have updated the document as described below > and posted the revised files here: > https://www.rfc-editor.org/authors/rfc9882.xml > https://www.rfc-editor.org/authors/rfc9882.txt > https://www.rfc-editor.org/authors/rfc9882.pdf > https://www.rfc-editor.org/authors/rfc9882.html > > Diffs highlighting the changes described below: > https://www.rfc-editor.org/authors/rfc9882-lastdiff.html > https://www.rfc-editor.org/authors/rfc9882-lastrfcdiff.html (side by side) > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9882-auth48diff.html > https://www.rfc-editor.org/authors/rfc9882-auth48rfcdiff.html (side by side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9882-diff.html > https://www.rfc-editor.org/authors/rfc9882-rfcdiff.html (side by side) > > Please review and let us know if any further updates are needed or if you > approve the RFC for publication. > > Thank you, > Sandy Ginoza > RFC Production Center > > > >> On Oct 23, 2025, at 4:57+IC8-AM, Ben S3 <[email protected]> wrote: >> >> OFFICIAL >> >> Hi Sandy, >> >> Apologies, I've only just returned from leave. >> >> I've given the draft a final full read and spotted four small changes to be >> made, listed below. Sorry for not noticing these earlier! Hopefully the >> formatting works, I+IBk-m doing this on my phone. >> >> Thanks, >> Ben >> >> Section 1: >> >> OLD: >> This document specifies the use of the ML-DSA in the CMS at three security >> levels: >> >> NEW: >> This document specifies the use of ML-DSA in the CMS at three security >> levels: >> >> >> Section 3.1: >> >> OLD: >> and these algorithms support both a "pure" and "pre-hash" mode. >> >> NEW: >> and these algorithms support both a "pure" and a "pre-hash" mode. >> >> >> Section 4: >> >> OLD: >> ML-DSA depends on high quality random numbers that are suitable for use in >> cryptography. >> >> NEW: >> ML-DSA depends on high-quality random numbers that are suitable for use in >> cryptography. >> >> OLD: >> Side channel attacks and fault attacks against ML-DSA are an active >> area of research >> >> NEW: >> Side-channel attacks and fault attacks against ML-DSA are an active >> area of research >> >> OFFICIAL >> From: Sandy Ginoza <[email protected]> >> Sent: Monday, October 20, 2025 3:56:05 PM >> To: Adam R <[email protected]> >> Cc: Daniel Van Geest <[email protected]>; Ben S3 >> <[email protected]>; RFC Editor <[email protected]>; >> [email protected] <[email protected]>; [email protected] >> <[email protected]>; [email protected] >> <[email protected]>; Deb Cooley <[email protected]>; Russ >> Housley <[email protected]> >> Subject: Re: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> for >> your review [You don't often get email from [email protected]. >> Learn why this is important at https://aka.ms/LearnAboutSenderIdentification >> ] >> >> Hi Daniel and Adam, >> >> Thank you for your replies. We have noted your approvals on the AUTH48 >> status page <https://www.rfc-editor.org/auth48/rfc9882>. We will continue >> with publication once we have received approval from Ben as well. >> >> Thank you. >> Sandy Ginoza >> RFC Production Center >> >> >> >>> On Oct 20, 2025, at 2:59+IC8-AM, Adam R <[email protected]> wrote: >>> >>> I also approve this for publication. >>> >>> Adam >>> >>> From: Daniel Van Geest <[email protected]> >>> Sent: Monday, October 20, 2025 09:31 >>> To: Sandy Ginoza <[email protected]>; Adam R >>> <[email protected]> >>> Cc: Ben S3 <[email protected]>; RFC Editor >>> <[email protected]>; [email protected] >>> <[email protected]>; [email protected] <[email protected]>; >>> [email protected] <[email protected]>; Deb >>> Cooley <[email protected]>; Russ Housley <[email protected]> >>> Subject: Re: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> >>> for your review >>> >>> I approve this for publication. >>> Daniel >>> On 2025-10-18 1:24 a.m., Sandy Ginoza wrote: >>> Hi Adam, >>> >>> Apologies for the delay. We have updated the document and posted the >>> revised files here: >>> https://www.rfc-editor.org/authors/rfc9882.xml >>> https://www.rfc-editor.org/authors/rfc9882.txt >>> https://www.rfc-editor.org/authors/rfc9882.pdf >>> >>> https://ww/ >>> w.rfc-editor.org%2Fauthors%2Frfc9882.html&data=05%7C02%7Cben.s3%40nc >>> sc.gov.uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa5744ece1474ea2d73 >>> 4f46dda64a1%7C0%7C0%7C638969535967434699%7CUnknown%7CTWFpbGZsb3d8eyJ >>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF >>> pbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=rAekWKKRUZIOGEfRGPOlLL3 >>> HnG6h8085fLx0pD2huJM%3D&reserved=0 >>> >>> Diffs highlighting the most recent udpates only: >>> https://www.rfc-editor.org/authors/rfc9882-lastdiff.html >>> >>> https://ww/ >>> w.rfc-editor.org%2Fauthors%2Frfc9882-lastrfcdiff.html&data=05%7C02%7 >>> Cben.s3%40ncsc.gov.uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa5744e >>> ce1474ea2d734f46dda64a1%7C0%7C0%7C638969535967464997%7CUnknown%7CTWF >>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=t%2Ft1GOoc6 >>> o%2FXBtW0XdHo2DuniNzX0zTGRGrJ71s5Fj8%3D&reserved=0 (side by side) >>> >>> AUTH48 diffs: >>> https://www.rfc-editor.org/authors/rfc9882-auth48diff.html >>> >>> https://ww/ >>> w.rfc-editor.org%2Fauthors%2Frfc9882-auth48rfcdiff.html&data=05%7C02 >>> %7Cben.s3%40ncsc.gov.uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa574 >>> 4ece1474ea2d734f46dda64a1%7C0%7C0%7C638969535967494530%7CUnknown%7CT >>> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM >>> iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=h7W%2Bp31 >>> yBmtFDyg1KrKGRAmtSDv1fZipi588qfsrtpA%3D&reserved=0 (side by side) >>> >>> Comprehensive diffs: >>> https://www.rfc-editor.org/authors/rfc9882-diff.html >>> >>> https://ww/ >>> w.rfc-editor.org%2Fauthors%2Frfc9882-rfcdiff.html&data=05%7C02%7Cben >>> .s3%40ncsc.gov.uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa5744ece14 >>> 74ea2d734f46dda64a1%7C0%7C0%7C638969535967523815%7CUnknown%7CTWFpbGZ >>> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=VBpS97trW0m9PAH >>> sodhjDkZ%2BY%2BXKvIMLrC%2FeCN3RAOI%3D&reserved=0 (side by side) >>> >>> Please review and let us know if any updates are needed or if you approve >>> the RFC for publication. >>> >>> Thank you. >>> Sandy Ginoza >>> RFC Production Center >>> >>> >>> >>> >>> On Oct 17, 2025, at 3:12+IC8-AM, Adam R <[email protected]> wrote: >>> >>> One other small correction courtesy of Sean Turner - the abstract suggests >>> the public key syntax is included in the document, but we removed that when >>> it was moved to dilithium-certs instead. >>> >>> OLD: >>> In addition, the algorithm identifier and public key syntax are provided. >>> >>> NEW: >>> In addition, the algorithm identifier syntax is provided. >>> >>> >>> Thanks, >>> >>> Adam >>> >>> From: Adam R <[email protected]> >>> Sent: Tuesday, October 14, 2025 16:00 >>> To: Deb Cooley <[email protected]>; Russ Housley >>> <[email protected]> >>> Cc: Sandy Ginoza <[email protected]>; Ben S3 >>> <[email protected]>; RFC Editor <[email protected]>; >>> [email protected] >>> <[email protected]>; [email protected] >>> <[email protected]>; [email protected] <[email protected]>; >>> [email protected] <[email protected]> >>> Subject: Re: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> >>> for your review >>> >>> I did. I expect to approve once that's done, though. >>> >>> I'll note that Daniel's on vacation this week, and Ben's away until the >>> 23rd, so I'll be the only author able to approve for a while. >>> >>> From: Deb Cooley <[email protected]> >>> Sent: Tuesday, October 14, 2025 15:56 >>> To: Russ Housley <[email protected]> >>> Cc: Adam R <[email protected]>; Sandy Ginoza >>> <[email protected]>; Ben S3 <[email protected]>; RFC >>> Editor <[email protected]>; >>> [email protected] >>> <[email protected]>; [email protected] >>> <[email protected]>; [email protected] <[email protected]>; >>> [email protected] <[email protected]> >>> Subject: Re: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> >>> for your review >>> >>> And Adam asked for a change? >>> >>> On Tue, Oct 14, 2025 at 8:08+IC8-AM Russ Housley <[email protected]> >>> wrote: >>> None of the authors have approved the draft yet. >>> >>> See >>> https://ww/ >>> w.rfc-editor.org%2Fauth48%2Frfc9882&data=05%7C02%7Cben.s3%40ncsc.gov >>> .uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa5744ece1474ea2d734f46dd >>> a64a1%7C0%7C0%7C638969535967538577%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI >>> ldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=WtO75yLIF3qKuCQG%2FoLZA8wfpKo >>> 02AKBr4OS671drj4%3D&reserved=0 >>> >>> Russ >>> >>> >>> On Oct 14, 2025, at 7:21+IC8-AM, Deb Cooley <[email protected]> wrote: >>> >>> Are we waiting on an update? or approvals by authors? >>> >>> Deb (attempting to not be twitchy) >>> >>> On Fri, Oct 10, 2025 at 3:44+IC8-PM Adam R <[email protected]> wrote: >>> Hi Sandy, >>> >>> Sorry, one last thing I spotted. There's been an "is" added in Section 3.3 >>> that changes the meaning of the text. The intended meaning is that the >>> security strength offered is either the digest algorithm's strength, or the >>> strength of the ML-DSA parameter set, depending on which value is lower. >>> The text change suggested below to reverts the change and suggests >>> alternative text to make this a bit clearer, but of course I'm happy for it >>> to be tweaked as is required: >>> >>> OLD: >>> The overall security strength offered by an ML-DSA signature calculated >>> over signed attributes is the floor of the digest algorithm's strength and >>> is the strength of the ML-DSA parameter set. >>> >>> NEW: >>> The overall security strength offered by an ML-DSA signature calculated >>> over signed attributes is constrained by either the digest algorithm's >>> strength or the strength of the ML-DSA parameter set, whichever is lower. >>> >>> Otherwise, everything looks good to go to me. >>> >>> Thanks, >>> >>> Adam >>> >>> >>> >>> From: Sandy Ginoza <[email protected]> >>> Sent: Friday, October 10, 2025 20:22 >>> To: Adam R <[email protected]> >>> Cc: Ben S3 <[email protected]>; RFC Editor >>> <[email protected]>; [email protected] >>> <[email protected]>; [email protected] >>> <[email protected]>; [email protected] <[email protected]>; >>> Russ Housley <[email protected]>;[email protected] >>> <[email protected]>; [email protected] >>> <[email protected]> >>> Subject: Re: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> >>> for your review >>> >>> [You don't often get email from [email protected]. Learn >>> why this is important at >>> https://aka.ms/LearnAboutSenderIdentification ] >>> >>> Hi Adam and Ben, >>> >>> The document has been updated as described below. The current files are >>> available here: >>> https://www.rfc-editor.org/authors/rfc9882.xml >>> https://www.rfc-editor.org/authors/rfc9882.txt >>> https://www.rfc-editor.org/authors/rfc9882.pdf >>> >>> https://ww/ >>> w.rfc-editor.org%2Fauthors%2Frfc9882.html&data=05%7C02%7Cben.s3%40nc >>> sc.gov.uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa5744ece1474ea2d73 >>> 4f46dda64a1%7C0%7C0%7C638969535967601393%7CUnknown%7CTWFpbGZsb3d8eyJ >>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF >>> pbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OepVUu4HA1D4qbgmoDbxmTf >>> mcNuslSNl7F6BbdAGp4Q%3D&reserved=0 >>> >>> AUTH48 diffs: >>> https://www.rfc-editor.org/authors/rfc9882-auth48diff.html >>> >>> https://ww/ >>> w.rfc-editor.org%2Fauthors%2Frfc9882-auth48rfcdiff.html&data=05%7C02 >>> %7Cben.s3%40ncsc.gov.uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa574 >>> 4ece1474ea2d734f46dda64a1%7C0%7C0%7C638969535967631362%7CUnknown%7CT >>> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM >>> iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=qr0RIrbX9 >>> YkXHVlc%2F9%2FZnzpl%2BZqPQg0GyxZNTetHX2s%3D&reserved=0 (side by >>> side) >>> >>> Comprehensive diffs: >>> https://www.rfc-editor.org/authors/rfc9882-diff.html >>> >>> https://ww/ >>> w.rfc-editor.org%2Fauthors%2Frfc9882-rfcdiff.html&data=05%7C02%7Cben >>> .s3%40ncsc.gov.uk%7Cc5ce8c95cf0f4aaa41a408de13682dbc%7C14aa5744ece14 >>> 74ea2d734f46dda64a1%7C0%7C0%7C638969535967660256%7CUnknown%7CTWFpbGZ >>> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=WwiXsAItWr5eOke >>> 9W2Qbzbk57osQm7%2F8jRqw1nsD5Zs%3D&reserved=0 (side by side) >>> >>> Please review and let us if any further updates are needed or if you >>> approve the RFC for publication. >>> >>> Thank you, >>> Sandy Ginoza >>> RFC Production Center >>> >>> >>> >>> >>> On Oct 10, 2025, at 8:05+IC8-AM, Adam R >>> <[email protected]> wrote: >>> >>> Hi Sandy, >>> >>> +ICI The authors (Ben included) have had a discussion on this and we >>> think we can just remove "traditional" entirely; describing the algorithm >>> as a "post-quantum" algorithm as we have elsewhere in the document conveys >>> the intended meaning. >>> >>> OLD: >>> The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a digital >>> signature algorithm standardised by the US National Institute of Standards >>> and Technology (NIST) as part of their post-quantum cryptography >>> standardisation process. >>> It is intended to be secure against both "traditional" cryptographic >>> attacks, as well as attacks utilising a quantum computer. >>> >>> NEW: >>> The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a >>> post-quantum digital signature algorithm standardised by the US National >>> Institute of Standards and Technology (NIST) as part of their post-quantum >>> cryptography standardisation process. >>> >>> +ICI We've discussed with the authors of dilithium-certs and Deb, and are >>> content that the meaning of the text is the same in both instances and >>> hence no wording changes are required. >>> >>> +ICI I also think this is fine. >>> >>> +ICI Base64-encoded examples seem somewhat rare in CMS RFCs, I had a >>> quick look at recent examples and I only found RFC 9690. That RFC tags its >>> examples as artwork. The examples in question aren't X.509, so I would >>> leave them as-is or tag as artwork. If Russ has an opinion (as an author of >>> RFC 9690 and many more CMS RFCs), I'd go with that. >>> >>> +ICI I agree with Ben. >>> >>> I agree with Ben's typo correction for Section 6, and suggest an additional >>> change to give that table a title: >>> OLD: >>> <table anchor="oid"> >>> <thead> >>> <tr> >>> <th>Decimal</th> >>> <th>Description</th> >>> <th>Refernece</th> >>> </tr> >>> </thead> >>> <tbody> >>> <tr> >>> <td>83</td> >>> <td>id-mod-ml-dsa-2024</td> >>> <td>RFC 9882</td> >>> </tr> >>> </tbody> >>> </table> >>> >>> NEW: >>> <table anchor="oid"> >>> <name>Object Identifier Assignments</name> <thead> >>> <tr> >>> <th>Decimal</th> >>> <th>Description</th> >>> <th>Reference</th> >>> </tr> >>> </thead> >>> <tbody> >>> <tr> >>> <td>83</td> >>> <td>id-mod-ml-dsa-2024</td> >>> <td>RFC 9882</td> >>> </tr> >>> </tbody> >>> </table> >>> >>> >>> I would suggest one other grammatical change in Section 5: >>> >>> OLD: >>> If ML-DSA signing is implemented in a hardware device such as the hardware >>> security module (HSM) or portable cryptographic token, implementers might >>> want to avoid sending the full content to the device for performance >>> reasons. >>> >>> NEW: >>> If ML-DSA signing is implemented in a hardware device such as a hardware >>> security module (HSM) or a portable cryptographic token, implementers might >>> want to avoid sending the full content to the device for performance >>> reasons. >>> >>> Thanks, >>> >>> Adam >>> >>> From: Ben S3 <[email protected]> >>> Sent: Friday, October 10, 2025 08:15 >>> To: [email protected] <[email protected]>; Adam R >>> <[email protected]>; >>> [email protected]<[email protected]> >>> Cc: [email protected] <[email protected]>; [email protected] >>> <[email protected]>;[email protected] <[email protected]>; >>> [email protected] <[email protected]>; [email protected] >>> <[email protected]> >>> Subject: RE: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> for >>> your review >>> >>> Thanks Sandy! >>> >>> To the specific points below: >>> >>> 1) Use of "Traditional" in our draft is intended to mirror the use of >>> traditional in RFC 9794. Traditional cryptographic algorithms are meant to >>> be secure against traditional cryptographic attacks, whereas PQ algorithms >>> are secure against both traditional and quantum attacks. Whilst not >>> explicitly defined, the terminology is precise enough that it is fully >>> understood in the post-quantum context. I'd therefore leave it as it is. >>> >>> 2) I agree they should be the same, but I think I prefer our wording. I'll >>> reach out to the authors of dilithium-certs. >>> >>> 3) Fine by me. >>> >>> 4) These are not X.509 artefacts, so I propose leaving the type attribute >>> unset. >>> >>> 5) I've reviewed the guidance - I believe our document has no inclusivity >>> concerns. >>> >>> Additional points: >>> >>> Section 6: >>> >>> OLD: >>> +-=========+-====================+-===========+- >>> | Decimal | Description | Refernece | >>> +-=========+-====================+-===========+- >>> | 83 | id-mod-ml-dsa-2024 | RFC 9882 | >>> +----------+---------------------+------------+- >>> >>> NEW: >>> +-=========+-====================+-===========+- >>> | Decimal | Description | Reference | >>> +-=========+-====================+-===========+- >>> | 83 | id-mod-ml-dsa-2024 | RFC 9882 | >>> +----------+---------------------+------------+- >>> >>> -----Original Message----- >>> From: [email protected] <[email protected]> >>> Sent: 10 October 2025 00:56 >>> To: Ben S3 <[email protected]>; Adam R <[email protected]>; >>> [email protected] >>> Cc: [email protected]; [email protected]; [email protected]; >>> [email protected]; [email protected]; [email protected] >>> Subject: Re: AUTH48: RFC-to-be 9882 <draft-ietf-lamps-cms-ml-dsa-07> for >>> your review >>> >>> Authors, >>> >>> While reviewing this document during AUTH48, please resolve (as necessary) >>> the following questions, which are also in the source file. >>> >>> 1) <!-- [rfced] We note that "traditional" is in quotes, but please >>> consider whether it should be updated for clarity. The term is ambiguous; >>> "tradition" is a subjective term because it is not the same for everyone. >>> >>> Original: >>> It is intended to be secure >>> against both "traditional" cryptographic attacks, as well as attacks >>> utilising a quantum computer. >>> --> >>> >>> >>> 2) <!-- [rfced] The following was provided in response to the intake form: >>> >>> This document and draft-ietf-lamps-dilithium-certificates use >>> the same text for one of the security considerations: "ML-DSA >>> depends on high quality random numbers...". That paragraph >>> should be kept the same between both documents. >>> >>> Should the paragraphs be identical? They do not currently match. Please >>> review and let us know how you would like to proceed. >>> >>> Currently in RFC-to-be 9881 <draft-ietf-lamps-dilithium-certificates>: >>> ML-DSA depends on high quality random numbers that are suitable for >>> use in cryptography. The use of inadequate pseudo-random number >>> generators (PRNGs) to generate such values can significantly >>> undermine various security properties. For instance, using an >>> inadequate PRNG for key generation might allow an attacker to >>> efficiently recover the private key by trying a small set of >>> possibilities, rather than brute-force searching the whole keyspace. >>> The generation of random numbers of a sufficient level of quality for >>> use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for >>> some additional information. >>> --> >>> >>> >>> 3) <!-- [rfced] [CSOR] FYI: We have updated the date for this reference >>> from 20 August 2024 to 13 June 2025 to match the information provided at >>> the URL. >>> --> >>> >>> >>> 4) <!-- [rfced] Regarding the text marked <sourcecode> and <artwork>, >>> please review and let us know if any updates are needed. The following was >>> provided in response via the intake form: >>> >>> The draft features an ASN.1 module that is tagged as source code >>> in the XML. The module has been tested to confirm that it compiles. >>> The draft also features example encodings in base64/PEM format and >>> in a parsed representation. These are artefacts produced by an >>> implementation rather than "source code" per se, so aren't tagged >>> that way. Regardless, we've tested the examples against an independent >>> implementation to make sure they work. >>> >>> Please consider whether some should be marked as "x509" for consistency >>> with RFC-to-be 9881 <draft-ietf-lamps-dilithium-certificates>, as the >>> authors of RFC 9881 provided the following guidance: >>> >>> And the PEM examples in the Appendix C.3 can become type +IBw-x509+IB0. >>> >>> RFC-to-be 9881 has not yet been updated. >>> >>> Note that the current list of preferred values for "type" is available at >>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >>> If the current list does not contain an applicable type, feel free to >>> suggest additions for consideration. Note that it is also acceptable to >>> leave the "type" attribute not set. >>> --> >>> >>> >>> 5) <!-- [rfced] Please review the "Inclusive Language" portion of the >>> online Style Guide >>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>> and let us know if any changes are needed. Updates of this nature >>> typically result in more precise language, which is helpful for readers. >>> >>> Note that our script did not flag any words in particular, but this should >>> still be reviewed as a best practice. >>> --> >>> >>> >>> Thank you. >>> Sandy Ginoza >>> RFC Production Center >>> >>> >>> >>> On Oct 9, 2025, at 4:51+IC8-PM, [email protected] wrote: >>> >>> *****IMPORTANT***** >>> >>> Updated 2025/10/09 >>> >>> RFC Author(s): >>> -------------- >>> >>> Instructions for Completing AUTH48 >>> >>> Your document has now entered AUTH48. Once it has been reviewed and >>> approved by you and all coauthors, it will be published as an RFC. >>> If an author is no longer available, there are several remedies >>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>> >>> You and you coauthors are responsible for engaging other parties >>> (e.g., Contributors or Working Group) as necessary before providing >>> your approval. >>> >>> Planning your review >>> --------------------- >>> >>> Please review the following aspects of your document: >>> >>> * RFC Editor questions >>> >>> Please review and resolve any questions raised by the RFC Editor >>> that have been included in the XML file as comments marked as >>> follows: >>> >>> <!-- [rfced] ... --> >>> >>> These questions will also be sent in a subsequent email. >>> >>> * Changes submitted by coauthors >>> >>> Please ensure that you review any changes submitted by your >>> coauthors. We assume that if you do not speak up that you >>> agree to changes submitted by your coauthors. >>> >>> * Content >>> >>> Please review the full content of the document, as this cannot >>> change once the RFC is published. Please pay particular attention to: >>> - IANA considerations updates (if applicable) >>> - contact information >>> - references >>> >>> * Copyright notices and legends >>> >>> Please review the copyright notice and legends as defined in >>> RFC 5378 and the Trust Legal Provisions >>> (TLP +IBM https://trustee.ietf.org/license-info). >>> >>> * Semantic markup >>> >>> Please review the markup in the XML file to ensure that elements of >>> content are correctly tagged. For example, ensure that <sourcecode> >>> and <artwork> are set correctly. See details at >>> <https://authors.ietf.org/rfcxml-vocabulary>. >>> >>> * Formatted output >>> >>> Please review the PDF, HTML, and TXT files to ensure that the >>> formatted output, as generated from the markup in the XML file, is >>> reasonable. Please note that the TXT will have formatting >>> limitations compared to the PDF and HTML. >>> >>> >>> Submitting changes >>> ------------------ >>> >>> To submit changes, please reply to this email using +IBg-REPLY ALL+IBk as >>> all >>> the parties CCed on this message need to see your changes. The parties >>> include: >>> >>> * your coauthors >>> >>> * [email protected] (the RPC team) >>> >>> * other document participants, depending on the stream (e.g., >>> IETF Stream participants are your working group chairs, the >>> responsible ADs, and the document shepherd). >>> >>> * [email protected], which is a new archival mailing list >>> to preserve AUTH48 conversations; it is not an active discussion >>> list: >>> >>> * More info: >>> >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>> >>> * The archive itself: >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>> >>> * Note: If only absolutely necessary, you may temporarily opt out >>> of the archiving of messages (e.g., to discuss a sensitive matter). >>> If needed, please add a note at the top of the message that you >>> have dropped the address. When the discussion is concluded, >>> [email protected] will be re-added to the CC list and >>> its addition will be noted at the top of the message. >>> >>> You may submit your changes in one of two ways: >>> >>> An update to the provided XML file >>> +IBQ OR +IBQ >>> An explicit list of changes in this format >>> >>> Section # (or indicate Global) >>> >>> OLD: >>> old text >>> >>> NEW: >>> new text >>> >>> You do not need to reply with both an updated XML file and an explicit >>> list of changes, as either form is sufficient. >>> >>> We will ask a stream manager to review and approve any changes that seem >>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>> and technical changes. Information about stream managers can be found in >>> the FAQ. Editorial changes do not require approval from a stream manager. >>> >>> >>> Approving for publication >>> -------------------------- >>> >>> To approve your RFC for publication, please reply to this email stating >>> that you approve this RFC for publication. Please use +IBg-REPLY ALL+IBk, >>> as all the parties CCed on this message need to see your approval. >>> >>> >>> Files >>> ----- >>> >>> The files are available here: >>> https://www.rfc-editor.org/authors/rfc9882.xml >>> https://www.rfc-editor.org/authors/rfc9882.html >>> >>> https://www.rfc-editor.org/authors/rfc9882.pdf >>> https://www.rfc-editor.org/authors/rfc9882.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9882-diff.html >>> https://www.rfc-editor.org/authors/rfc9882-rfcdiff.html (side by side) >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9882-xmldiff1.html >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9882 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC 9882 (draft-ietf-lamps-cms-ml-dsa-07) >>> >>> Title : Use of the ML-DSA Signature Algorithm in the >>> Cryptographic Message Syntax (CMS) >>> Author(s) : B. Salter, A. Raine, D. Van Geest >>> WG Chair(s) : Russ Housley, Tim Hollebeek >>> Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
