Hi Megan, I also reviewed and approve the document.
Cheers, Aron -- Aron Wussler Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930 On Friday, 29 May 2026 at 23:11, Megan Ferguson <[email protected]> wrote: > Stavros, Johannes, and Falko, > > Thank you for your replies. > > We have updated as suggested by Falko (thank you for spotting that!) and > reposted the files. > > We have also recorded your approvals of the document in its current form. We > will assume your approval stands even if a coauthor submits further changes > unless we hear objection at that time. Once we have approval from Aron and AD > approval, this document should be ready to move forward in the publication > process. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9980.txt > https://www.rfc-editor.org/authors/rfc9980.pdf > https://www.rfc-editor.org/authors/rfc9980.html > https://www.rfc-editor.org/authors/rfc9980.xml > > The diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9980-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9980-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9980-auth48diff.html (Final Review > changes only) > https://www.rfc-editor.org/authors/rfc9980-auth48rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9980-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9980-lastrfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9980-alt-diff.html (to see IANA > table/list changes) > https://www.rfc-editor.org/authors/rfc9980-alt-rfcdiff.html (side by side) > > The Final Review status page for this document is viewable here: > https://www.rfc-editor.org/auth48/rfc9980 > > Thank you. > > Megan Ferguson > RFC Production Center > > > On May 29, 2026, at 1:28 AM, Stavros Kousidis <[email protected]> > > wrote: > > > > Hi Megan, > > > > Looks good for me, too. > > > > Thank you all > > Stavros > > > > > > Am 29. Mai 2026 07:50:59 MESZ schrieb Johannes Roth <[email protected]>: > > Hi Megan, > > > > Thanks for the quick action. I reviewed the document and it looks good to > > me (aside from the comma issue that Falko mentioned). > > > > Best, > > Johannes > > > > On 27.05.2026 18:59, Megan Ferguson wrote: > > Hi Aron and *AD, > > > > [*AD - please respond regarding question #8 and review/approve the author’s > > suggested text to resolve question #12]. > > > > Thanks for the reply and guidance. We have updated as requested. > > > > Note that we made the further change of removing “of RFC 9980” from the > > Reference column of the IANA Considerations table (now list). This matches > > the method of referencing most commonly seen in recently published RFCs; > > please let us know any objections. Note that these changes are best viewed > > in the “alt diff” files below. > > > > Please review the files carefully as we do not make changes once the > > document is published as an RFC. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9980.txt > > https://www.rfc-editor.org/authors/rfc9980.pdf > > https://www.rfc-editor.org/authors/rfc9980.html > > https://www.rfc-editor.org/authors/rfc9980.xml > > > > The diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9980-diff.html (comprehensive) > > https://www.rfc-editor.org/authors/rfc9980-rfcdiff.html (side by side) > > > > https://www.rfc-editor.org/authors/rfc9980-auth48diff.html (Final Review > > changes only) > > https://www.rfc-editor.org/authors/rfc9980-auth48rfcdiff.html (side by side) > > > > https://www.rfc-editor.org/authors/rfc9980-alt-diff.html (to see IANA > > table/list changes) > > https://www.rfc-editor.org/authors/rfc9980-alt-rfcdiff.html (side by side) > > > > The Final Review status page for this document is viewable here: > > https://www.rfc-editor.org/auth48/rfc9980 > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > On May 27, 2026, at 5:11 AM, Aron Wussler <[email protected]> wrote: > > > > Hi Megan, > > > > thanks for the thorough editing. We provide our answers and our suggested > > changes in the following. > > > > 1) We suggest the following key words: pgp, pqc, encryption, digital > > signature, post-quantum > > > > 2) We agreed to the following change: > > > > Section 1 > > > > OLD: > > Namely, these are ML-KEM [FIPS-203] as a Key Encapsulation Mechanism > > (KEM), a KEM being a modern building block for public key encryption, > > and ML-DSA [FIPS-204] as well as SLH-DSA [FIPS-205] as signature > > schemes. > > > > NEW: > > ML-KEM [FIPS-203] was selected as a Key Encapsulation Mechanism (KEM). > > A KEM is a modern building block for public key encryption. > > ML-DSA [FIPS-204] and SLH-DSA [FIPS-205] were selected as signature schemes. > > > > 3) We would like to leave these sentences in their current places. They > > clarify technical details of the algorithm choices, and thus do not belong > > into the terminology section. > > > > 4) We agreed to the following change: > > > > Section 4.3.1 > > > > OLD: > > Note that like in the case of the algorithms X25519 and X448 > > specified in [RFC9580], for the ML-KEM composite schemes, in the case > > of a v3 PKESK packet, the symmetric algorithm identifier is not > > encrypted. > > > > NEW: > > Note that for the ML-KEM composite schemes, in the case of a v3 PKESK > > packet, the symmetric algorithm identifier is not encrypted. > > This follows the construction of X25519 and X448 specified in [RFC9580]. > > > > 5a) We agree to the proposed change to use a definitions list. > > > > 5b) Indeed, the entries for ID 30 and ID 31 should be references to Section > > 5. The reference for ID 35 and 36 should be to Section 4. > > > > 6) We agree to the proposed change. > > > > 7) We agree to the proposed change. > > > > 8) We defer to the AD for this item. > > > > 9) We do not mind wrapping here. Feel free to change the tag or manually > > add a newline to resolve this. > > > > 10a) The abbreviation extensions seem fine to us. > > > > 10b) That is correct, you may update the document to use "Module Learning > > with Errors" as expansion for "MLWE". > > > > 10c) No objections. > > > > 10d) We prefer to remove "(PK)" and "(SK)" from Table 8 in Section 6.1. > > > > 11a) We prefer to use "sentence case" for the term, that is, capitalize the > > first word only in titles and beginning of sentences. As far as we can see, > > the only inconsistent spelling is in Section 2.1 in the parenthesis > > "(Algorithm IDs 31 and 36)". We prefer this to be adjusted to sentence case. > > > > Section 2.1 > > > > OLD: > > (Algorithm IDs 31 and 36) > > > > NEW: > > (algorithm IDs 31 and 36) > > > > 11b) The list looks fine to us. > > > > 12) We did not find any issues regarding inclusive language. The word > > 'traditional' is used in line with the definition of 'traditional > > cryptographic algorithms' in RFC 9794. For clarity, we suggest to add this > > term in Section 1.1.1. We propose the following change. We also believe > > there should be a comma before the "and", please feel free to remove it if > > that is wrong. > > > > Section 1.1.1 > > > > OLD: > > Specifically, the terms "multi-algorithm", "composite" and "non-composite" > > are used in correspondence with the definitions therein. > > > > NEW: > > Specifically, the terms "multi-algorithm", "composite", "non-composite", > > and "traditional" are used in correspondence with the definitions therein. > > > > > > Kind regards, > > Aron, on behalf of all authors > > > > > > -- > > Aron Wussler > > Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930 > > > > > > On Wednesday, 20 May 2026 at 15:43, Megan Ferguson > > <[email protected]> wrote: > > > > Hi Aron, > > > > Thanks for the heads up! We appreciate your collaboration so our mail > > exchange is easier to follow. > > > > We’ll look for your reply once you get things ironed out. > > > > Megan Ferguson > > RFC Production Center > > > > On May 20, 2026, at 2:20 AM, Aron Wussler <[email protected]> wrote: > > > > Hi Megan, > > > > We're already drafting internally an answer which we all agree to - sorry > > if this is taking longer than expected. > > > > Cheers, > > Aron > > > > -- > > Aron Wussler > > Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930 > > > > > > On Tuesday, 19 May 2026 at 19:36, Megan Ferguson > > <[email protected]> wrote: > > > > Authors and *AD, > > > > [*AD - please see question 8 in our mail below] > > > > Just a reminder that this document awaits your attention. > > > > Please review both emails sent thus far (AUT48 instructions as well as > > document-specific questions) and let us know how to proceed on any issues > > as well as any changes you might like to request upon completion of your > > review of the document. > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > On May 8, 2026, at 2:50 PM, [email protected] wrote: > > > > All, > > > > *AD - please review question #8 below. Please note also that we assume AD > > approval of the change between versions -16 and -17 as it was submitted by > > Paul. > > > > Authors - While reviewing this document during AUTH48, please resolve (as > > necessary) the following questions, which are also in the source file. > > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > 2) <!--[rfced] This sentence is difficult to parse please rephrase (and > > perhaps consider breaking up into multiple sentences). > > > > Original: > > Namely, these are ML-KEM [FIPS-203] as a Key Encapsulation Mechanism > > (KEM), a KEM being a modern building block for public key encryption, > > and ML-DSA [FIPS-204] as well as SLH-DSA [FIPS-205] as signature > > schemes. > > > > --> > > > > > > 3) <!--[rfced] Would it make sense to include the following sentences > > from the subsections of 5.1 and Section 6 in the Terminology > > section? > > > > Original: > > Throughout this specification EdDSA refers to the PureEdDSA variant > > defined in [RFC8032]. > > > > Original: > > Throughout this specification ML-DSA refers to the default pure and > > hedged version of ML-DSA defined in [FIPS-204]. > > > > Original: > > Throughout this specification SLH-DSA refers to the default pure and > > hedged version of SLH-DSA defined in [FIPS-205]. > > > > --> > > > > > > 4) <!--[rfced] How may we rephrase to avoid the stacked "in the case"? > > Perhaps breaking this sentence up would be helpful? > > > > Original: > > Note that like in the case of the algorithms X25519 and X448 > > specified in [RFC9580], for the ML-KEM composite schemes, in the case > > of a v3 PKESK packet, the symmetric algorithm identifier is not > > encrypted. > > --> > > > > > > 5) <!--[rfced] We had the following questions related to the table in the > > IANA Considerations section: > > > > a) The table of IANA values is very difficult to read and, now that > > some edits have been made to the text, exceed our 72-character line > > length limit. > > > > We suggest updating to a definitions list for readability. This > > update would appear as seen here: > > > > https://www.rfc-editor.org/authors/rfc9980alt.txt > > > > b) We see links to specific tables in the various "Format" columns. > > Please review as ID 30 (for example) mentions Tables 6 and 7 (which > > are in Sections 5.1.1 and 5.1.2, respectively), while the Reference > > column is pointing to Section 5.2. If this is not as expected, please > > review each entry and let us know if/how to update. > > > > c) Please note that we will communicate any updates we've made to the > > text in the IANA table to IANA for corresponding updates at > > https://www.iana.org/assignments/openpgp/openpgp.xhtml#openpgp-public-key-algorithms > > once AUTH48 completes (and the text is stable). > > > > > > --> > > > > > > 6) <!-- [rfced] [NIST-PQC] Please review. The date provided for this > > reference does not match any of the dates provided at this > > reference's URL. At the bottom of the page the dates listed are > > "Created January 03, 2017, Updated December 11, 2025". > > > > Also, the authors used in this reference entry are not listed on this > > page (with the exception of Dustin Moody who is listed in the > > "Contacts" section). > > > > Is there another page this reference was meant to point to? > > > > If this is the correct URL we recommend the following update: > > > > > > Current: > > [NIST-PQC] Chen, L., Moody, D., and Y. Liu, "Post-Quantum Cryptography > > Standardization", December 2016, > > <https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization>. > > > > Perhaps: > > [NIST-PQC] NIST, "Post-Quantum Cryptography Standardization", December 2025, > > <https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization>. > > > > --> > > > > > > 7) <!-- [rfced] [NISTIR-8413] FYI: We've updated the date for this > > reference from September 2022 to July 2022. Note that the version from > > September was withdrawn and replaced by an updated version in July > > 2022: https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf. We > > also updated the series number from "NIST IR 8413" to "NIST IR > > 8413-upd1". --> > > > > > > 8) <!--[rfced] [AD] The authors submitted a query about possible downrefs > > suggested by IDNITs (see list below). This is not generally something the > > RPC advises on. Upon conference between AD and authors, please let us know > > if any updates/changes are necessary. > > > > Checking references for intended status: Proposed Standard > > > > (See RFCs 3967 and 4897 for information about using normative references > > to lower-maturity documents in RFCs) > > > > - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-203' > > > > - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-204' > > > > - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-205' > > > > - Possible downref: Non-RFC (?) normative reference: ref. 'IANA-OPENPGP' > > > > ** Downref: Normative reference to an Informational RFC: RFC 3394 > > > > ** Downref: Normative reference to an Informational RFC: RFC 7748 > > > > ** Downref: Normative reference to an Informational RFC: RFC 8032 > > > > From the authors: "We listed those references as normative as they > > contain the algorithmic specifications needed. > > > > We would appreciate guidance from the RFC Editor Team if this should > > be handled differently." > > > > --> > > > > > > 9) <!--[rfced] Please have a look at the line wrap issue in Appendix A.4.3. > > Now that the text is in <tt> to format it as fixed width, it seems not to > > be able to wrap to fit within the 72-character limit.--> > > > > > > 10) <!--[rfced] We had the following questions/comments related to > > abbreviation use throughout the document: > > > > a) We have expanded abbreviations on first use. Please review these > > expansions for accuracy. > > > > b) The document expands MLWE as "Learning with Errors problem in > > module lattices (MLWE)". We believe the abbreviation stands for > > "Module Learning with Errors". Please let us know if/how to update. > > > > c) We have updated the expansion of SEIPD to match RFC 9580. Please > > let us know any objections. > > > > Original: > > Symmetrically Encrypted and Integrity Protected Data > > > > Current: > > Symmetrically Encrypted Integrity Protected Data > > > > d) We see PK and SK are introduced in Section 6.1, but are not used > > elsewhere in the text. Would you like to introduce them sooner and > > use them throughout? Or perhaps remove them from Section 6.1? > > --> > > > > > > 11) <!--[rfced] We had the following questions/comments about terminology > > use throughout the document: > > > > a) We see both algorithm ID and Algorithm ID. Please let us know if/how > > these should be made uniform. > > > > b) Please review the list of terms that appear in <tt> (for special > > marking) for consistency and let us know if any updates are necessary. > > You can find the list at: > > > > https://www.rfc-editor.org/authors/draft-ietf-openpgp-pqc-17ttsorted.txt > > > > --> > > > > > > 12) <!-- [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. > > > > In addition, please consider whether "traditional" should be updated for > > clarity. > > While the NIST website > > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > > indicates that this term is potentially biased, it is also ambiguous. > > "Tradition" is a subjective term, as it is not the same for everyone. > > > > --> > > > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > > > *****IMPORTANT***** > > > > Updated 2026/05/08 > > > > 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://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 reviewPlease 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://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://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 changesTo 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > * The archive itself: > > 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 publicationTo 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. > > > > > > FilesThe files are available here: > > https://www.rfc-editor.org/authors/rfc9980.xml > > https://www.rfc-editor.org/authors/rfc9980.html > > https://www.rfc-editor.org/authors/rfc9980.pdf > > https://www.rfc-editor.org/authors/rfc9980.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9980-diff.html > > https://www.rfc-editor.org/authors/rfc9980-rfcdiff.html (side by side) > > > > Diff of the XML: > > https://www.rfc-editor.org/authors/rfc9980-xmldiff1.html > > > > > > Tracking progressThe details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9980 > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC EditorRFC9980 (draft-ietf-openpgp-pqc-17) > > > > Title : Post-Quantum Cryptography in OpenPGP > > Author(s) : S. Kousidis, J. Roth, F. Strenzke, A. Wussler > > WG Chair(s) : Stephen Farrell, Daniel Kahn Gillmor > > > > Area Director(s) : Deb Cooley, Christopher Inacio > > > > > > > > > > > > > > > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
