I approve the change. Deb
On Mon, Feb 23, 2026 at 3:23 PM Madison Church <[email protected]> wrote: > Hi Daniel, *Deb, > > Daniel - Thank you for your reply! We have updated the document > accordingly. > > *Deb - As responsible AD, please let us know if you approve the correction > in Section 2.4 (which can be viewed in this diff file: > https://www.rfc-editor.org/authors/rfc9936-auth48diff.html). > > Authors - Please review the document carefully to ensure satisfaction as > we do not make changes once it has been published as an RFC. Contact us > with any further updates or with your approval of the document in its > current form. We will await approvals from each author prior to moving > forward in the publication process. > > Updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9936.txt > https://www.rfc-editor.org/authors/rfc9936.pdf > https://www.rfc-editor.org/authors/rfc9936.html > https://www.rfc-editor.org/authors/rfc9936.xml > > Updated diff files: > https://www.rfc-editor.org/authors/rfc9936-diff.html > https://www.rfc-editor.org/authors/rfc9936-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9936-auth48diff.html > https://www.rfc-editor.org/authors/rfc9936-auth48rfcdiff.html (side by > side) > > AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9936 > > Thank you! > > Madison Church > RFC Production Center > > > On Feb 23, 2026, at 5:06 AM, Daniel Van Geest < > [email protected]> wrote: > > > > Hi Madison and all, > > > > I have just discovered an error in draft-ietf-lamps-cms-kyber-13. > > > > The wrong content type was mentioned in section 2.4. The correct > content types are mentioned throughout the rest of the document, so this > section should be corrected to align with the rest of the document. > > > > OLD: > > > > Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to > > announce a partial list of algorithms that an S/MIME implementation > > can support. When constructing a CMS signed-data content type > > [RFC5652], a compliant implementation MAY include the > > SMIMECapabilities attribute that announces support for one or more of > > the ML-KEM algorithm identifiers. > > > > NEW: > > > > Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to > > announce a partial list of algorithms that an S/MIME implementation > > can support. When constructing a CMS enveloped-data content type, a > > CMS authenticated-data content type, or a CMS authenticated- > > enveloped-data content type, a compliant implementation MAY include > > the SMIMECapabilities attribute that announces support for one or > > more of the ML-KEM algorithm identifiers. > > > > Thanks, > > Daniel > > > > From: Madison Church <[email protected]> > > Sent: Thursday, February 19, 2026 9:35 PM > > To: Daniel Van Geest <[email protected]>; Julien > Prat <[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]>; [email protected] < > [email protected]> > > Subject: Re: AUTH48: RFC-to-be 9936 <draft-ietf-lamps-cms-kyber-13> for > your review > > > > Hi Daniel, > > > > Thank you for your response! We have updated the document per your reply > and we have no followup questions at this time. Once we have all author > approvals for this document (and once RFC-to-be 9935 completes AUTH48), we > will move this document forward in the publication process. > > > > The updated files have been posted here (please refresh): > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.txt&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106424033%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=eBOlZz5DecuadtcDGTOYApppdecjrr5JVLm82BtKBGI%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.pdf&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106437215%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=hRurVTAIr6FWXpkweLrx7GTtApkCmcRP7m2PABtZD7k%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106445354%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=TiK1grHP1%2FoMoH3FLr0FF4AkHDWzE%2FU4vN5A1%2F4pNgg%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.xml&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106452931%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=7mAnGWnx7zWJwh8FVxeQ8Bu4jmyIXRMhaVBs60MSwoY%3D&reserved=0 > > > > Diff files: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936-diff.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106460489%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=EdAVvywiXMJ89K2tV1zeSMhUXSRt9Y94uaOAtYij0Q8%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936-rfcdiff.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106467806%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=DUqrVAvwXY2C3JqySKfSM9mwKmTQsBmxAWlhv%2BOUvjk%3D&reserved=0 > (side by side) > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936-auth48diff.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106474936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=P1xUZ7nUee0HsFtCI0vAw4MaZveAGuRxCpljRQhB5hQ%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936-auth48rfcdiff.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106482314%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=lU88DIvaAUx1%2FhjL1P9PRQ8F%2BVdgUm4jMgSx1UdwaIk%3D&reserved=0 > (side by side) > > > > For the AUTH48 status page, see: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9936&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106489489%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=q%2Fxr3C3qzMBsRbnmuY4MbiHWuy6H7g0KJEa1%2FbzxxWk%3D&reserved=0 > . > > > > Thank you! > > Madison Church > > RFC Production Center > > > > > On Feb 16, 2026, at 7:40 AM, Daniel Van Geest <daniel.vangeest= > [email protected]> wrote: > > > > > > Responses inline > > > On 2026-02-10 5:02 a.m., [email protected] wrote: > > >> Authors, > > >> > > >> While reviewing this document during AUTH48, please resolve (as > necessary) > > >> the following questions, which are also in the source file. > > >> > > >> 1) <!-- [rfced] FYI: We have updated "Module Lattice Key Encapsulation > > >> Mechanism" to "Module-Lattice-Based Key-Encapsulation Mechanism" to > match > > >> its use in NIST FIPS 203 and draft-ietf-lamps-kyber-certificates (and > for > > >> consistency with the Abstract). Please let us know any objections. > > >> > > >> Original: > > >> The Module Lattice Key Encapsulation Mechanism (ML-KEM) is an > > >> IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in > > >> [FIPS203] by the NIST PQC Project [NIST-PQ]. > > >> > > >> Current: > > >> The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is an > > >> IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in > > >> [FIPS203] by the NIST PQC Project [NIST-PQ]. > > >> --> > > > Looks good > > >> > > >> > > >> > > >> 2) <!-- [rfced] FYI: We believe "MK-KEM-512" should be "ML-KEM-512". > We > > >> have corrected as follows. > > >> > > >> Original: > > >> This document specifies the direct use of ML-KEM in the > > >> KEMRecipientInfo structure using each of the three parameter sets from > > >> [FIPS203], namely MK-KEM-512, ML-KEM-768, and ML-KEM-1024. > > >> > > >> Current: > > >> This document specifies the direct use of ML-KEM > > >> in the KEMRecipientInfo structure using each of the three parameter > > >> sets from [FIPS203], namely ML-KEM-512, ML-KEM-768, and ML-KEM-1024. > > >> --> > > > Looks good > > >> > > >> > > >> 3) <!-- [rfced] We have updated the following sentence since we fully > > >> expanded HKDF. Please let us know any objections. > > >> > > >> Original: > > >> Implementations MUST support HKDF [RFC5869] with SHA-256 [FIPS180], > > >> using the id-alg-hkdf-with-sha256 KDF object identifier [RFC8619]. > > >> > > >> Current: > > >> Implementations MUST support the HMAC-based Key Derivation Function > > >> (HKDF) [RFC5869] with SHA-256 [FIPS180] using the id- alg-hkdf-with- > > >> sha256 KDF object identifier [RFC8619]. > > >> --> > > > Looks good > > >> > > >> > > >> 4) <!-- [rfced] References > > >> > > >> a) FYI: We updated the date for [CSOR] from "20 August 2024" to "13 > > >> June 2025" to match the most current date provided at the URL. > > >> > > >> Original: > > >> [CSOR] NIST, "Computer Security Objects Register", 20 August > > >> 2024, < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fcomputer-security-&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106496563%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=j0oIOwAywjcujHnfd9kQ0R0hC0iGNQMO5LxcRStcT2U%3D&reserved=0 > > >> objects-register/algorithm-registration>. > > >> > > >> Current: > > >> [CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June > > >> 2025, < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fcomputer-security-&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106503897%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=dlKhDFzQIxsMc1GOnS2orQB%2Bxk8WIx8okE1S%2B9JuBkI%3D&reserved=0 > > >> objects-register/algorithm-registration>. > > > Looks good > > >> > > >> b) FYI: We've updated the date for [NIST-PQ] from "20 December 2016" > to > > >> "30 September 2025" to match the most current date provided at the > URL. > > >> > > >> Original: > > >> [NIST-PQ] National Institute of Standards and Technology, "Post- > > >> Quantum Cryptography Project", 20 December 2016, > > >> < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fpost-quantum-&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106511016%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=hEoXDrRB2HqN9LYXmE9Jh1xdI2IoooLfKwmn46XRJh0%3D&reserved=0 > > >> cryptography>. > > >> > > >> Current: > > >> [NIST-PQ] NIST, "Post-Quantum Cryptography (PQC)", 30 September > > >> 2025, < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fpost-quantum-&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106520455%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=wlxVxUeE2BVV5dfsFEhsd%2F3H3LFh1zpcXrosgg%2FOmZo%3D&reserved=0 > > >> cryptography>. > > > Looks good > > >> > > >> > > >> c) FYI: We've updated the date for [CMVP] from "2016" to "3 September > > >> 2025" to match the most current date provided at the URL. > > >> > > >> Original: > > >> [CMVP] National Institute of Standards and Technology, > > >> "Cryptographic Module Validation Program", 2016, > > >> < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fcryptographic-module-&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106530485%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Oi3xC%2Bim0kp7FP42qDdSrZJNURBYCjgcYfiI25V5P5g%3D&reserved=0 > > >> validation-program>. > > >> > > >> Current: > > >> [CMVP] NIST, "Cryptographic Module Validation Program (CMVP)", 3 > > >> September 2025, < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fprojects%2F&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106538264%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Saj%2BjG%2BptlkT4MQqSJIqr0amhsgygnzIrSUXZDpCJko%3D&reserved=0 > > >> cryptographic-module-validation-program>. > > > Looks good > > >> > > >> > > >> d) We note that draft-kampanakis-ml-kem-ikev2-09 has been replaced > with > > >> draft-ietf-ipsecme-ikev2-mlkem-03. We have updated the reference > > >> accordingly. Please let us know if this is incorrect. > > >> --> > > > Looks good > > >> > > >> > > >> > > >> 5) <!-- [rfced] The following line exceeds the line limit by 3 > characters. > > >> Please review and let us know how this line can be modified. > > >> > > >> 980 16: OCTET STRING 5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33 > > >> > > >> --> > > > The line can be wrapped. I have re-run my dumpasn1 script with > tighter wrapping. For consistency this causes all of the hex lines to be > shifted left slightly. Here is the fully re-processed sample: > > > NEW: > > > 0 994: SEQUENCE { > > > 4 11: OBJECT IDENTIFIER > > > : authEnvelopedData (1 2 840 113549 1 9 16 1 23) > > > 17 977: [0] { > > > 21 973: SEQUENCE { > > > 25 1: INTEGER 0 > > > 28 888: SET { > > > 32 884: [4] { > > > 36 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3' > > > 49 867: SEQUENCE { > > > 53 1: INTEGER 0 > > > 56 20: [0] > > > : 59 97 88 C3 7A ED 40 0E E4 05 D1 B2 A3 36 6A B1 > > > : 7D 82 4A 51 > > > 78 11: SEQUENCE { > > > 80 9: OBJECT IDENTIFIER '2 16 840 1 101 3 4 4 1' > > > : } > > > 91 768: OCTET STRING > > > : 3E A4 0F C6 CA 09 0E 2C 8A F7 6E 27 27 AB 38 E0 > > > : 65 2D 95 15 98 6F E1 86 82 7F E8 4E 59 6E 42 1B > > > : 85 FD 45 9C C7 89 97 37 2C 9D E3 1D 19 1B 39 C1 > > > : D5 A3 EB 6D DB 56 AA DE DE 76 5C C3 90 FD BB C2 > > > : F8 8C B1 75 68 1D 42 01 B8 1C CD FC B2 4F EF 13 > > > : AF 2F 5A 1A BC F8 D8 AF 38 4F 02 A0 10 A6 E9 19 > > > : F1 98 7A 5E 9B 1C 0E 2D 3F 07 F5 8A 9F A5 39 CE > > > : 86 CC 14 99 10 A1 69 2C 0C A4 CE 0E CE 4E EE D2 > > > : E6 69 9C B9 76 33 24 52 DE 4A 2E B5 CA 61 F7 B0 > > > : 81 33 0C 34 79 8E F7 12 A2 4E 59 C3 3C EA 1F 1F > > > : 9E 6D 4F BF 37 43 A3 84 67 43 00 11 33 6F 62 D8 > > > : 70 79 2B 86 6B EF CD 1D 1B 36 5B ED 19 52 67 3D > > > : 3A 5B 0C 20 B3 86 B4 EF D1 CF 63 FD 37 6B D4 7C > > > : CC 46 AC 4D D8 EC 66 B0 47 C4 C9 5A CF F1 CF D0 > > > : 28 A4 19 B0 02 FD A1 B6 17 CB A6 1D 2E 91 CF E8 > > > : FF FB CB 8F FD 4D 5F 6A D8 B1 58 C2 19 E3 6D C5 > > > : 14 05 DC 0C 0B 23 49 79 AC 65 8E 72 BD DF 1B 67 > > > : 73 B9 6B 2A E3 E4 D0 7B E8 60 48 04 0C 01 67 43 > > > : 6F A8 39 E7 52 9B 00 CC 9A B5 5A 2F 25 DB 63 CC > > > : 9F 55 75 94 E6 91 C1 1E 55 3D 4A 3E BC 76 0F 5F > > > : 19 E5 FE 14 48 38 B4 C7 D1 59 1D A9 B5 D4 67 49 > > > : 4F D9 CA C5 2C C5 50 40 60 39 9D BD B7 22 98 EB > > > : 9A 4C 01 7B 00 78 6F DC 7D 9D 7A A5 7A DB B8 B6 > > > : 1C 34 DE 1E 28 8B 2A B7 28 17 1D CE 14 3C D1 69 > > > : 53 F9 84 C1 AE D5 59 E5 6B AA 0C E6 58 D3 2C CE > > > : 42 F4 40 75 04 CD 7A 57 9A D0 EF 9B 77 13 5E AA > > > : 39 B6 F9 3A 3A 2E 59 97 80 7F 06 36 1C 83 F4 E6 > > > : 7F 8E 3F 9C F6 83 16 01 15 14 F5 D8 5A 18 1C EA > > > : D7 14 CD 49 40 E4 EB AC 01 D6 65 28 DA 32 F8 9C > > > : EA 04 28 E8 EB CA DC F8 AA 18 8C 9F 62 E8 5B 19 > > > : 57 65 5B 7F E2 B8 D7 97 3B 7A 72 26 B6 6D 93 BF > > > : 7B 23 2F 3D CF 65 3C 84 B4 EC F1 A9 92 0D B1 94 > > > : 9A D7 50 B5 46 A5 55 2A 20 E5 49 09 71 9B 8C 0C > > > : 07 05 6F CB 7E 57 4A D2 A3 2E C9 50 01 DD E8 44 > > > : 81 BE 77 D0 39 ED 5B F7 42 62 EC F3 98 1F 1B 00 > > > : D3 36 6A 9C 2E 06 1C 47 E2 41 A0 61 C6 24 95 60 > > > : D2 B8 44 6A 48 0C 38 C2 8B A9 89 D9 F6 8A DC 4B > > > : BA F2 A2 0B 47 E4 92 31 28 C7 23 42 D5 97 FD A2 > > > : 59 DE 0B 83 C2 05 6D 6B 77 E7 99 B3 19 32 4A A5 > > > : 0B 1D 65 9C 2A 56 02 9B 74 53 C5 F3 BA 52 43 D9 > > > : FA 74 9D 91 7C 40 D9 D1 01 E4 53 BC 8B 10 E4 2A > > > : 7C 08 93 23 C0 26 F7 83 E1 00 B9 FA 6E 70 14 42 > > > : 4D A6 FA 37 92 BC 95 7E E8 21 9D 01 6B 77 3F 28 > > > : FE DC C9 62 A4 85 AB AF FE C0 23 28 19 71 E2 9A > > > : A6 89 83 9E CF D2 61 9E 92 28 7C D2 30 DB 26 A2 > > > : 50 7C C5 00 EB 1C 7A 52 93 B5 FE 91 7A E2 9B F1 > > > : AD 35 01 24 F8 A3 11 63 52 14 B4 11 DB 9F 67 D3 > > > : B8 5B D7 15 01 85 37 EA 45 B4 1F 41 B4 C6 60 51 > > > 863 13: SEQUENCE { > > > 865 11: OBJECT IDENTIFIER > > > : hkdfWithSha256 (1 2 840 113549 1 9 16 3 28) > > > : } > > > 878 1: INTEGER 16 > > > 881 11: SEQUENCE { > > > 883 9: OBJECT IDENTIFIER > > > : aes128-wrap (2 16 840 1 101 3 4 1 5) > > > : } > > > 894 24: OCTET STRING > > > : C0 50 E4 39 2F 9C 14 DD 0A C2 22 02 03 F3 17 D7 > > > : 01 F9 4F 9D D9 27 78 F5 > > > : } > > > : } > > > : } > > > 920 58: SEQUENCE { > > > 922 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) > > > 933 30: SEQUENCE { > > > 935 9: OBJECT IDENTIFIER > > > : aes128-GCM (2 16 840 1 101 3 4 1 6) > > > 946 17: SEQUENCE { > > > 948 12: OCTET STRING 5C A5 74 68 B8 1B F0 3B 8D A7 18 6C > > > 962 1: INTEGER 16 > > > : } > > > : } > > > 965 13: [0] 94 C8 68 9A 99 D2 C3 8E 19 2F A6 BA 08 > > > : } > > > 980 16: OCTET STRING > > > : 5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33 > > > : } > > > : } > > > : } > > > > > >> > > >> 6) <!-- [rfced] The following was provided in response to the intake > form: > > >> > > >> Acknowledgements should maybe mention > draft-ietf-lamps-kyber-certificates. > > >> There is an Informative reference to I-D.kampanakis-ml-kem-ikev2 > which is only referenced from the Acknowledgements section. That s polite, > but if this RFC will be delayed waiting for the other one, then it can be > removed. > > >> > > >> Please provide text if you would like to update the Acknowledgements > > >> section. Note that draft-ietf-lamps-kyber-certificates is now in > AUTH48 as > > >> RFC-to-be 9935. > > >> --> > > > The first paragraph of the acknowledgements section can be updated as > follows to mention RFC9935. As this is just an acknowledgement, I don't > think draft would be delayed waiting on kampanakis-ml-kem-ikev2. If that's > the case, we can change the text further. > > > NEW: > > > This document borrows heavily from [RFC9690], [FIPS203], [RFC9935], > > > and [I-D.ietf-ipsecme-ikev2-mlkem]. Thanks go to the authors of > > > those documents. "Copying always makes things easier and less error > > > prone" - RFC8411. > > >> > > >> 7) <!-- [rfced] FYI - We updated artwork elements to sourcecode per > the > > >> guidance given in the document intake form: > > >> > > >> "...the two-line code block in section 2.2.1, the identifiers in > section 3 > > >> and especially the sample data in Appendix C." > > >> > > >> A) Please review and let us know if any other artwork elements need > to be > > >> marked as sourcecode. > > > No additional artworks need to be marked as sourcecode. > > >> > > >> B) Please review the current list of preferred values for sourcecode > "type" > > >> ( > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode-types&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106546142%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=B7esviotwtVEiE%2BaST8hk0a9ZNkTnDZibBAMG4tRpnw%3D&reserved=0 > ) > > >> and let us know how/if type should be set. If the list does not > contain an > > >> applicable type, then feel free to let us know. Also, note that it is > > >> acceptable to leave the "type" attribute not set. > > >> --> > > > These are the appropriate types: > > > Section 2.2.1: pseudocode > > > Section 3: asn.1 > > > Appendix C: test-vectors > > >> > > >> 8) <!-- [rfced] We have added expansions for abbreviations throughout > the > > >> document and use abbreviated forms for expansions upon first use. > Please > > >> let us know any objections. > > >> --> > > > Looks good > > >> > > >> > > >> 9) <!-- [rfced] Please review the "Inclusive Language" portion of the > > >> online Style Guide < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106553707%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=eXfKeR9EHNhiLCVIEVmodDXjup6RS6JyAOjaBDq39t8%3D&reserved=0 > > > > >> 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. > > >> > > >> In addition, please consider whether "tradition" should be updated for > > >> clarity. While the NIST website > > >> < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.gov%2Fnist-research-library%2Fnist-technical-series-publications-author-instructions%23table1&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106561467%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ZqPGwOVSRNfmny4kF8nChfSblT%2Btoaxx3oGzQ1tQSjY%3D&reserved=0 > > > > >> indicates that this term is potentially biased, it is also ambiguous. > > >> "Tradition" is a subjective term, as it is not the same for everyone. > > >> Possible substitutions for "traditional" (used in past RFCs) include > > >> "commonly used", "typical", "long-established", "conventional", and > > >> "time-honored". --> > > > This question can be sidestepped by removing "traditional" entirely: > > > OLD: > > > Instead of defining the strength of a quantum algorithm in a > > > traditional manner using the imprecise notion of bits of security, > > > NEW: > > > Instead of defining the strength of a quantum algorithm using the > > > imprecise notion of bits of security, > > >> > > >> Thank you. > > >> Madison Church and Sandy Ginoza > > >> RFC Production Center > > > Thanks, > > > Daniel > > >> > > >> > > >> On Feb 9, 2026, at 8:59 PM, [email protected] wrote: > > >> > > >> *****IMPORTANT***** > > >> > > >> Updated 2026/02/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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106568937%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2F65kEXn39JX84rBXeyr0Yf0PR%2FPWT2BQTzacIh%2BUrFo%3D&reserved=0 > ). > > >> > > >> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106576216%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=YrcK36jLws5oU5hUUEPxWysuH6sIUc9epcMyG5X5gNY%3D&reserved=0 > ). > > >> > > >> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106583578%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=MB6rFGcf%2FiK5nTgV9H6%2BlrhSRMIbD1BdVajKD8Z1tnA%3D&reserved=0 > >. > > >> > > >> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106591115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=50Iz6uxJrJRww7Qq2ZwDc8kGhZBgp17grg1zr0JQ0Vw%3D&reserved=0 > > >> > > >> * The archive itself: > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106598660%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Q9ctvgxbwVVM%2BbvOTNf2fUQiZypIlPnv%2BMdB2b%2Bn%2BnI%3D&reserved=0 > > >> > > >> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.xml&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106606068%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=p91a05OTMYaeVtHxc6ZeFY%2FN5w%2FR3C4wYgNjWjj2U84%3D&reserved=0 > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106613275%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=leGz%2B2joSVQMl2FTEfkWxrBDKXChoDZJtzBeq4hnmJs%3D&reserved=0 > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.pdf&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106620536%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=BPOOQsUBg%2BJknDUd4OrgFhYuIVct6ptMcS4v%2BbLhiuE%3D&reserved=0 > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936.txt&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106628047%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2FSEEPVrUH4T6qGeqdJnJq%2Fnnvxpj7v2cXhlNA2YZU8U%3D&reserved=0 > > >> > > >> Diff file of the text: > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936-diff.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106635476%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Tcc%2BONTPmeuRPTGy1IXmRuaX1pAZkseym3DL2eK9sUY%3D&reserved=0 > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936-rfcdiff.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106642620%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=IclSgwXAjYJm1KJnSLQRkx7DVfUkNtc%2BhA1FjYCNXsY%3D&reserved=0 > (side by side) > > >> > > >> Diff of the XML: > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9936-xmldiff1.html&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106649867%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=HpAQbf%2F7ERt%2BGmex4WR1Azxc3wFs%2BubdIh2flXrAigI%3D&reserved=0 > > >> > > >> > > >> Tracking progress > > >> ----------------- > > >> > > >> The details of the AUTH48 status of your document are here: > > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9936&data=05%7C02%7Cdaniel.vangeest%40cryptonext-security.com%7C78cca519b7fe4ae0c6d608de6ffee9ca%7Cda4a2df14b1b489da7f4224b58fd4200%7C0%7C0%7C639071338106657036%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=hV4jt9f4eWj9LPnLgqb84B1UDpvbcT1GKAP3ndU41k4%3D&reserved=0 > > >> > > >> Please let us know if you have any questions. > > >> > > >> Thank you for your cooperation, > > >> > > >> RFC Editor > > >> > > >> -------------------------------------- > > >> RFC 9936 (draft-ietf-lamps-cms-kyber-13) > > >> > > >> Title : Use of ML-KEM in the Cryptographic Message Syntax (CMS) > > >> Author(s) : P. Julien, M. Ounsworth, 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]
