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]
