The changes look good to me Paul previous SEC-AD
On Tue, May 19, 2026 at 1:36 PM 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 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://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 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://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 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://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 progress > > ----------------- > > > > The 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 Editor > > > > -------------------------------------- > > RFC9980 (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]
