And Adam asked for a change?

On Tue, Oct 14, 2025 at 8:08 AM Russ Housley <[email protected]> wrote:

> 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]> 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://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 <Adam.r=
>> [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]>
>> > 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 “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] 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] (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://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] 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]

Reply via email to