None of the authors have approved the draft yet. See https://www.rfc-editor.org/auth48/rfc9882
Russ > On Oct 14, 2025, at 7:21 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 PM Adam R <[email protected] > <mailto:[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] >> <mailto:[email protected]>> >> Sent: Friday, October 10, 2025 20:22 >> To: Adam R <[email protected] <mailto:[email protected]>> >> Cc: Ben S3 <[email protected] <mailto:[email protected]>>; RFC Editor >> <[email protected] <mailto:[email protected]>>; >> [email protected] >> <mailto:[email protected]> >> <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]> <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]> <[email protected] >> <mailto:[email protected]>>; Russ Housley <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]> <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]> <[email protected] >> <mailto:[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] >> <mailto:[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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.xml&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268246479%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=uqerqXC6nzT9MwE3Wi3K1PTn9aKhrPYtyZhZfV%2Bpk2E%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882.xml> >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.txt&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268268275%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=phy5HggE1xt96aJPJsvS4yUqiVwPhBMRWHbcI9IIjgU%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882.txt> >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.pdf&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268282284%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Ov69TGX7uxf6OOlYSY9z3E9yfnpj%2BzyW0KCN%2FM3PWWI%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882.pdf> >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268295960%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=aWOegTwccTsZt6DzNPBpMl5DF49uguB7U2ST6cXFnHM%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882.html> >> >> AUTH48 diffs: >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882-auth48diff.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268314893%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=vHj8DsiiTxLubiI8mI8LX%2BU32wU57aS5Tkgtlqyr5eU%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882-auth48diff.html> >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882-auth48rfcdiff.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268328968%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=ka%2B1vNFu1FJbxX%2BmYm9ciw8Lz0vw2xnaICR0p4eMSjo%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882-auth48rfcdiff.html> (side by >> side) >> >> Comprehensive diffs: >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882-diff.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268342596%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=j0oHVO5rhHrBZmGXixYkJz3hJZ4qlaCykqvc9dtcJz4%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882-diff.html> >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882-rfcdiff.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268356005%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=a0bc4VjqUR0sE6qi64cXezLOJ8DEzESVNzw7wIcIXJw%3D&reserved=0 >> <https://www.rfc-editor.org/authors/rfc9882-rfcdiff.html> (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 AM, Adam R <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi Sandy, >> > >> > • 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. >> > >> > • 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. >> > >> > • I also think this is fine. >> > >> > • 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. >> > >> > • 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] <mailto:[email protected]>> >> > Sent: Friday, October 10, 2025 08:15 >> > To: [email protected] <mailto:[email protected]> >> > <[email protected] <mailto:[email protected]>>; Adam R >> > <[email protected] <mailto:[email protected]>>; >> > [email protected] >> > <mailto:[email protected]> >> > <[email protected] >> > <mailto:[email protected]>> >> > Cc: [email protected] <mailto:[email protected]> <[email protected] >> > <mailto:[email protected]>>; [email protected] >> > <mailto:[email protected]> <[email protected] >> > <mailto:[email protected]>>; [email protected] >> > <mailto:[email protected]> <[email protected] >> > <mailto:[email protected]>>; [email protected] >> > <mailto:[email protected]> <[email protected] >> > <mailto:[email protected]>>; [email protected] >> > <mailto:[email protected]> <[email protected] >> > <mailto:[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] <mailto:[email protected]> >> > <[email protected] <mailto:[email protected]>> >> > Sent: 10 October 2025 00:56 >> > To: Ben S3 <[email protected] <mailto:[email protected]>>; Adam R >> > <[email protected] <mailto:[email protected]>>; >> > [email protected] >> > <mailto:[email protected]> >> > Cc: [email protected] <mailto:[email protected]>; >> > [email protected] <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[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 “x509”. >> > >> > RFC-to-be 9881 has not yet been updated. >> > >> > Note that the current list of preferred values for "type" is available at >> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode-types&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268369318%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2FvZG8aXo3FUtJemb9RG3zCCB%2FHBv1ZzpBp0U%2BnfRTHU%3D&reserved=0 >> > <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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268382976%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=qC0%2BlreUc%2FAnrJptTYFtdKkcgFes%2FR6rq1W5fhaZoUs%3D&reserved=0 >> > <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 PM, [email protected] >> > <mailto:[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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268396289%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=ESZs4U6kw8XiwEMiiya9mgI4yYXOs9bUmm2YYPsSVd8%3D&reserved=0 >> > <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 – >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268409594%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=LoVNU82ed0EY43ttWhNEiMBFdQhTXhVQhiCwftjLa0g%3D&reserved=0) >> > <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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268423430%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=CX44Od6rwC4KIMDBWBbI91ChDiSkeSAS4q5%2Brzt%2FgC8%3D&reserved=0 >> > <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 ‘REPLY ALL’ as all >> > the parties CCed on this message need to see your changes. The parties >> > include: >> > >> > * your coauthors >> > >> > * [email protected] <mailto:[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] <mailto:[email protected]>, >> > which is a new archival mailing list >> > to preserve AUTH48 conversations; it is not an active discussion >> > list: >> > >> > * More info: >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268437376%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=hkixNS2Wd7Pm7JUtZxAsUbMNIJabo4wi6gvdcVdJY1o%3D&reserved=0 >> > >> > <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> >> > >> > * The archive itself: >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268450579%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=9R7tNDKE7cjWCdxbv1U%2BSHfxNp41WocYr90NZd0nwQk%3D&reserved=0 >> > <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] <mailto:[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 >> > — OR — >> > 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 ‘REPLY ALL’, >> > as all the parties CCed on this message need to see your approval. >> > >> > >> > Files >> > ----- >> > >> > The files are available here: >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.xml&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268466912%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=E1ttndI6QoKO5Kh%2FJzo4pLT4w2lB0Lf3SyHpAKgiy0U%3D&reserved=0 >> > <https://www.rfc-editor.org/authors/rfc9882.xml> >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268480506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=S0f69ao7lAF1eY7CdJ3y0Qi7aIWilHt2QOKg%2BdMobDI%3D&reserved=0 >> > <https://www.rfc-editor.org/authors/rfc9882.html> >> > >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.pdf&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268493915%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=B95nK%2BMp4LbYxqSsclN13NqSkaNm8bzfQMMEh5%2FCs4s%3D&reserved=0 >> > <https://www.rfc-editor.org/authors/rfc9882.pdf> >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882.txt&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268507232%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=ZLqnM4hf5VVAQDl%2F6JVQ1dKYv3mHz%2BT1rC6CqFvWdLI%3D&reserved=0 >> > <https://www.rfc-editor.org/authors/rfc9882.txt> >> > >> > Diff file of the text: >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882-diff.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268520523%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=qutguWINIvH7HtM9l2TtpfZl2wSJoAHVW2wT%2FXCg1Vk%3D&reserved=0 >> > <https://www.rfc-editor.org/authors/rfc9882-diff.html> >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882-rfcdiff.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268533784%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=grW8b3egwN5wPE%2FNLHKO7LP%2BnN5vKICbOTP8Txu4txQ%3D&reserved=0 >> > <https://www.rfc-editor.org/authors/rfc9882-rfcdiff.html> (side by side) >> > >> > Diff of the XML: >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9882-xmldiff1.html&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268547103%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=7sC6328tZnfKJxp03mR9iPiE%2B5olPxnfM3jDAZwJyg0%3D&reserved=0 >> > <https://www.rfc-editor.org/authors/rfc9882-xmldiff1.html> >> > >> > >> > Tracking progress >> > ----------------- >> > >> > The details of the AUTH48 status of your document are here: >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9882&data=05%7C02%7CAdam.r%40ncsc.gov.uk%7Cdb7d96e5cb2346297b2008de08332eaf%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638957213268560479%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=nrRcJB5nUAsuvk4%2BFyhEdIuSHUsNjW5vFIGkQWoehn8%3D&reserved=0 >> > <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]
