Hi, Sabrina. Great! Thank you for the quick fix! Lynne Bartholomew RFC Production Center
> On Oct 28, 2025, at 9:48 AM, Sabrina Tanamal via RT <[email protected]> > wrote: > > Hi Lynne, > > Thanks for catching this! The description for Ed25519 has been updated: > > Ed25519 -19 EdDSA using the Ed25519 parameter set in Section 5.1 of [RFC8032] > > Please see > https://www.iana.org/assignments/cose > > Thanks, > Sabrina > > On Tue Oct 28 16:04:57 2025, [email protected] wrote: >> Hi, Sabrina. Thank you for the updates! All looks good, with the >> exception of this item on <https://www.iana.org/assignments/cose>: >> For the "Ed25519 -19" entry, please change "Section 5.1 [RFC8032]" >> to "Section 5.1 of [RFC8032]". >> >> Thanks again! >> >> Lynne Bartholomew >> RFC Production Center >> >>> On Oct 27, 2025, at 2:26 PM, Sabrina Tanamal via RT <iana- >>> [email protected]> wrote: >>> >>> Hi Lynne, >>> >>> These updates have been completed: >>> >>> https://www.iana.org/assignments/jose >>> https://www.iana.org/assignments/cose >>> >>> Please let me know if anything was missed. >>> >>> Thank you, >>> Sabrina >>> >>> On Thu Oct 23 16:22:25 2025, [email protected] wrote: >>>> 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]; jose- >>>>>>> [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 >>>>>>>>>>>> Mike> "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 >>>>>>>>>>>> Mike> "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, >>>>>>>>>>>> Mike> such >>>>>>>>>>>> Mike> as "The following fully specified JOSE and COSE >>>>>>>>>>>> Mike> <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]" <jose- >>>>>>>>>>>> [email protected]>, >>>>>>>>>>>> "[email protected]" <[email protected]>, >>>>>>>>>>>> "[email protected]" <[email protected]>, >>>>>>>>>>>> "[email protected]" <[email protected]>, >>>>>>>>>>>> "[email protected]" <auth48archive@rfc- >>>>>>>>>>>> editor.org> >>>>>>>>>>>> >>>>>>>>>>>> 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]' <jose- >>>>>>>>>>>> [email protected]>; >>>>>>>>>>>> '[email protected]' <[email protected]>; >>>>>>>>>>>> '[email protected]' <[email protected]>; >>>>>>>>>>>> '[email protected]' <[email protected]>; >>>>>>>>>>>> '[email protected]' <auth48archive@rfc- >>>>>>>>>>>> editor.org> >>>>>>>>>>>> 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] <rfc-editor@rfc- >>>>>>>>>>>>>> editor.org> >>>>>>>>>>>>>> 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") >>>>>>>>>>>> Mike> 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 >>>>>>>>>>>> Mike> "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 >>>>>>>>>>>> Mike> the >>>>>>>>>>>> Mike> 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 >>>>>>>>>>>> Mike> text wasn't carried forward into the documents that >>>>>>>>>>>> Mike> 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 >>>>>>>>>>>> Mike> 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 >>>>>>>>>>>> Mike> 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- >>>>>>>>>>>> Mike> 1_0.html cannot be changed. Please update the >>>>>>>>>>>> Mike> reference >>>>>>>>>>>> Mike> to match the referenced specification by removing the >>>>>>>>>>>> Mike> "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 >>>>>>>>>>>> Mike> 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 >>>>>>>>>>>> Mike> 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 >>>>>>>>>>>> Mike> signature" are used in the COSE algorithms registry. >>>>>>>>>>>> Mike> Therefore, the current text is consistent with the >>>>>>>>>>>> Mike> 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, >>>>>>>>>>>> Mike> such >>>>>>>>>>>> Mike> as "The following fully specified JOSE and COSE >>>>>>>>>>>> Mike> <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]
