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]
