Amanda, Thanks for the updates.
We will move this document forward in the publication process at this time. Megan Ferguson RFC Production Center > On Jun 25, 2026, at 6:40 PM, Amanda Baber via RT <[email protected]> wrote: > > Hi, > > These changes are complete: > > https://www.iana.org/assignments/openpgp > > thanks, > Amanda > > On Tue Jun 23 18:44:09 2026, [email protected] wrote: >> IANA, >> >> There are a number of changes to the “OpenPGP Public Key Algorithms” >> registry (at https://www.iana.org/assignments/openpgp/openpgp.xhtml) >> necessary to exactly match the document. >> >> 1) The large majority of these changes involve hyphenation of octets >> in attributive position (e.g., 32-octet Ed25519 public key instead of >> 32 octets Ed25519 public key). Nearly every column will be affected. >> >> 2) The section number mentions are somewhat different (e.g., the >> document will point to Section 5 while the IANA registry has Section >> 5.2). Please make these consistent with the document as well. >> >> The plaintext version of the document is available here: >> https://www.rfc-editor.org/authors/rfc9980.txt >> >> Because there was such significant formatting variation both within >> the versions of the document and as compared to the IANA registry, our >> usual diff is nearly unreadable. So, here is a Claude-generated diff >> highlighting the changes requested in 1 and 2 above: >> https://www.rfc-editor.org/authors/rfc9980IANAdiff.html >> >> Please let us know once the registry has been updated as all other >> approvals have been received and the document will be ready to move >> forward in the publication process. >> >> Thank you. >> >> Megan Ferguson >> RFC Production Center >> >>> On Jun 17, 2026, at 9:32 AM, Madison Church <[email protected] >>> editor.org> wrote: >>> >>> Hi Paul, Authors, >>> >>> (Taking over for Megan temporarily as she is offline for the rest of >>> this week.) >>> >>> Paul - Thank you for your response! We have noted your approval here: >>> https://queue.rfc-editor.org/final-review/rfc9980/. >>> >>> Authors - As all of our queries have been resolved, we will begin >>> preparing this document for publication. >>> >>> Thank you for your time! >>> >>> Best, >>> Madison Church >>> RFC Production Center >>> >>>> On Jun 16, 2026, at 8:52 AM, Paul Wouters >>>> <[email protected]> wrote: >>>> >>>> >>>> On Mon, Jun 15, 2026 at 11:07 PM Megan Ferguson >>>> <[email protected]> wrote: >>>> ADs, >>>> >>>> Just in case this is pending me as the then-AD at the time, >>>> >>>> >>>> Just a friendly reminder that this document is ready to go once we >>>> hear back from the AD on the following: >>>> >>>>> On Jun 1, 2026, at 9:12 AM, Megan Ferguson <[email protected] >>>>> editor.org> wrote: >>>>> >>>>> Now we believe we just need AD input to wrap things up. >>>>> >>>>> *AD - Please weigh in on question 8 and the authors’ updates to >>>>> resolve question 12 (copied below for convenience): >>>>> >>>>>>>> 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." >>>> >>>> The downrefs are fine. >>>>>>>> >>>>>>>> —> >>>>> >>>>> From Falko: >>>>>> as I understand question 8, we still need to address the "downref" >>>>>> problems: >>>>>> - normative references to the FIPS specs: Can these simply be >>>>>> kept? >>>>>> - normative reference to IANA registry: What is the right way >>>>>> here? >>>>>> - normative references to "Informational" RFCs: It seems to me >>>>>> those need some kind of annotation if we want to keep them as >>>>>> normative references. But I don't understand the procedure. Can >>>>>> you point out the possible options here? >>>> >>>> No need for any changes. >>>>> >>>>> >>>>> And for question 12 (inclusive language): >>>>>> 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. >>>> >>>> That looks fine to me. >>>>> Once we hear back some AD guidance on the above, we believe the >>>>> document will be ready to move forward in the publication process. >>>> >>>> No issues with the proposed Section 1.1.1 change and no issues with >>>> the downrefs. Looks good to go. >>>> >>>> >>>> Paul >>>> >>>>> >>>>> 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 30, 2026, at 2:25 PM, Aron Wussler <[email protected]> wrote: >>>>>> >>>>>> 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]
