Hi Alanna Paloma, I agree with the responses from Gilles as well.
Thank you and Regards, Quynh. > -----Original Message----- > From: Gilles VAN ASSCHE <[email protected]> > Sent: Tuesday, September 23, 2025 5:25 AM > To: Alanna Paloma <[email protected]>; [email protected]; > [email protected]; Dang, Quynh H. (Fed) > <[email protected]>; [email protected] > Cc: RFC Editor <[email protected]>; [email protected]; > [email protected]; auth48archive <auth48archive@rfc- > editor.org> > Subject: [EXTERNAL] RE: AUTH48: RFC-to-be 9861 <draft-irtf-cfrg- > kangarootwelve-17> for your review > > Dear Alanna Paloma, > > Sorry for the delay. > > Please find enclosed answers to your comments and questions. From informal > discussions with the other authors, I know that some of them agree with > these, but I let them confirm officially. :-) > > Kind regards, > Gilles > > > ST Restricted > -----Original Message----- > From: Alanna Paloma <[email protected]> > Sent: lundi 22 septembre 2025 19:56 > To: [email protected]; [email protected]; Gilles VAN ASSCHE > <[email protected]>; [email protected]; [email protected] > Cc: RFC Editor <[email protected]>; [email protected]; > [email protected]; auth48archive <auth48archive@rfc- > editor.org> > Subject: Re: AUTH48: RFC-to-be 9861 <draft-irtf-cfrg-kangarootwelve-17> for > your review > > Greetings, > > We do not believe we have heard from you regarding this document's > readiness for publication. Please review our previous messages describing the > AUTH48 process and containing any document-specific questions we may > have had. > > We will wait to hear from you before continuing with the publication process. > > The AUTH48 status page for this document is located here: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > rfc- > editor.org%2Fauth48%2Frfc9861&data=05%7C02%7Cquynh.dang%40nist.g > ov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e0 > 54655c61dec%7C0%7C0%7C638942163357236765%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW > 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y9crja > qWPAE%2Bnc3MSzBk29xviAKB%2BdV550k7HWpIafI%3D&reserved=0 > > Thank you, > Alanna Paloma > RFC Production Center > > > On Sep 15, 2025, at 6:20 PM, [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] Please ensure that the guidelines listed in Section 2.1 > > of RFC 5743 have been adhered to in this document. --> > > > > > > 2) <!--[rfced] Should the document's short title, which can be seen in > > the header of the PDF output, include "TurboSHAKE" to reflect the full > document title? > > > > Original: > > KangarooTwelve > > > > Perhaps: > > KangarooTwelve and TurboSHAKE > > --> > > > > > > 3) <!--[rfced] May we clarify that "similarly to the SHAKE's" is > > referring to the SHAKE's security? > > > > Original: > > Similarly to the SHAKE's, it proposes two security strengths: > > 128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256. > > > > Perhaps: > > Similarly to the SHAKE's security, it proposes two security strengths: > > 128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256. > > --> > > > > > > 4) <!--[rfced] Section 1. We rephrased the following sentence for > > consistency with the other sentences in the list and to avoid using > > citations as adjectives. If it changes the intended meaning, please > > let us know. > > > > Original: > > * Unlike any [FIPS202] and [SP800-185] functions but ParallelHash, > > KT128 and KT256 exploit available parallelism. > > > > Perhaps: > > * Unlike any functions in [FIPS202] and [SP800-185] except for > > ParallelHash, KT128 and KT256 exploit available parallelism. > > --> > > > > > > 5) <!--[rfced] Section 2.1. We rephrased this text to match similar > > text in the first paragraph of Section 3.1. If it changes the intended > > meaning, please let us know. > > > > Original: > > An instance of TurboSHAKE takes as input parameters a byte-string M, > > an OPTIONAL byte D and a positive integer L where > > > > Current: > > A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and > > a positive integer L as input parameters, where: > > --> > > > > > > 6) <!--[rfced] Please clarify "for any distinct values D1 and D2". Is > > the current text correct or is the intended meaning "for distinct > > values D1 and D2" (i.e., without "any")? > > > > Original: > > Specifically, for any distinct values D1 and D2, TurboSHAKE(M, D1, > > L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M. > > > > Perhaps: > > Specifically, for distinct values D1 and D2, TurboSHAKE(M, D1, > > L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M. > > --> > > > > > > 7) <!--[rfced] Is the space before the colon in "l_e( x ) :" > > intentional, or may we update the text as follows to avoid the added space? > > > > Current: > > The following figure illustrates the computation flow of KT128 > > for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x ) > > are abbreviated respectively as TSHK128 and l_e( x ) : > > > > Perhaps: > > The following figure illustrates the computation flow of KT128 > > for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x ) > > are abbreviated as TSHK128 and l_e( x ), respectively: > > --> > > > > > > 8) <!--[rfced] In the "COSE Algorithms" registry at > > > <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w > > > .iana.org%2Fassignments%2Fcose&data=05%7C02%7Cquynh.dang%40nist.g > ov%7C > > > c76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e054655c > 61dec%7C0%7C0%7C638942163357261580%7CUnknown%7CTWFpbGZsb > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BVAeMXy > ARCb4LwomvG%2BaB6cGocz2np%2B%2B%2B3vTAkY7QYI%3D&reserved=0> > , IANA lists the values in descending order. Should Table 3 be ordered to > match > the IANA registry (e.g., list "KT256 | -264 " first and "TurboSHAKE128 | -261" > last)? > > > > Also, may we include the "Recommended" column in Table 3 to match the > > IANA registry or include the following sentence in the lead-in text? > > Please let us know which option is preferred. > > > > Current: > > In the COSE Algorithms "COSE Algorithms" registry, IANA has added > > the following entries for TurboSHAKE and KangarooTwelve: > > > > Perhaps: > > In the COSE Algorithms "COSE Algorithms" registry, IANA has added > > the following entries for TurboSHAKE and KangarooTwelve. For each > > entry, the "Recommended" column contains "No". > > --> > > > > > > 9) <!--[rfced] To improve the readability of "the output L MUST be > > chosen long enough", may we update it to "the chose L output MUST be > long enough"? > > Note that this phrasing occurs in two sentences. > > > > Original: > > To achieve 128-bit > > security strength, the output L MUST be chosen long enough so that > > there are no generic attacks that violate 128-bit security. > > ... > > To achieve 256-bit security strength, the output L MUST be chosen long > > enough so that there are no generic attacks that violate 256-bit > > security. > > > > Perhaps: > > To achieve 128-bit > > security strength, the chosen L output MUST be long enough so that > > there are no generic attacks that violate 128-bit security. > > ... > > To achieve 256-bit security strength, the chosen L output MUST be long > > enough so that there are no generic attacks that violate 256-bit > > security. > > --> > > > > > > 10) <!--[rfced] As the first sentence is not a full sentence, may we > > combine the two sentences below into one sentence? > > > > Original: > > Lastly, as KT128 and KT256 use TurboSHAKE with three values for D, > > namely 0x06, 0x07, and 0x0B. Protocols that use both KT128 and > > TurboSHAKE128, or both KT256 and TurboSHAKE256, SHOULD avoid using > > these three values for D. > > > > Perhaps: > > Lastly, as KT128 and KT256 use TurboSHAKE with three values for D, > > namely 0x06, 0x07, and 0x0B, protocols that use both KT128 and > > TurboSHAKE128 or both KT256 and TurboSHAKE256 SHOULD avoid using > > these three values for D. > > --> > > > > > > 11) <!-- [rfced] References > > > > a) Would you like the references to be alphabetized or left in their > > current order? > > > > > > b) We note that the original [KT] reference entry contained two URL > > strings. > > > > The first URL is to a pre-print version of this article available from > > the Cryptology ePrint Archive with the most recent version being added > > in May 2018: > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Feprint. > iacr.org%2F2016%2F770.pdf&data=05%7C02%7Cquynh.dang%40nist.gov% > 7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e0546 > 55c61dec%7C0%7C0%7C638942163357275531%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SYSUTzuS > gZyyz6EI2LzayORosPCWy6ghUvGGIc3IXRI%3D&reserved=0. > > > > The other URL is to the published conference paper with a date of June > > 2018: https://link.springer.com/chapter/10.1007/978-3-319-93387-0_21. > > > > We have modified this reference to use the Springer Link URL as this > > appears to be the most recently published version that also includes a > > DOI. Please review and let us know if you have any objections. > > > > Original: > > [KT] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van > > Keer, R., and B. Viguier, "KangarooTwelve: fast hashing > > based on Keccak-p", WWW https://link.springer.com/ > > chapter/10.1007/978-3-319-93387-0_21, > > WWW > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Feprint. > iacr.org%2F2016%2F770.pdf&data=05%7C02%7Cquynh.dang%40nist.gov% > 7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e0546 > 55c61dec%7C0%7C0%7C638942163357288302%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WQGVLV > %2BJlmcmI8Oa1cUykpScrk8tJHgd%2BWrZwM9LAOI%3D&reserved=0, July > 2018. > > > > Current: > > [KT] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van > > Keer, R., and B. Viguier, "KangarooTwelve: Fast Hashing > > Based on Keccak-p", Applied Cryptography and Network > > Security (ACNS 2018), Lecture Notes in Computer Science, > > vol. 10892, pp. 400-418, DOI 10.1007/978-3-319-93387-0_21, > > June 2018, <https://link.springer.com/ > > chapter/10.1007/978-3-319-93387-0_21>. > > > > > > c) We note that the original [SAKURA] reference entry contained two > > URL strings. > > > > The first URL is to a pre-print version of this article available from > > the Cryptology ePrint Archive with the most recent version being added > > in April 2014: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint > .iacr.org%2F2013%2F231.pdf&data=05%7C02%7Cquynh.dang%40nist.gov% > 7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e0546 > 55c61dec%7C0%7C0%7C638942163357301443%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WyFvDUN > p82KIPw5AzixmMnvy1qmq%2BaCAo1K3x7uyKho%3D&reserved=0. > > > > The other URL is to the published conference paper with a date of > > 2014: https://link.springer.com/chapter/10.1007/978-3-319-07536-5_14. > > > > We have modified this reference to use the Springer Link URL as this > > appears to be the most recently published version that also includes a > > DOI. Please review and let us know if you have any objections. > > > > Original: > > [SAKURA] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, > > "Sakura: a flexible coding for tree hashing", WWW > > https://link.springer.com/ > > chapter/10.1007/978-3-319-07536-5_14, > > WWW > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Feprint. > iacr.org%2F2013%2F231.pdf&data=05%7C02%7Cquynh.dang%40nist.gov% > 7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e0546 > 55c61dec%7C0%7C0%7C638942163357455336%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yzbSfXDV > dI6YMM3TNYAQeOt6yD9SFtVlYjco8I2abqc%3D&reserved=0, June 2014. > > > > Current: > > [SAKURA] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, > > "Sakura: a Flexible Coding for Tree Hashing", Applied > > Cryptography and Network Security (ACNS 2014), Lecture > > Notes in Computer Science, vol. 8479, pp. 217-234, > > DOI 10.1007/978-3-319-07536-5_14, 2014, > > <https://link.springer.com/ > > chapter/10.1007/978-3-319-07536-5_14>. > > > > > > d) Since this reference is to a GitHub repository, please provide a > > commit hash in accordance with Part 2 of the RFC Style > > Guide: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23ref_repo&data=05%7C02%7Cquy > nh.dang%40nist.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d8 > 2fd8fa4797a93e054655c61dec%7C0%7C0%7C638942163357470722%7CU > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C > %7C&sdata=VjVSBkJOr4XiqXt4aT01uCMGWEeAn50XRaAr83ozOUI%3D&rese > rved=0. > > > > [XKCP] "eXtended Keccak Code Package", December 2022, > > <https://github.com/XKCP/XKCP>. > > --> > > > > > > 12) <!--[rfced] The following lines are 1 character over the > > 72-character limit. Please let us know how you would like to adjust > > the lines/spacing. > > > > Appendix A.4: > > CV = TurboSHAKE128(S[offset : offset + blockSize], `0B`, 32) > > > > Appendix A.5: > > CV = TurboSHAKE256(S[offset : offset + blockSize], `0B`, 64) > > --> > > > > > > 13) <!--[rfced] Throughout the text, the following terminology appears > > to be used inconsistently. Please review these occurrences and let us > > know if/how they may be made consistent. > > > > Chaining Value vs. chaining value > > Customization string vs. customization string Message vs. message > > --> > > > > > > 14) <!-- [rfced] Abbreviations > > > > a) FYI - We have added expansions for the following abbreviations per > > Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > expansion in the document carefully to ensure correctness. > > > > Elliptic Curve Diffie-Hellman (ECDH) > > Hashed Message Authentication Code (HMAC) Original Dialog Identifier > > (ODI) single instruction, multiple data (SIMD) > > > > b) FYI: We added a hyphen to the expansion of "XOF" per [FIPS202] and > > the NIST glossary. > > > > eXtendable Output Functions -> eXtendable-Output Functions > > --> > > > > > > 15) <!-- [rfced] Please review the "Inclusive Language" portion of the > > online Style Guide > > > <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w > > .rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 > > > C02%7Cquynh.dang%40nist.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8 > %7C2ab5d > > > 82fd8fa4797a93e054655c61dec%7C0%7C0%7C638942163357483838%7C > Unknown%7CT > > > WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiI > > > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DGuywhGp > nu0Nv9em3 > > fT8cATiZXXX%2FDcSmP%2BzRW4S3PU%3D&reserved=0> > > and let us know if any changes are needed. > > > > Note that our script did not flag any words in particular, but this > > should still be reviewed as a best practice. > > --> > > > > > > Thank you. > > > > Alanna Paloma and Karen Moore > > RFC Production Center > > > > > > > > On Sep 15, 2025, at 6:17 PM, RFC Editor via auth48archive > <[email protected]> wrote: > > > > *****IMPORTANT***** > > > > Updated 2025/09/15 > > > > 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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7Cquynh.dang%40nist.gov%7Cc76af > ae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e054655c61de > c%7C0%7C0%7C638942163357496624%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HKyrExUs66VG%2 > F6WdwSrjm9JdYmxPZcEcdO0ht6wD1Wk%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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftruste > e.ietf.org%2Flicense- > info&data=05%7C02%7Cquynh.dang%40nist.gov%7Cc76afae48ab24b7b1d1 > 308ddfa831bd8%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C6 > 38942163357508996%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo > yfQ%3D%3D%7C0%7C%7C%7C&sdata=ohWWqiRZLpp30HThDXEuc4mF83C > 9hPjuvvWNW0W%2BvSg%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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth > ors.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7Cquynh.dang%40nist.gov%7Cc76afae48ab24 > b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7 > C0%7C638942163357521380%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC > IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b5fvX%2F4DHZIXkXXzIZgE% > 2F0akHgr3sg9ppJxD2UHmHkE%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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > > archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxI&dat > > > a=05%7C02%7Cquynh.dang%40nist.gov%7Cc76afae48ab24b7b1d1308ddfa > 831bd8%7 > > > C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C638942163357533 > 639%7CUnkno > > > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > sIlAiOiJXa > > > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=H4a > jVAFxrQa > > rg33teHqc8btrE7kqi9nVPiByCJzIA0s%3D&reserved=0 > > Ae6P8O4Zc > > > > * The archive itself: > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > > > archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02% > 7Cquy > > > nh.dang%40nist.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d8 > 2fd8fa47 > > > 97a93e054655c61dec%7C0%7C0%7C638942163357546096%7CUnknown > %7CTWFpbGZsb3 > > > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoi > > > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g2%2FF1o%2FyJ9% > 2BF2TNdMUBD > > wsjTu06cy5iB749AfqC1ELs%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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc- > editor.org%2Fauthors%2Frfc9861.xml&data=05%7C02%7Cquynh.dang%40ni > s > > > t.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93 > e054655c > > > 61dec%7C0%7C0%7C638942163357558289%7CUnknown%7CTWFpbGZsb > 3d8eyJFbXB0eU1 > > > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > dUI > > > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=sn13fHd3kVHphtAUkkffItc1RXBg0 > n%2FnYkoVQ > > XGjQb0%3D&reserved=0 > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc- > editor.org%2Fauthors%2Frfc9861.html&data=05%7C02%7Cquynh.dang%40 > ni > > > st.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a9 > 3e054655 > > > c61dec%7C0%7C0%7C638942163357572736%7CUnknown%7CTWFpbGZs > b3d8eyJFbXB0eU > > > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldU > > > IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8oPI%2BCs3nPasyZCqySUXCr1XdI > %2BMXxYzqr > > tDnI0MDaY%3D&reserved=0 > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc- > editor.org%2Fauthors%2Frfc9861.pdf&data=05%7C02%7Cquynh.dang%40ni > s > > > t.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93 > e054655c > > > 61dec%7C0%7C0%7C638942163357585036%7CUnknown%7CTWFpbGZsb > 3d8eyJFbXB0eU1 > > > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > dUI > > > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=shypLP3dMWOqFBE12BRbMauInl > C8PABIT%2F%2F > > 2DloycBA%3D&reserved=0 > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc- > editor.org%2Fauthors%2Frfc9861.txt&data=05%7C02%7Cquynh.dang%40ni > s > > > t.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93 > e054655c > > > 61dec%7C0%7C0%7C638942163357597427%7CUnknown%7CTWFpbGZsb > 3d8eyJFbXB0eU1 > > > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > dUI > > > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=MgQ%2B3cW6SufndLlv3lrt8oDBCl > cNGANdl1aY4 > > t8u9DY%3D&reserved=0 > > > > Diff file of the text: > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc-editor.org%2Fauthors%2Frfc9861- > diff.html&data=05%7C02%7Cquynh.dang > > > %40nist.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4 > 797a93e0 > > > 54655c61dec%7C0%7C0%7C638942163357609855%7CUnknown%7CTWF > pbGZsb3d8eyJFb > > > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCI > > > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2B7ee%2FW5qhG6aO3%2 > BWxt2pD013FxE > > j95peFRar61DScJA%3D&reserved=0 > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc-editor.org%2Fauthors%2Frfc9861- > rfcdiff.html&data=05%7C02%7Cquynh.d > > > ang%40nist.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8 > fa4797a9 > > > 3e054655c61dec%7C0%7C0%7C638942163357622062%7CUnknown%7CT > WFpbGZsb3d8ey > > > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > > > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kTQ%2BhX1xnc3LGZ8FzE > E%2FQEsPBI > > lIsxlyZ9lVwjAko50%3D&reserved=0 (side by > > side) > > > > Diff of the XML: > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc-editor.org%2Fauthors%2Frfc9861- > xmldiff1.html&data=05%7C02%7Cquynh. > > > dang%40nist.gov%7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd > 8fa4797a > > > 93e054655c61dec%7C0%7C0%7C638942163357634561%7CUnknown%7C > TWFpbGZsb3d8e > > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > oiTWF > > > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GqPhQBL%2B98cGqHh > WCdlKQmOdd1m > > 3zWbgAw%2Fb305ryCY%3D&reserved=0 > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc- > editor.org%2Fauth48%2Frfc9861&data=05%7C02%7Cquynh.dang%40nist.g > ov > > > %7Cc76afae48ab24b7b1d1308ddfa831bd8%7C2ab5d82fd8fa4797a93e054 > 655c61dec > > > %7C0%7C0%7C638942163357646905%7CUnknown%7CTWFpbGZsb3d8ey > JFbXB0eU1hcGki > > > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo > yfQ > > > %3D%3D%7C0%7C%7C%7C&sdata=MeqXVj4OClqKQn4CtHxgn00mu%2FLsS > GnFi3UFPq8g1R > > o%3D&reserved=0 > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC9861 (draft-irtf-cfrg-kangarootwelve-17) > > > > Title : KangarooTwelve and TurboSHAKE > > Author(s) : B. Viguier, D. Wong, Ed., G. Assche, Ed., Q. Dang, Ed., > > J. > Daemen, Ed. > > WG Chair(s) : > > Area Director(s) : > > > > > > -- > > auth48archive mailing list -- [email protected] To > > unsubscribe send an email to [email protected] > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
