Hello Authors, We have merged the updates and converted the kramdown-rfc file to RFCXML. Thank you both for submitting PRs and comments throughout the process, it was super helpful on our end!
Please review the XML file and its TXT, HTML, and PDF outputs, and let us know if any changes are required or if you approve the RFC for publication. We consider this your final assent that the document is ready for publication. To request changes or approve your RFC for publication, please reply to this email. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Note that we will only make changes in the XML file from this point on. XML file: https://www.rfc-editor.org/authors/rfc10032.xml Output files: https://www.rfc-editor.org/authors/rfc10032.txt https://www.rfc-editor.org/authors/rfc10032.pdf https://www.rfc-editor.org/authors/rfc10032.html Comprehensive diff file of the text: https://www.rfc-editor.org/authors/rfc10032-diff.html https://www.rfc-editor.org/authors/rfc10032-rfcdiff.html (side by side) For the Final Review status of this document, please see: https://queue.rfc-editor.org/final-review/rfc10032 Thank you! Madison Church RFC Production Center > On Aug 14, 2026, at 3:31 PM, [email protected] wrote: > > Authors, > > While reviewing this document during Final Review, please reply to the issues > in the GitHub repository > (https://github.com/rfc-editor-drafts/FinalReview-rfc10032/issues), which are > listed below for backup. > > > 1) <!-- [rfced] We have shortened the abbreviated title for this document as > shown below. Please review and let us know if you prefer something > different. Note that the abbreviated title only appears on the running header > at the top of each page in the PDF output. > > Original: > The AEGIS Family of Authenticated Encryption Algorithms > > Updated: > AEGIS Authenticated Encryption Algorithms > --> > > > 2) <!-- [rfced] The document title, abstract, and introduction use slightly > different language in referring to the algorithms. For example, the abstract > uses "AES-based authenticated encryption algorithms", and the introduction > uses "Authenticated Encryption with Associated Data (AEAD) algorithms". Please > review and let us know if any updates are needed. > > Document title: > The AEGIS Family of Authenticated Encryption Algorithms > > Abstract: > This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and > AEGIS-256X AES-based authenticated encryption algorithms designed for > high-performance applications. > > Introduction: > This document describes the AEGIS family of Authenticated Encryption > with Associated Data (AEAD) algorithms [AEGIS], which were chosen for ... > --> > > > 3) <!-- [rfced] The [FIPS-AES] reference entry points to a "Withdrawn NIST > Technical Series Publication". NIST FIPS 197 was withdrawn in May 2023 and > updated by NIST FIPS 197-upd1. > > The withdrawal notice includes the following note: > > This update makes no technical changes to the algorithm specified in the > original (2001) release of this standard. This update includes extensive > editorial > improvements to the original version. > > We have updated this reference to point to the most current version of > NIST FIPS 197. Please let us know if you have any objections. > > Original: > [FIPS-AES] NIST, "Advanced encryption standard (AES)", NIST Federal > Information Processing Standards Publications 197, > DOI 10.6028/NIST.FIPS.197, November 2001, > <https://nvlpubs.nist.gov/nistpubs/FIPS/ > NIST.FIPS.197.pdf>. > > Updated: > [FIPS-AES] NIST, "Advanced Encryption Standard (AES)", NIST FIPS 197, > DOI 10.6028/NIST.FIPS.197-upd1, May 2023, > <https://doi.org/10.6028/NIST.FIPS.197-upd1>. > --> > > > 4) <!-- [rfced] Please insert any keywords (beyond those that appear in the > title) for use on https://www.rfc-editor.org/search. --> > > > 5) <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC > 5743 have been adhered to in this document. --> > > > 6) <!-- [rfced] Regarding sourcecode, the response on the intake form > specifies that the document includes two types: "pseudocode" for algorithm > descriptions and "test-vectors" for sourcecode in the appendix. > > We have updated to use "test-vectors" in the appendix, but we would like to > clarify your intent for using "pseudocode" for algorithm descriptions. Should > "pseudocode" be applied to each block prefaced with "Steps:" in Sections 3-8? > Should each function (e.g., 'Encrypt(msg, ad, key, nonce)' in Section 3.1) > also be marked as "pseudocode"? > > Note that the blocks in Sections 5.4.7 and 8.3.2 contains lines that are too > long for the TXT output (the line limit for sourcecode in the TXT output is 69 > characters). When we convert the kramdown-rfc file to RFCXML, we will ask > about how to break these long lines to fit the line limit. > --> > > > 7) <!-- [rfced] How may we update "whose meaning is defined in" for clarity? > Note that this text appears twice in the document. > > Original: > The parameters for this algorithm, whose meaning is defined in > [RFC5116], Section 4, are: > > Perhaps (uses "are" - parameters are defined): > The parameters for this algorithm, which are defined in > Section 4 of [RFC5116], are: > > Or (uses "is" - algorithm is defined): > The parameters for this algorithm, which is defined in > Section 4 of [RFC5116], are: > --> > > > 8) <!-- [rfced] How should we expand "VAES"? > > Original: > Some CPUs, such as Intel and Intel-compatible CPUs with > the VAES extensions, include instructions to efficiently > apply the AES round function to a vector of AES blocks. > --> > > > 9) <!-- [rfced] FYI - We updated "each of them updating" to "each of which > updates". Let us know any concerns. > > Original: > M0 and M1 are 128 > * D bits instead of 128 bits, but are split into 128-bit blocks, each > of them updating a different AEGIS-128L state. > ... > M is 128 * D bits > instead of 128 bits and is split into 128-bit blocks, each of them > updating a different AEGIS-256 state. > > Updated: > M0 and M1 are 128 > * D bits instead of 128 bits, but they are split into 128-bit blocks, each > of which updates a different AEGIS-128L state. > ... > M is 128 * D bits > instead of 128 bits and is split into 128-bit blocks, each of which > updates a different AEGIS-256 state. > --> > > > 10) <!-- [rfced] Is a citation needed for "NIST guidelines"? If so, please > provide the appropriate reference. > > Original: > With AEGIS-128L and AEGIS-128X, random nonces can safely encrypt up > to 2^48 messages using the same key with negligible (~2^-33, to align > with NIST guidelines) collision probability. > --> > > > 11) <!-- [rfced] Will readers know what is meant by "the original > specification" here? Is a citation needed? > > Original: > This document extends the original specification by introducing > optional support for 256-bit authentication tags, which are > constructed similarly to the 128-bit tags. > --> > > > 12) <!-- [rfced] IANA Considerations > > a) FYI - We made the following changes to the table in the IANA Considerations > section: > > - switched the order of the columns to match the order in registry > - updated the column headers to match those in the registry > > Link to registry: > https://www.iana.org/assignments/aead-parameters#aead-parameters-2 > > > b) The algorithm names listed in Table 2 in the IANA Considerations section do > not align with the names used throughout the document. In the pairs of > examples below, we see the first name in Table 2 and the second elsewhere in > the document. Please review and let us know if any updates are needed > (document and IANA registry). > > AEAD_AEGIS128L > AEGIS-128L > > AEAD_AEGIS256 > AEGIS-256 > > AEAD_AEGIS128X2 > AEGIS-128X2 > > AEAD_AEGIS128X4 > AEGIS-128X4 > > AEAD_AEGIS256X2 > AEGIS-256X2 > > AEAD_AEGIS256X4 > AEGIS-256X4 > > > In addition, the following appear in the document but not in Table 2. If any > updates are needed for the above, these may also need to be updated. > > AEGIS-128X > AEGIS-256X > AEGISMAC-128L > AEGISMAC-256 > AEGISMAC-128X > AEGISMAC-256X > --> > > > 13) <!-- [rfced] We note that the following term is used inconsistently in the > document. Please let us know which form you prefer or if this should be left > as is. > > Mac function > MAC function (1 instance) > --> > > > 14) <!-- [rfced] 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. > > key derivation function (KDF) > HMAC-based key derivation function (HKDF) > --> > > > 15) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> > > > Thank you. > > Madison Church and Rebecca VanRheenen > RFC Production Center > > > > On Aug 14, 2026, at 1:30 PM, [email protected] wrote: > > *****IMPORTANT***** > > RFC Author(s): > -------------- > > Your document has now entered Final Review (previously AUTH48). > > The document was edited in kramdown-rfc as part of the RPC pilot test (see > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). > > Final Review is being handled in GitHub as part of the GitHub pilot test > (see > https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). > > Your document is available for review at: > https://github.com/rfc-editor-drafts/FinalReview-rfc10032 > > Please do the following: > > a) accept your invitations to join the repo as collaborators. Note that we > sent > invitations to both authors. We can also send an invitation to the document > shepherd (Stanislav Smyshlyaev) if provided with a GitHub username. > > b) see the README for details on the Final Review process: > https://github.com/rfc-editor-drafts/FinalReview-rfc10032/blob/Approved/README.md > > c) review the edits in the RPC-edits pull request: > https://github.com/rfc-editor-drafts/FinalReview-rfc10032/pulls > > d) address the issues: > https://github.com/rfc-editor-drafts/FinalReview-rfc10032/issues > > Once the content of the .md file is stable, we will convert it to .xml > and provide the .html, .pdf, .txt, and .xml files for review. > > You and your coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Once the document has been reviewed and approved by all of the authors, > it will be published as an RFC. If an author is no longer available, > there are several remedies; see the Unavailable Authors section > (https://authors.ietf.org/rfc-publication-process#unavailable-authors). > > Details on the status of your Final Review are here: > https://queue.rfc-editor.org/final-review/rfc10032/ > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Production Center > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
