Dear IANA, Per the author, please make the following updates on <https://www.iana.org/assignments/jose/>: OLD: Ed25519 EdDSA using Ed25519 curve Ed448 EdDSA using Ed448 curve NEW: Ed25519 EdDSA using the Ed25519 parameter set in Section 5.1 of [RFC8032] Ed448 EdDSA using the Ed448 parameter set in Section 5.2 of [RFC8032] =============================== Per the author (with apologies for anything that's misordered here as compared to the IANA page; we found the process of listing these updates very challenging), please make the following updates on <https://www.iana.org/assignments/cose/>: OLD: Reference [RFC9053][RFC9054][RFC-ietf-jose-fully-specified-algorithms-13, Section 4.3.1] NEW: Reference [RFC9053][RFC9054][RFC-ietf-jose-fully-specified-algorithms-13, Section 4.2] = = = = = OLD: ESB512 -268 ... [RFC-ietf-jose-fully-specified-algorithms-13] ESB384 -267 ... [RFC-ietf-jose-fully-specified-algorithms-13] ESB320 -266 ... [RFC-ietf-jose-fully-specified-algorithms-13] ESB256 -265 ... [RFC-ietf-jose-fully-specified-algorithms-13] Ed448 -53 ... [RFC-ietf-jose-fully-specified-algorithms-13] ESP512 -52 ... [RFC-ietf-jose-fully-specified-algorithms-13] ESP384 -51 ... [RFC-ietf-jose-fully-specified-algorithms-13] Ed25519 -19 ... [RFC-ietf-jose-fully-specified-algorithms-13] ESP256 -9 ... [RFC-ietf-jose-fully-specified-algorithms-13] NEW: ESB512 -268 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.1 ESB384 -267 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.1 ESB320 -266 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.1 ESB256 -265 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.1 Ed448 -53 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.2 ESP512 -52 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.1 ESP384 -51 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.1 Ed25519 -19 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.2 ESP256 -9 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section 2.1 = = = = = OLD: Ed448 -53 EdDSA using Ed448 curve Ed25519 -19 EdDSA using Ed25519 curve NEW: Ed448 -53 EdDSA using the Ed448 parameter set in Section 5.2 of [RFC8032] Ed25519 -19 EdDSA using the Ed25519 parameter set in Section 5.1 of [RFC8032] = = = = = Please also add "IETF" in the "Change Controller" column for the ES512 entry: OLD: ES512 -36 ... [kty] [RFC9053][RFC-ietf-jose-fully-specified-algorithms-13] NEW: ES512 -36 ... [kty] IETF [RFC9053][RFC-ietf-jose-fully-specified-algorithms-13]
Thank you! Lynne Bartholomew RFC Production Center > On Oct 23, 2025, at 9:10 AM, Lynne Bartholomew > <[email protected]> wrote: > > Hi, Deb. Thank you for the quick reply! So noted: > > https://www.rfc-editor.org/auth48/rfc9864 > > We will send the IANA email shortly. > > Thanks again! > > Lynne Bartholomew > RFC Production Center > >> On Oct 23, 2025, at 9:04 AM, Deb Cooley <[email protected]> wrote: >> >> I approve. >> >> Deb >> >> On Thu, Oct 23, 2025 at 11:40 AM Lynne Bartholomew >> <[email protected]> wrote: >> Hi, Mike and *Deb. >> >> Mike, thank you for the updated XML file! >> >> * Deb, please let us know if you approve the change from "must" to "MUST" in >> Section 3, Paragraph 6. >> >> Mike, after we receive AD approval, we will ask IANA to make the necessary >> updates. After the IANA updates are complete, we will prepare this document >> for publication. >> >> In the meantime, we have noted your approval on the AUTH48 status page: >> >> https://www.rfc-editor.org/auth48/rfc9864 >> >> The latest files are posted here. Please refresh your browser: >> >> https://www.rfc-editor.org/authors/rfc9864.txt >> https://www.rfc-editor.org/authors/rfc9864.pdf >> https://www.rfc-editor.org/authors/rfc9864.html >> https://www.rfc-editor.org/authors/rfc9864.xml >> https://www.rfc-editor.org/authors/rfc9864-diff.html >> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html (side by >> side) >> https://www.rfc-editor.org/authors/rfc9864-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9864-lastrfcdiff.html (side by side) >> >> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html >> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html >> >> Thanks again! >> >> Lynne Bartholomew >> RFC Production Center >> >> >>> On Oct 22, 2025, at 5:13 PM, Michael Jones <[email protected]> >>> wrote: >>> >>> The attached source contains three requested changes relative to the latest >>> version. They are: >>> >>> diff "rfc9864.xml~" rfc9864.xml >>> 86c86 >>> < Examples are the <tt>Edwards-curve Digital Signature Algorithm >>> (EdDSA)</tt> >>> --- >>>> Examples are the Edwards-curve Digital Signature Algorithm (EdDSA) >>> 238c238 >>> < The following fully-specified JOSE and COSE <tt>EdDSA</tt> >>> algorithms are defined by this specification: >>> --- >>>> The following fully-specified JOSE and COSE EdDSA algorithms are >>>> defined by this specification: >>> 323c323 >>> < the inner "alg" value must specify all parameters for symmetric >>> encryption. >>> --- >>>> the inner "alg" value <bcp14>MUST</bcp14> specify all parameters for >>>> symmetric encryption. >>> >>> For the first two changes, EdDSA should only be in <tt>...</tt> when it is >>> an algorithm identifier - not when it is a designator for the Edwards-curve >>> Digital Signature Algorithm (EdDSA) signature method. >>> >>> For the third change, it makes the spec consistent in its use of MUST >>> within that sentence. >>> >>> I have reviewed all other changes and agree with them, including all the >>> hyphenation decisions. Once my three changes above are incorporated, >>> please mark the document approval status for me as Yes at >>> https://www.rfc-editor.org/auth48/rfc9864. >>> >>> Are the next steps to update the IANA registration text that was changed? >>> >>> Thanks all, >>> -- Mike >>> >>> >>> -----Original Message----- >>> From: Lynne Bartholomew <[email protected]> >>> Sent: Wednesday, October 22, 2025 8:26 AM >>> To: Deb Cooley <[email protected]> >>> Cc: Orie <[email protected]>; [email protected]; Michael Jones >>> <[email protected]>; [email protected]; >>> [email protected]; [email protected]; [email protected] >>> Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9864 >>> <draft-ietf-jose-fully-specified-algorithms-13> for your review >>> >>> Hi, Deb. Thanks for the quick reply! We have noted your approval: >>> >>> https://www.rfc-editor.org/auth48/rfc9864 >>> >>> Regarding your note about hyphenation: We sent the follow-up question >>> below to Mike on 6 Oct. We're still waiting for his reply (forgot to ping >>> him in yesterday's 11:55 AM email). >>> >>>>>>>>> 2) <!-- [rfced] Section 2.1: Because it appears that "full-specified" >>>>>>>>> means "fully specified", we updated this text accordingly. If this >>>>>>>>> is incorrect, please let us know what "full-specified" means >>>>>>>>> (possibly "specified in full"?). >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are >>>>>>>>> full-specified.) >>>>>>>>> >>>>>>>>> Currently: >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are fully >>>>>>>>> specified.) --> >>>>>>>>> >>>>>>>> Mike> This has already been addressed by returning to using >>>>>>>> "fully-specified", etc. >>>>>>> >>>>>>> We only hyphenated where "fully specified" is used as a modifier. For >>>>>>> example, the text still shows "are fully specified. ...". There are >>>>>>> currently 12 instances of "fully specified" (no hyphen). Should we >>>>>>> hyphenate all of these as well? >>> >>> Thanks again! >>> >>> Lynne Bartholomew >>> RFC Production Center >>> >>>> On Oct 21, 2025, at 3:15 PM, Deb Cooley <[email protected]> wrote: >>>> >>>> The tables are fine. I approve. >>>> >>>> What I did notice is that there is a mix of 'fully specified' and >>>> 'fully-specified' throughout the draft. If that is 'by design', then I'm >>>> fine with it. If it is not by design, then I suggest that we pick one and >>>> stick with it. >>>> >>>> Deb >>>> >>>> On Tue, Oct 21, 2025 at 11:55 AM Lynne Bartholomew >>>> <[email protected]> wrote: >>>> Hi, Orie and *AD (Deb or Paul). >>>> >>>> * Deb or Paul, please review the updates to Table 2, Section 4.1.1, and >>>> Section 4.2.1, and let us know if you approve. (We're not sure if these >>>> updates could be considered "beyond editorial".) >>>> >>>> Orie, as it appears that you approve this document for publication in its >>>> current form, we have noted your approval on the AUTH48 status page. >>>> Please let us know if we noted your approval in error: >>>> >>>> https://www.rfc-editor.org/auth48/rfc9864 >>>> >>>> Thank you! >>>> >>>> Lynne Bartholomew >>>> RFC Production Center >>>> >>>>> On Oct 20, 2025, at 1:39 PM, Orie <[email protected]> wrote: >>>>> >>>>> I reviewed the diffs. These look good to me. >>>>> >>>>> Regards, >>>>> >>>>> OS >>>>> >>>>> On Mon, Oct 20, 2025 at 10:08 AM Lynne Bartholomew >>>>> <[email protected]> wrote: >>>>> Hi, Mike and Orie. >>>>> >>>>> Mike, we do not believe we have heard from you regarding our 6 Oct. email >>>>> below. Please review, and let us know if further changes are needed. >>>>> >>>>> Orie, please review the updated files, and let us know if you would like >>>>> to make any changes. Please refresh your browser to view the latest: >>>>> >>>>> https://www.rfc-editor.org/authors/rfc9864.txt >>>>> https://www.rfc-editor.org/authors/rfc9864.pdf >>>>> https://www.rfc-editor.org/authors/rfc9864.html >>>>> https://www.rfc-editor.org/authors/rfc9864.xml >>>>> https://www.rfc-editor.org/authors/rfc9864-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side by side) >>>>> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html >>>>> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html (side by >>>>> side) >>>>> https://www.rfc-editor.org/authors/rfc9864-lastdiff.html >>>>> https://www.rfc-editor.org/authors/rfc9864-lastrfcdiff.html (side by side) >>>>> >>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html >>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html >>>>> >>>>> Thank you! >>>>> >>>>> Lynne Bartholomew >>>>> RFC Production Center >>>>> >>>>>> On Oct 6, 2025, at 11:08 AM, Lynne Bartholomew >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Forgot to mention that we are keeping track of the IANA updates that we >>>>>> will need to request just prior to publication. >>>>>> >>>>>>> On Oct 6, 2025, at 11:05 AM, Lynne Bartholomew >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hi, Mike. Thank you for your replies to our questions. >>>>>>> >>>>>>> Regarding this question and your reply: >>>>>>> >>>>>>>>> 2) <!-- [rfced] Section 2.1: Because it appears that "full-specified" >>>>>>>>> means "fully specified", we updated this text accordingly. If this >>>>>>>>> is incorrect, please let us know what "full-specified" means >>>>>>>>> (possibly "specified in full"?). >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are >>>>>>>>> full-specified.) >>>>>>>>> >>>>>>>>> Currently: >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are fully >>>>>>>>> specified.) --> >>>>>>>>> >>>>>>>> Mike> This has already been addressed by returning to using >>>>>>>> "fully-specified", etc. >>>>>>> >>>>>>> We only hyphenated where "fully specified" is used as a modifier. For >>>>>>> example, the text still shows "are fully specified. ...". There are >>>>>>> currently 12 instances of "fully specified" (no hyphen). Should we >>>>>>> hyphenate all of these as well? >>>>>>> >>>>>>> = = = = = >>>>>>> >>>>>>> Regarding question 14)b) and your reply: >>>>>>> >>>>>>>>> alg value (2 instances) / "alg" value (7 instances) >>>>>>>> >>>>>>>> Mike> Let's use "alg" value. >>>>>>> >>>>>>> >>>>>>> We also changed 'alg numbers' to '"alg" numbers'; although [FIDO2] >>>>>>> doesn't use the word "number", we see that "alg" is quoted everywhere. >>>>>>> Please let us know if we should revert this change. >>>>>>> >>>>>>> = = = = = >>>>>>> >>>>>>> Regarding question 14)c) and your reply: >>>>>>> >>>>>>>>> c) The following terms appear both with and without <tt> in the XML >>>>>>>>> file. Please review, and let us know if the current applications of >>>>>>>>> <tt> are correct and consistent. >>>>>>>>> >>>>>>>>> <tt>Ed25519</tt> (no <tt>s in IANA Considerations section) >>>>>>>>> <tt>Ed448</tt> (no <tt>s in IANA Considerations section) >>>>>>>>> <tt>EdDSA</tt> usage of <tt> appears to be inconsistent (e.g., in >>>>>>>>> the XML file, we see >>>>>>>>> "This redefines the COSE <tt>EdDSA</tt> algorithm identifier" and >>>>>>>>> "The following fully specified JOSE and COSE EdDSA algorithms" --> >>>>>>>> >>>>>>>> Mike> Please add <tt> where missing for algorithm names, such as "The >>>>>>>> following fully specified JOSE and COSE <tt>EdDSA</tt> algorithms" >>>>>>> >>>>>>> >>>>>>> We're not sure that we understood your request correctly. We updated >>>>>>> the example sentence that you listed but are not sure if any other >>>>>>> sentences need to be updated. Please review. If further changes are >>>>>>> needed, please specify via "Old" and "New" text where we should make >>>>>>> additional updates. >>>>>>> >>>>>>> = = = = = >>>>>>> >>>>>>> We have also incorporated the updates that you sent on Friday (3 Oct.). >>>>>>> >>>>>>> The latest files are posted here. Please refresh your browser: >>>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9864.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9864.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9864.html >>>>>>> https://www.rfc-editor.org/authors/rfc9864.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9864-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side by side) >>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html (side by >>>>>>> side) >>>>>>> https://www.rfc-editor.org/authors/rfc9864-lastdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9864-lastrfcdiff.html (side by >>>>>>> side) >>>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html >>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> Lynne Bartholomew >>>>>>> RFC Production Center >>>>>>> >>>>>>> >>>>>>>> From: Michael Jones <[email protected]> >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 >>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your review >>>>>>>> Date: October 3, 2025 at 3:52:59 AM PDT >>>>>>>> To: Lynne Bartholomew <[email protected]> >>>>>>>> Cc: "[email protected]" <[email protected]>, Orie >>>>>>>> <[email protected]>, "[email protected]" <[email protected]>, >>>>>>>> "[email protected]" <[email protected]>, "[email protected]" >>>>>>>> <[email protected]>, "[email protected]" <[email protected]>, >>>>>>>> "[email protected]" <[email protected]> >>>>>>>> >>>>>>>> One other point of clarification came up before AUTH48 that we should >>>>>>>> make. These clarifications need to be applied in three sections. >>>>>>>> >>>>>>>> In 2.2. Edwards-curve Digital Signature Algorithm (EdDSA): >>>>>>>> >>>>>>>> Old: >>>>>>>> EdDSA using Ed25519 curve >>>>>>>> New: >>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC 8032 >>>>>>>> >>>>>>>> Old: >>>>>>>> EdDSA using Ed448 curve >>>>>>>> New: >>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032 >>>>>>>> >>>>>>>> In 4.1.1. Fully-Specified JOSE Algorithm Registrations: >>>>>>>> >>>>>>>> Old: >>>>>>>> EdDSA using Ed25519 curve >>>>>>>> New: >>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC 8032 >>>>>>>> >>>>>>>> Old: >>>>>>>> EdDSA using Ed448 curve >>>>>>>> New: >>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032 >>>>>>>> >>>>>>>> In 4.2.1. Fully-Specified COSE Algorithm Registrations: >>>>>>>> >>>>>>>> Old: >>>>>>>> EdDSA using Ed25519 curve >>>>>>>> New: >>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC 8032 >>>>>>>> >>>>>>>> Old: >>>>>>>> EdDSA using Ed448 curve >>>>>>>> New: >>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032 >>>>>>>> >>>>>>>> Thanks again, >>>>>>>> -- Mike >>>>>>> >>>>>>>> On Oct 2, 2025, at 9:55 AM, Michael Jones >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> My replies are inline, prefixed by "Mike>". >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Michael Jones >>>>>>>> Sent: Friday, September 26, 2025 4:32 PM >>>>>>>> To: 'Lynne Bartholomew' <[email protected]> >>>>>>>> Cc: '[email protected]' <[email protected]>; Orie >>>>>>>> <[email protected]>; '[email protected]' <[email protected]>; >>>>>>>> '[email protected]' <[email protected]>; '[email protected]' >>>>>>>> <[email protected]>; '[email protected]' <[email protected]>; >>>>>>>> '[email protected]' <[email protected]> >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 >>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your review >>>>>>>> >>>>>>>> Also, please update Orie's author information to: >>>>>>>> >>>>>>>> <author fullname="Orie Steele" initials="O." surname="Steele"> >>>>>>>> <organization>Tradeverifyd</organization> >>>>>>>> <address> >>>>>>>> <email>[email protected]</email> >>>>>>>> </address> >>>>>>>> </author> >>>>>>>> >>>>>>>> That's what he asked for in >>>>>>>> https://github.com/ietf-wg-jose/draft-ietf-jose-fully-specified-algorithms/pull/34. >>>>>>>> (Yes, I realize that we're past the point of using the GitHub >>>>>>>> repository anymore.) >>>>>>>> >>>>>>>> Thanks again, >>>>>>>> -- Mike >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Michael Jones >>>>>>>> Sent: Friday, September 26, 2025 7:24 AM >>>>>>>> To: Lynne Bartholomew <[email protected]> >>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>> [email protected]; [email protected]; [email protected]; >>>>>>>> [email protected]; [email protected] >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 >>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your review >>>>>>>> >>>>>>>> Thanks, Lynne. That looks good. I'll respond to the rest of the >>>>>>>> questions shortly - probably this weekend. >>>>>>>> >>>>>>>> Best wishes, >>>>>>>> -- Mike >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lynne Bartholomew <[email protected]> >>>>>>>> Sent: Wednesday, September 24, 2025 9:33 AM >>>>>>>> To: Michael Jones <[email protected]> >>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>> [email protected]; [email protected]; [email protected]; >>>>>>>> [email protected]; [email protected] >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864 >>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your review >>>>>>>> >>>>>>>> Hi, Mike. We've applied consistent hyphenation per your request. >>>>>>>> >>>>>>>> Please note that we also hyphenated "fully specified replacements", >>>>>>>> "fully specified digital signature algorithm identifiers", "fully >>>>>>>> specified COSE ECDSA algorithms", "fully specified encryption", etc., >>>>>>>> because "fully specified" also acts as a modifier in these instances. >>>>>>>> >>>>>>>> The latest files are posted here. Please refresh your browser: >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side by side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html >>>>>>>> >>>>>>>> Please review our updates carefully, and let us know if anything is >>>>>>>> incorrect. >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Lynne Bartholomew >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Sep 20, 2025, at 1:40 PM, Michael Jones >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Thanks for your input, Sandy. I've thought about it since receiving >>>>>>>>> your note yesterday, and I'd be more comfortable if we restored the >>>>>>>>> hyphens to the compound adjective uses. In particular, please change >>>>>>>>> all instances of "fully specified algorithm" back to "fully-specified >>>>>>>>> algorithm". >>>>>>>>> >>>>>>>>> Yes, CMOS permits the omission of the hyphen. But including the >>>>>>>>> hyphen makes it sound like my writing, which I've decided is >>>>>>>>> important to me. >>>>>>>>> >>>>>>>>> Thanks all! >>>>>>>>> -- Mike >>>>>>>>> >>>>>>>>> P.S. I'll address the other AUTH48 questions shortly. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Sandy Ginoza <[email protected]> >>>>>>>>> Sent: Friday, September 19, 2025 3:25 PM >>>>>>>>> To: Michael Jones <[email protected]> >>>>>>>>> Cc: RFC Editor <[email protected]>; [email protected]; >>>>>>>>> Alice Russo <[email protected]>; [email protected]; >>>>>>>>> [email protected]; [email protected]; [email protected]; >>>>>>>>> [email protected] >>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864 >>>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your review >>>>>>>>> >>>>>>>>> Hi Mike, >>>>>>>>> >>>>>>>>> Thank for trying to follow the guidance we previously sent! What you >>>>>>>>> said is correct — compound adjectives are hyphenated when appearing >>>>>>>>> before the noun. CMOS treats adverbs ending with -ly differently — >>>>>>>>> that is, no hyphen whether appearing before or after the noun. We >>>>>>>>> removed the hyphen from “fully qualified” for this reason. If you >>>>>>>>> feel strongly about using the hyphen in this case, please let us know. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sandy >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sep 19, 2025, at 10:47 AM, Michael Jones >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Thanks for the detailed work on this specification, Lynne and Karen! >>>>>>>>>> Before responding to the rest of the feedback, I wanted to get a >>>>>>>>>> broader set of opinions one change made, including possibly from >>>>>>>>>> Sandy and Alice, who I’ve added to the thread. >>>>>>>>>> >>>>>>>>>> Uses of the compound adjective "fully-specified" (typically used in >>>>>>>>>> the context "fully-specified algorithms") were changed to "fully >>>>>>>>>> specified". The rationale for this change cited was as follows: >>>>>>>>>> >>>>>>>>>> a) The following term was used inconsistently in this document. >>>>>>>>>> We chose to use the latter form. Please let us know any objections. >>>>>>>>>> >>>>>>>>>> fully-specified / >>>>>>>>>> fully specified (e.g., "are fully-specified", "are fully >>>>>>>>>> specified", "fully specified RSA algorithms")* >>>>>>>>>> >>>>>>>>>> * Per the Chicago Manual of Style >>>>>>>>>> ("Compounds formed by an adverb ending in ‑ly plus an adjective or >>>>>>>>>> participle (such as largely irrelevant or smartly dressed) are not >>>>>>>>>> hyphenated either before or after a noun, since ambiguity is >>>>>>>>>> virtually impossible (a smartly dressed couple).") >>>>>>>>>> >>>>>>>>>> In previous interactions with the RFC Editor, I’d been told that the >>>>>>>>>> normal convention was to hyphenate compound adjectives qualifying a >>>>>>>>>> noun, such as “fully-specified algorithms”, but to not hyphenate >>>>>>>>>> noun phrases, such as “The algorithm is fully specified”. >>>>>>>>>> Therefore, I followed that convention in the document. >>>>>>>>>> >>>>>>>>>> Not that this is authoritative, but a Bing search result for “when >>>>>>>>>> to hyphenate words” opens with: >>>>>>>>>> Here are some rules for when to hyphenate words: >>>>>>>>>> • Compound Adjectives: Hyphenate two or more words when they come >>>>>>>>>> before a noun and act as a single idea, such as "well-written book". >>>>>>>>>> • Modifiers: Use a hyphen when a compound modifier precedes the noun >>>>>>>>>> it modifies, like "high-speed chase". >>>>>>>>>> >>>>>>>>>> This seems to support retaining the hyphenation when used as a >>>>>>>>>> compound adjective. >>>>>>>>>> >>>>>>>>>> Personally, retaining the hyphenation in these contexts seems more >>>>>>>>>> natural to me, the Chicago Manual of Style’s suggestion >>>>>>>>>> notwithstanding. >>>>>>>>>> >>>>>>>>>> But I’d be curious what others think. I’ve added Sandy and Alice to >>>>>>>>>> the thread in case they want to weigh in. >>>>>>>>>> >>>>>>>>>> Thanks all, >>>>>>>>>> -- Mike >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: [email protected] <[email protected]> >>>>>>>>>> Sent: Thursday, September 18, 2025 12:52 PM >>>>>>>>>> To: [email protected]; [email protected] >>>>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>>>> [email protected]; [email protected]; [email protected]; >>>>>>>>>> [email protected] >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864 >>>>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your review >>>>>>>> >>>>>>>> Authors, >>>>>>>> >>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>> necessary) the following questions, which are also in the source file. >>>>>>>> >>>>>>>> 1) <!-- [rfced] Please note that the document title has been updated >>>>>>>> as follows. The abbreviations "JOSE” and "COSE" have been expanded per >>>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please let us know any >>>>>>>> objections. >>>>>>>> >>>>>>>> Original: >>>>>>>> Fully-Specified Algorithms for JOSE and COSE >>>>>>>> >>>>>>>> Currently: >>>>>>>> Fully Specified Algorithms for JSON Object Signing and Encryption >>>>>>>> (JOSE) >>>>>>>> and CBOR Object Signing and Encryption (COSE) --> >>>>>>>> >>>>>>>> Mike> The title in the current XML (using "Fully-Specified") is >>>>>>>> appropriate. >>>>>>>> >>>>>>>> 2) <!-- [rfced] Section 2.1: Because it appears that "full-specified" >>>>>>>> means "fully specified", we updated this text accordingly. If this is >>>>>>>> incorrect, please let us know what "full-specified" means (possibly >>>>>>>> "specified in full"?). >>>>>>>> >>>>>>>> Original: >>>>>>>> (The corresponding JOSE registrations in [RFC7518] are >>>>>>>> full-specified.) >>>>>>>> >>>>>>>> Currently: >>>>>>>> (The corresponding JOSE registrations in [RFC7518] are fully >>>>>>>> specified.) --> >>>>>>>> >>>>>>>> Mike> This has already been addressed by returning to using >>>>>>>> "fully-specified", etc. >>>>>>>> >>>>>>>> 3) <!-- [rfced] Section 3: We see "COSE_Encrypt" but not "COSE >>>>>>>> Encrypt" >>>>>>>> in RFC 9052, and we do not see "COSE Encrypt" or "COSE_Encrypt" in RFC >>>>>>>> 9053. Please let us know how/if this sentence should be updated so >>>>>>>> that it is clear to readers. For example, we see "using COSE_Encrypt, >>>>>>>> as specified in Section 5.1 of [RFC9052]" later in this section. >>>>>>>> >>>>>>>> Original: >>>>>>>> This section describes the construction of fully-specified encryption >>>>>>>> algorithm identifiers in the context of the JOSE and COSE encryption >>>>>>>> schemes JSON Web Encryption (JWE), as described in [RFC7516] and >>>>>>>> [RFC7518], and COSE Encrypt, as described in [RFC9052] and [RFC9053]. >>>>>>>> --> >>>>>>>> >>>>>>>> Mike> Let's change "COSE Encrypt" to "COSE encryption". >>>>>>>> >>>>>>>> New: >>>>>>>> This section describes the construction of fully-specified >>>>>>>> encryption algorithm identifiers in the context of the JOSE and COSE >>>>>>>> encryption schemes >>>>>>>> JSON Web Encryption (JWE), as described in <xref target="RFC7516"/> >>>>>>>> and <xref target="RFC7518"/>, and >>>>>>>> COSE encryption, as described in <xref target="RFC9052"/> and <xref >>>>>>>> target="RFC9053"/>. >>>>>>>> >>>>>>>> 4) <!-- [rfced] Section 3: Please confirm that "must specify" in this >>>>>>>> sentence shouldn't be "MUST specify". >>>>>>>> >>>>>>>> Original: >>>>>>>> To perform fully-specified encryption in COSE, the outer "alg" value >>>>>>>> MUST specify all parameters for key establishment and the inner "alg" >>>>>>>> value must specify all parameters for symmetric encryption. --> >>>>>>>> >>>>>>>> Mike> The original text with "MUST specify" is fine. >>>>>>>> >>>>>>>> 5) <!-- [rfced] Section 3.1: "as are the key wrapping with AES GCM >>>>>>>> algorithms" reads oddly. Should "key wrapping with AES GCM" be placed >>>>>>>> in quotes, per the quoted algorithm types in the next paragraph? >>>>>>>> >>>>>>>> We have the same question for "The JOSE Key Encryption with PBES2 >>>>>>>> algorithms" two paragraphs later. >>>>>>>> >>>>>>>> Original (all three paragraphs included for context): >>>>>>>> In both JOSE and COSE, all registered key wrapping algorithms are >>>>>>>> fully specified, as are the key wrapping with AES GCM algorithms. An >>>>>>>> example of a fully-specified key wrapping algorithm is "A128KW" (AES >>>>>>>> Key Wrap using 128-bit key). >>>>>>>> >>>>>>>> The JOSE "dir" and COSE "direct" algorithms are fully specified. The >>>>>>>> COSE direct+HKDF algorithms are fully specified. >>>>>>>> >>>>>>>> The JOSE Key Encryption with PBES2 algorithms are fully specified. --> >>>>>>>> >>>>>>>> Mike> Let's change >>>>>>>> "the key wrapping with AES GCM algorithms" >>>>>>>> to >>>>>>>> "the algorithms performing key wrapping using AES GCM" >>>>>>>> >>>>>>>> Mike> Let's change >>>>>>>> "The JOSE Key Encryption with PBES2 algorithms are fully specified." >>>>>>>> to >>>>>>>> "The JOSE algorithms performing Key Encryption with PBES2 are fully >>>>>>>> specified." >>>>>>>> >>>>>>>> 6) <!-- [rfced] We have included some specific questions about the >>>>>>>> IANA text below. In addition to responding to those questions, please >>>>>>>> review all of the IANA-related updates carefully and let us know if >>>>>>>> any further updates are needed. >>>>>>>> >>>>>>>> "JSON Web Signature and Encryption Algorithms" registry: >>>>>>>> https://www.iana.org/assignments/jose >>>>>>>> >>>>>>>> "COSE Algorithms" registry: >>>>>>>> https://www.iana.org/assignments/cose >>>>>>>> >>>>>>>> a) Section 4.1: As the "JSON Web Signature and Encryption Algorithms" >>>>>>>> registry was established by RFC 7518, we have replaced RFC 7515 with >>>>>>>> RFC 7518 as shown below. We have also removed RFC 7515 from the >>>>>>>> normative references section as it was only mentioned in Section 4.1. >>>>>>>> Note that RFC 7518 is listed as an informative reference; please let >>>>>>>> us know if this is okay as is or if it should be normative. >>>>>>>> >>>>>>>> We also included that this document was listed as an additional >>>>>>>> reference for the registry at the end of the sentence below (and have >>>>>>>> removed the related text from Section 4.3, which describes the updates >>>>>>>> to the review instructions for the DEs). >>>>>>>> Note that a similar change was made to Section 4.2 for the "COSE >>>>>>>> Algorithms" registry, as shown below. >>>>>>>> >>>>>>>> Please review and let us know of any objections. >>>>>>>> >>>>>>>> Original (Section 4.1): >>>>>>>> This section registers the following values in the IANA "JSON Web >>>>>>>> Signature and Encryption Algorithms" registry [IANA.JOSE] established >>>>>>>> by [RFC7515]. >>>>>>>> >>>>>>>> Currently: >>>>>>>> IANA has registered the values in this section in the "JSON Web >>>>>>>> Signature and Encryption Algorithms" registry [IANA.JOSE] established >>>>>>>> by [RFC7518] and has listed this document as an additional reference >>>>>>>> for the registry. >>>>>>>> >>>>>>>> ... >>>>>>>> Original (Section 4.2): >>>>>>>> This section registers the following values in the IANA "COSE >>>>>>>> Algorithms" registry [IANA.COSE]. >>>>>>>> >>>>>>>> Currently: >>>>>>>> IANA has registered the following values in the "COSE Algorithms" >>>>>>>> registry [IANA.COSE] established by [RFC9053] and [RFC9054] and has >>>>>>>> added this document as an additional reference for the registry. >>>>>>>> >>>>>>>> Mike> I agree with both of those changes. >>>>>>>> >>>>>>>> b) Per the changes noted in a) above, we will ask IANA to update the >>>>>>>> reference for the "COSE Algorithms" registry as shown below (i.e., >>>>>>>> update the section number listed for this document). >>>>>>>> >>>>>>>> Original: >>>>>>>> Reference >>>>>>>> [RFC9053][RFC9054][draft-ietf-jose-fully-specified-algorithms-13, >>>>>>>> Section 4.3.1] >>>>>>>> >>>>>>>> Suggested: >>>>>>>> Reference >>>>>>>> [RFC9053][RFC9054][RFC9864, Section 4.2] >>>>>>>> >>>>>>>> Mike> Good >>>>>>>> >>>>>>>> c) In Section 4.2.1, we note that this document lists section numbers >>>>>>>> for the algorithms but the "COSE Algorithm" registry does not, so >>>>>>>> there is a mismatch. Should "Section 2.1" and "Section 2.2" be removed >>>>>>>> from this document for consistency with the registry, or should IANA >>>>>>>> add "Section 2.1" and "Section 2.2" accordingly for consistency with >>>>>>>> this document? >>>>>>>> >>>>>>>> Section 2.1 listed in the document >>>>>>>> but not in the registry for: >>>>>>>> ESP256 >>>>>>>> ESP384 >>>>>>>> ESP512 >>>>>>>> ESB256 >>>>>>>> ESB320 >>>>>>>> ESB384 >>>>>>>> ESB512 >>>>>>>> >>>>>>>> Section 2.2 listed in the document >>>>>>>> but not in the registry for: >>>>>>>> Ed25519 >>>>>>>> Ed448 >>>>>>>> >>>>>>>> Mike> Thanks for noting the inconsistency. Please include the section >>>>>>>> numbers everywhere. >>>>>>>> >>>>>>>> d) For "ES512" in the "COSE Algorithm" registry, we note that "IETF" >>>>>>>> is not listed under "Change Controller". Should "IETF" be added to the >>>>>>>> registry or removed from this document? >>>>>>>> >>>>>>>> Currently in this document: >>>>>>>> Name: ES512 >>>>>>>> Value: -36 >>>>>>>> Description: ECDSA w/ SHA-512 >>>>>>>> Capabilities: [kty] >>>>>>>> Change Controller: IETF >>>>>>>> Reference: [RFC9053] and RFC 9864 >>>>>>>> Recommended: Deprecated >>>>>>>> --> >>>>>>>> >>>>>>>> Mike> Please add IETF as the change controller >>>>>>>> >>>>>>>> 7) <!-- [rfced] RFC 8152 has been obsoleted by RFC 9052. May we >>>>>>>> replace all instances of RFC 8152 with RFC 9052, or may we add the >>>>>>>> following sentence to the first mention of RFC 8152? Please let us >>>>>>>> know your preference. >>>>>>>> >>>>>>>> Original: >>>>>>>> Furthermore, while in [RFC7518] JOSE specifies that both "Deprecated" >>>>>>>> and "Prohibited" can be used, in [RFC8152] COSE specifies the use >>>>>>>> of "Deprecated" but not "Prohibited". >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> Furthermore, while in [RFC7518] JOSE specifies that both "Deprecated" >>>>>>>> and "Prohibited" can be used, in [RFC8152] COSE specifies the use >>>>>>>> of "Deprecated" but not "Prohibited" (note that [RFC8152] has been >>>>>>>> obsoleted by [RFC9052]). >>>>>>>> --> >>>>>>>> >>>>>>>> Mike> We kept the reference to 8152 because the referenced text wasn't >>>>>>>> carried forward into the documents that replaced it. Let's go with >>>>>>>> this: >>>>>>>> >>>>>>>> New: >>>>>>>> Furthermore, while in [RFC7518] JOSE specifies that both "Deprecated" >>>>>>>> and "Prohibited" can be used, in [RFC8152] COSE specifies the use >>>>>>>> of "Deprecated" but not "Prohibited". (Note that [RFC8152] has been >>>>>>>> obsoleted by [RFC9052].) >>>>>>>> >>>>>>>> 8) <!-- [rfced] Section 4.4: We see that the entry for "Recommended" >>>>>>>> is formatted differently than the entries for "Deprecated" and >>>>>>>> "Prohibited" that appear just before it. Would you like all three >>>>>>>> entries to be formatted in the same way? >>>>>>>> >>>>>>>> Original: >>>>>>>> Deprecated >>>>>>>> There is a preferred mechanism to achieve similar functionality to >>>>>>>> that referenced by the identifier; this replacement functionality >>>>>>>> SHOULD be utilized in new deployments in preference to the >>>>>>>> deprecated identifier, unless there exist documented operational >>>>>>>> or regulatory requirements that prevent migration away from the >>>>>>>> deprecated identifier. >>>>>>>> >>>>>>>> Prohibited >>>>>>>> The identifier and the functionality that it references MUST NOT >>>>>>>> be used. (Identifiers may be designated as "Prohibited" due to >>>>>>>> security flaws, for instance.) >>>>>>>> ... >>>>>>>> Recommended: Does the IETF have a consensus recommendation to use >>>>>>>> the algorithm? The legal values are "Yes", "No", "Filter Only", >>>>>>>> "Prohibited", and "Deprecated". >>>>>>>> >>>>>>>> Possibly: >>>>>>>> Recommended >>>>>>>> Does the IETF have a consensus recommendation to use the >>>>>>>> algorithm? The legal values are "Yes", "No", "Filter Only", >>>>>>>> "Prohibited", and "Deprecated". --> >>>>>>>> >>>>>>>> Mike> Yes, please make the formatting consistent in the way that you >>>>>>>> suggest. >>>>>>>> >>>>>>>> 9) <!-- [rfced] Section 4.4: Because the title of RFC 8996 is >>>>>>>> "Deprecating TLS 1.0 and TLS 1.1", should 'the term "Deprecated" is >>>>>>>> used in the title of [RFC8996]' be 'a variation of the term >>>>>>>> "Deprecated" is used in the title of [RFC8996]'? >>>>>>>> >>>>>>>> Original: >>>>>>>> For instance, the term "Deprecated" is used in the title of >>>>>>>> [RFC8996], but the actual specification text uses the terminology >>>>>>>> "MUST NOT be used". --> >>>>>>>> >>>>>>>> Mike> Yes. 'a variation of the term "Deprecated" is used in the title >>>>>>>> of [RFC8996]' works for me. >>>>>>>> >>>>>>>> 10) <!-- [rfced] [OpenID.Discovery]: We see "Jones, M.B." in this >>>>>>>> document but "M. Jones" on the provided web page. We normally make >>>>>>>> the author listings in the document match what we see on the provided >>>>>>>> web page. Would it be possible for Mike to update >>>>>>>> <https://openid.net/specs/openid-connect-discovery-1_0.html> and list >>>>>>>> his name as "M.B. Jones", or should we change "Jones, M.B." to "Jones, >>>>>>>> M." here? >>>>>>>> >>>>>>>> Original: >>>>>>>> [OpenID.Discovery] >>>>>>>> Sakimura, N., Bradley, J., Jones, M.B., and E. Jay, >>>>>>>> "OpenID Connect Discovery 1.0", 15 December 2023, >>>>>>>> <https://openid.net/specs/openid-connect-discovery- >>>>>>>> 1_0.html>. --> >>>>>>>> >>>>>>>> Mike> https://openid.net/specs/openid-connect-discovery-1_0.html >>>>>>>> cannot be changed. Please update the reference to match the >>>>>>>> referenced specification by removing the "B." in this case. >>>>>>>> >>>>>>>> 11) <!-- [rfced] The provided URL for [FIDO2] yields a 404. May we >>>>>>>> update as suggested (which includes correcting the names of the last >>>>>>>> two authors in the list)? If not, please provide a working URL and >>>>>>>> correct information. >>>>>>>> >>>>>>>> Original: >>>>>>>> [FIDO2] Bradley, J., Jones, M., Kumar, A., Lindemann, R., Johan, >>>>>>>> J., and D. David, "Client to Authenticator Protocol >>>>>>>> (CTAP)", FIDO Alliance Proposed Standard, 28 February >>>>>>>> 2025, <https://fidoalliance.org/specs/fido-v2.2-ps- >>>>>>>> 20250228/fido-client-to-authenticator-protocol-v2.2-ps- >>>>>>>> 20250228.html>. >>>>>>>> >>>>>>>> Suggested: >>>>>>>> [FIDO2] Bradley, J., Jones, M.B., Kumar, A., Lindemann, R., >>>>>>>> Verrept, J., and D. Waite, "Client to Authenticator >>>>>>>> Protocol (CTAP)", FIDO Alliance Proposed Standard, 14 >>>>>>>> July 2025, <https://fidoalliance.org/specs/ >>>>>>>> fido-v2.2-ps-20250714/ >>>>>>>> fido-client-to-authenticator-protocol-v2.2-ps-20250714.html>. >>>>>>>> --> >>>>>>>> >>>>>>>> Mike> Yes, please apply this correction. >>>>>>>> >>>>>>>> 12) <!-- [rfced] Acknowledgements: John Preuß Mattsson recently >>>>>>>> informed us that his last name is "Preuß Mattsson". Because it >>>>>>>> appears that the names should be listed in alphabetical order, we >>>>>>>> moved John's name in the list accordingly. Please let us know any >>>>>>>> concerns. >>>>>>>> >>>>>>>> Original: >>>>>>>> ... >>>>>>>> Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil >>>>>>>> Madden, John Preuß Mattsson, Kathleen Moriarty, Jeremy O'Donoghue, >>>>>>>> Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes ... >>>>>>>> >>>>>>>> Currently: >>>>>>>> ... >>>>>>>> Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil >>>>>>>> Madden, Kathleen Moriarty, Jeremy O'Donoghue, John Preuß Mattsson, >>>>>>>> Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes >>>>>>>> ... --> >>>>>>>> >>>>>>>> Mike> Works for me. >>>>>>>> >>>>>>>> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>>>> online Style Guide at >>>>>>>> <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. --> >>>>>>>> >>>>>>>> Mike> I am not aware of any inclusive language changes needed. >>>>>>>> >>>>>>>> 14) <!-- [rfced] Please let us know if any changes are needed for the >>>>>>>> following: >>>>>>>> >>>>>>>> a) The following term was used inconsistently in this document. >>>>>>>> We chose to use the latter form. Please let us know any objections. >>>>>>>> >>>>>>>> fully-specified / >>>>>>>> fully specified (e.g., "are fully-specified", "are fully >>>>>>>> specified", "fully specified RSA algorithms")* >>>>>>>> >>>>>>>> * Per the Chicago Manual of Style >>>>>>>> ("Compounds formed by an adverb ending in ‑ly plus an adjective or >>>>>>>> participle (such as largely irrelevant or smartly dressed) are not >>>>>>>> hyphenated either before or after a noun, since ambiguity is >>>>>>>> virtually impossible (a smartly dressed couple).") >>>>>>>> >>>>>>>> Mike> We decided earlier to go with "fully-specified". No additional >>>>>>>> changes are needed in this regard. >>>>>>>> >>>>>>>> b) The following terms appear to be used inconsistently in this >>>>>>>> document. Please let us know which form is preferred. >>>>>>>> >>>>>>>> alg value (2 instances) / "alg" value (7 instances) >>>>>>>> >>>>>>>> Mike> Let's use "alg" value. >>>>>>>> >>>>>>>> enc value ("alg and enc values") / "enc" value (5 instances) >>>>>>>> >>>>>>>> Mike> Let's use "enc" value. >>>>>>>> >>>>>>>> HSS/LMS / HSS-LMS ("HSS/LMS Hash-Based Digital Signature Algorithm", >>>>>>>> "HSS-LMS algorithm") >>>>>>>> >>>>>>>> Mike> Both "HSS-LMS" and "HSS/LMS hash-based digital signature" are >>>>>>>> used in the COSE algorithms registry. Therefore, the current text is >>>>>>>> consistent with the registry entry. No change is needed. >>>>>>>> >>>>>>>> c) The following terms appear both with and without <tt> in the XML >>>>>>>> file. Please review, and let us know if the current applications of >>>>>>>> <tt> are correct and consistent. >>>>>>>> >>>>>>>> <tt>Ed25519</tt> (no <tt>s in IANA Considerations section) >>>>>>>> <tt>Ed448</tt> (no <tt>s in IANA Considerations section) >>>>>>>> <tt>EdDSA</tt> usage of <tt> appears to be inconsistent (e.g., in >>>>>>>> the XML file, we see >>>>>>>> "This redefines the COSE <tt>EdDSA</tt> algorithm identifier" and >>>>>>>> "The following fully specified JOSE and COSE EdDSA algorithms" --> >>>>>>>> >>>>>>>> Mike> Please add <tt> where missing for algorithm names, such as "The >>>>>>>> following fully specified JOSE and COSE <tt>EdDSA</tt> algorithms" >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> Lynne Bartholomew and Karen Moore >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>> Mike> Thank you! >>>>>>>> >>>>>>>>>> On Sep 18, 2025, at 12:48 PM, RFC Editor via auth48archive >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> *****IMPORTANT***** >>>>>>>>>> >>>>>>>>>> Updated 2025/09/18 >>>>>>>>>> >>>>>>>>>> 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://maila/ >>>>>>>>>> rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P >>>>>>>>>> 8 >>>>>>>>>> O4Zc&data=05%7C02%7C%7C761b71ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f >>>>>>>>>> 6 >>>>>>>>>> 40afb435aaaaaaaaaaaa%7C1%7C0%7C638939174977368758%7CUnknown%7CTWFpbGZ >>>>>>>>>> s >>>>>>>>>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >>>>>>>>>> j >>>>>>>>>> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c67E5JmKVA73PwHxHTAjKpB >>>>>>>>>> j >>>>>>>>>> ckPOveGLD5eLfMLHLPU%3D&reserved=0 >>>>>>>>>> >>>>>>>>>> * The archive itself: >>>>>>>>>> >>>>>>>>>> https://maila/ >>>>>>>>>> rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7C%7C >>>>>>>>>> 7 >>>>>>>>>> 61b71ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C >>>>>>>>>> 1 >>>>>>>>>> %7C0%7C638939174977385249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >>>>>>>>>> y >>>>>>>>>> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D >>>>>>>>>> % >>>>>>>>>> 3D%7C0%7C%7C%7C&sdata=TaXkq4q%2BqGcE0jxkrRshom%2F30XVg%2BqzoLR82FE1tL >>>>>>>>>> K >>>>>>>>>> 0%3D&reserved=0 >>>>>>>>>> >>>>>>>>>> * 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%2Fauthors%2Frfc9864.xml&data=05%7C02%7C%7C91aa2df0daa5 >>>>>>>>>> 4943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638 >>>>>>>>>> 943284065580201%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO >>>>>>>>>> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >>>>>>>>>> C%7C%7C&sdata=J%2B%2BbnL37e54MKyJRORpcnBYmCykPfGy8DE5WZCZdWWI%3D&rese >>>>>>>>>> rved=0 >>>>>>>>>> >>>>>>>>>> https://www/. >>>>>>>>>> rfc-editor.org%2Fauthors%2Frfc9864.html&data=05%7C02%7C%7C91aa2df0daa >>>>>>>>>> 54943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63 >>>>>>>>>> 8943284065596919%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi >>>>>>>>>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% >>>>>>>>>> 7C%7C%7C&sdata=q01yZ03I%2FviVW6nDhK2aVURwm9IVrZ0tretGnwYSYqQ%3D&reser >>>>>>>>>> ved=0 >>>>>>>>>> >>>>>>>>>> https://www/. >>>>>>>>>> rfc-editor.org%2Fauthors%2Frfc9864.pdf&data=05%7C02%7C%7C91aa2df0daa5 >>>>>>>>>> 4943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638 >>>>>>>>>> 943284065613325%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO >>>>>>>>>> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >>>>>>>>>> C%7C%7C&sdata=9AWfQDiclBkvJu%2FRag2iAWy82RqR%2FiBXZ0%2BjGOJGzqE%3D&re >>>>>>>>>> served=0 >>>>>>>>>> >>>>>>>>>> https://www/. >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065629453%7CUnknown%7CTWFpbG >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kB71H%2F%2B2fbtM%2BI >>>>>>>>>> t8vVSL56Va42PeWdjLFpCcaQV3zrY%3D&reserved=0 >>>>>>>>>> fc-editor.org%2Fauthors%2Frfc9864.txt&data=05%7C02%7C%7C761b71ce49ea4 >>>>>>>>>> 2 >>>>>>>>>> e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63893 >>>>>>>>>> 9 >>>>>>>>>> 174977450136%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw >>>>>>>>>> L >>>>>>>>>> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >>>>>>>>>> % >>>>>>>>>> 7C&sdata=Sw4hdekzH6euwekPdmkgArRgDE9jxN%2FBbxniPqBXGb4%3D&reserved=0 >>>>>>>>>> >>>>>>>>>> Diff file of the text: >>>>>>>>>> >>>>>>>>>> https://www/. >>>>>>>>>> rfc-editor.org%2Fauthors%2Frfc9864-diff.html&data=05%7C02%7C%7C91aa2d >>>>>>>>>> f0daa54943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0 >>>>>>>>>> %7C638943284065645773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU >>>>>>>>>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >>>>>>>>>> %7C0%7C%7C%7C&sdata=61beAaISKTA9xH5PalRDeAINUUCL23Ie3dDucrqSf9Q%3D&re >>>>>>>>>> served=0 >>>>>>>>>> >>>>>>>>>> https://www/. >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065664319%7CUnknown%7CTWFpbG >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VZi1WfQUh8aqDbh5FgtP >>>>>>>>>> 3BCPWS3qiwliQEcgLAhf33g%3D&reserved=0 >>>>>>>>>> fc-editor.org%2Fauthors%2Frfc9864-rfcdiff.html&data=05%7C02%7C%7C761b >>>>>>>>>> 7 >>>>>>>>>> 1ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C >>>>>>>>>> 0 >>>>>>>>>> %7C638939174977482323%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU >>>>>>>>>> s >>>>>>>>>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% >>>>>>>>>> 7 >>>>>>>>>> C0%7C%7C%7C&sdata=EvN4SdkHmBnKNv4SjQPMZT3Crd9P%2FAdrRVzHTQJ50WU%3D&re >>>>>>>>>> s >>>>>>>>>> erved=0 (side by side) >>>>>>>>>> >>>>>>>>>> Diff of the XML: >>>>>>>>>> >>>>>>>>>> https://www/. >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065680577%7CUnknown%7CTWFpbG >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mQFxALBZrQ5Egd7CsSIS >>>>>>>>>> j3tosB3tyHFlqc8mZAYgoCk%3D&reserved=0 >>>>>>>>>> fc-editor.org%2Fauthors%2Frfc9864-xmldiff1.html&data=05%7C02%7C%7C761 >>>>>>>>>> b >>>>>>>>>> 71ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7 >>>>>>>>>> C >>>>>>>>>> 0%7C638939174977501023%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW >>>>>>>>>> U >>>>>>>>>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >>>>>>>>>> % >>>>>>>>>> 7C0%7C%7C%7C&sdata=zb%2BxMfmrtEW4EzQuOyYybMEbf%2BPxJ%2FYy1xLdb5VWkig% >>>>>>>>>> 3 >>>>>>>>>> D&reserved=0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tracking progress >>>>>>>>>> ----------------- >>>>>>>>>> >>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>> >>>>>>>>>> https://www/. >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065697092%7CUnknown%7CTWFpbG >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OKWb9Ta3CEbIuo8DrYng >>>>>>>>>> nphBXzbyeulO%2FcvFWk1vADw%3D&reserved=0 >>>>>>>>>> fc-editor.org%2Fauth48%2Frfc9864&data=05%7C02%7C%7C761b71ce49ea42e893 >>>>>>>>>> e >>>>>>>>>> 008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389391749 >>>>>>>>>> 7 >>>>>>>>>> 7517704%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM >>>>>>>>>> D >>>>>>>>>> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>>>>> d >>>>>>>>>> ata=IqovDgFGL85gX%2B3TddI%2FRyWRSVYSIszXtFZnxn1f9%2Bs%3D&reserved=0 >>>>>>>>>> >>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>> >>>>>>>>>> Thank you for your cooperation, >>>>>>>>>> >>>>>>>>>> RFC Editor >>>>>>>>>> >>>>>>>>>> -------------------------------------- >>>>>>>>>> RFC9864 (draft-ietf-jose-fully-specified-algorithms-13) >>>>>>>>>> >>>>>>>>>> Title : Fully-Specified Algorithms for JOSE and COSE >>>>>>>>>> Author(s) : M.B. Jones, O. Steele >>>>>>>>>> WG Chair(s) : John Bradley, John Preuß Mattsson, Karen >>>>>>>>>> O'Donoghue >>>>>>>>>> >>>>>>>>>> Area Director(s) : Deb Cooley, Paul Wouters >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> <rfc9864.xml> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
