Hi, Mike. We've updated the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9864) and will prepare this document for publication shortly.
Thank you! Lynne Bartholomew RFC Production Center > From: Lynne Bartholomew <[email protected]> > Subject: Re: [IANA #1434984] [IANA] Re: AUTH48: RFC-to-be 9864 > <draft-ietf-jose-fully-specified-algorithms-13> for your review > Date: October 28, 2025 at 9:50:41 AM PDT > To: [email protected] > Cc: "[email protected]" <[email protected]>, [email protected], > [email protected], [email protected], [email protected], > [email protected], [email protected], [email protected] > > Hi, Sabrina. Great! Thank you for the quick fix! > > Lynne Bartholomew > RFC Production Center >> From: Lynne Bartholomew <[email protected]> >> Subject: Re: [IANA #1434984] [IANA] Re: AUTH48: RFC-to-be 9864 >> <draft-ietf-jose-fully-specified-algorithms-13> for your review >> Date: October 28, 2025 at 9:04:21 AM PDT >> To: [email protected] >> Cc: "[email protected]" <[email protected]>, [email protected], >> [email protected], [email protected], [email protected], >> [email protected], [email protected], [email protected] >> >> 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 <[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 Oct 27, 2025, at 6:28 PM, Michael Jones <[email protected]> >> wrote: >> >> Thanks, Sabrina. Those updates are correct. >> >> We're now just waiting for the IANA approval at >> https://www.rfc-editor.org/auth48/rfc9864 before publication, correct Lynne? >> >> Thanks all! >> -- Mike >> >> -----Original Message----- >> From: Sabrina Tanamal via RT <[email protected]> >> Sent: Monday, October 27, 2025 2:27 PM >> To: [email protected] >> Cc: [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected] >> Subject: [IANA #1434984] [IANA] Re: AUTH48: RFC-to-be 9864 >> <draft-ietf-jose-fully-specified-algorithms-13> for your review >> >> 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, 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]" <[email protected]>, >>>>>>>>>>> "[email protected]" <[email protected]>, >>>>>>>>>>> "[email protected]" <[email protected]>, >>>>>>>>>>> "[email protected]" <[email protected]>, >>>>>>>>>>> "[email protected]" <[email protected]> >>>>>>>>>>> >>>>>>>>>>> One other point of clarification came up before AUTH48 that we >>>>>>>>>>> should make. These clarifications need to be applied in three >>>>>>>>>>> sections. >>>>>>>>>>> >>>>>>>>>>> In 2.2. Edwards-curve Digital Signature Algorithm (EdDSA): >>>>>>>>>>> >>>>>>>>>>> Old: >>>>>>>>>>> EdDSA using Ed25519 curve >>>>>>>>>>> New: >>>>>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC >>>>>>>>>>> 8032 >>>>>>>>>>> >>>>>>>>>>> Old: >>>>>>>>>>> EdDSA using Ed448 curve >>>>>>>>>>> New: >>>>>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032 >>>>>>>>>>> >>>>>>>>>>> In 4.1.1. Fully-Specified JOSE Algorithm Registrations: >>>>>>>>>>> >>>>>>>>>>> Old: >>>>>>>>>>> EdDSA using Ed25519 curve >>>>>>>>>>> New: >>>>>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC >>>>>>>>>>> 8032 >>>>>>>>>>> >>>>>>>>>>> Old: >>>>>>>>>>> EdDSA using Ed448 curve >>>>>>>>>>> New: >>>>>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032 >>>>>>>>>>> >>>>>>>>>>> In 4.2.1. Fully-Specified COSE Algorithm Registrations: >>>>>>>>>>> >>>>>>>>>>> Old: >>>>>>>>>>> EdDSA using Ed25519 curve >>>>>>>>>>> New: >>>>>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC >>>>>>>>>>> 8032 >>>>>>>>>>> >>>>>>>>>>> Old: >>>>>>>>>>> EdDSA using Ed448 curve >>>>>>>>>>> New: >>>>>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032 >>>>>>>>>>> >>>>>>>>>>> Thanks again, >>>>>>>>>>> -- Mike >>>>>>>>>> >>>>>>>>>>> On Oct 2, 2025, at 9:55 AM, Michael Jones >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> My replies are inline, prefixed by "Mike>". >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Michael Jones >>>>>>>>>>> Sent: Friday, September 26, 2025 4:32 PM >>>>>>>>>>> To: 'Lynne Bartholomew' <[email protected]> >>>>>>>>>>> Cc: '[email protected]' <[email protected]>; >>>>>>>>>>> Orie <[email protected]>; '[email protected]' <[email protected]>; >>>>>>>>>>> '[email protected]' <[email protected]>; >>>>>>>>>>> '[email protected]' <[email protected]>; >>>>>>>>>>> '[email protected]' <[email protected]>; >>>>>>>>>>> '[email protected]' <[email protected]> >>>>>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 <draft-ietf-jose-fully- >>>>>>>>>>> specified-algorithms-13> for your review >>>>>>>>>>> >>>>>>>>>>> Also, please update Orie's author information to: >>>>>>>>>>> >>>>>>>>>>> <author fullname="Orie Steele" initials="O." surname="Steele"> >>>>>>>>>>> <organization>Tradeverifyd</organization> >>>>>>>>>>> <address> >>>>>>>>>>> <email>[email protected]</email> >>>>>>>>>>> </address> >>>>>>>>>>> </author> >>>>>>>>>>> >>>>>>>>>>> That's what he asked for in https://github.com/ietf-wg- >>>>>>>>>>> jose/draft-ietf-jose-fully-specified-algorithms/pull/34. >>>>>>>>>>> (Yes, I realize that we're past the point of using the GitHub >>>>>>>>>>> repository anymore.) >>>>>>>>>>> >>>>>>>>>>> Thanks again, >>>>>>>>>>> -- Mike >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Michael Jones >>>>>>>>>>> Sent: Friday, September 26, 2025 7:24 AM >>>>>>>>>>> To: Lynne Bartholomew <[email protected]> >>>>>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>>>>> [email protected]; [email protected]; [email protected]; >>>>>>>>>>> [email protected]; [email protected] >>>>>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 <draft-ietf-jose-fully- >>>>>>>>>>> specified-algorithms-13> for your review >>>>>>>>>>> >>>>>>>>>>> Thanks, Lynne. That looks good. I'll respond to the rest of >>>>>>>>>>> the questions shortly - probably this weekend. >>>>>>>>>>> >>>>>>>>>>> Best wishes, >>>>>>>>>>> -- Mike >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lynne Bartholomew <[email protected]> >>>>>>>>>>> Sent: Wednesday, September 24, 2025 9:33 AM >>>>>>>>>>> To: Michael Jones <[email protected]> >>>>>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>>>>> [email protected]; [email protected]; [email protected]; >>>>>>>>>>> [email protected]; [email protected] >>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864 <draft-ietf-jose-fully- >>>>>>>>>>> specified-algorithms-13> for your review >>>>>>>>>>> >>>>>>>>>>> Hi, Mike. We've applied consistent hyphenation per your >>>>>>>>>>> request. >>>>>>>>>>> >>>>>>>>>>> Please note that we also hyphenated "fully specified >>>>>>>>>>> replacements", "fully specified digital signature algorithm >>>>>>>>>>> identifiers", "fully specified COSE ECDSA algorithms", "fully >>>>>>>>>>> specified encryption", etc., because "fully specified" also >>>>>>>>>>> acts as a modifier in these instances. >>>>>>>>>>> >>>>>>>>>>> The latest files are posted here. Please refresh your >>>>>>>>>>> browser: >>>>>>>>>>> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864.txt >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864.pdf >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864.xml >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864-diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side >>>>>>>>>>> by side) >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html >>>>>>>>>>> (side by side) >>>>>>>>>>> >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html >>>>>>>>>>> >>>>>>>>>>> Please review our updates carefully, and let us know if >>>>>>>>>>> anything is incorrect. >>>>>>>>>>> >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> Lynne Bartholomew >>>>>>>>>>> RFC Production Center >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Sep 20, 2025, at 1:40 PM, Michael Jones >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks for your input, Sandy. I've thought about it since >>>>>>>>>>>> receiving your note yesterday, and I'd be more comfortable if >>>>>>>>>>>> we restored the hyphens to the compound adjective uses. In >>>>>>>>>>>> particular, please change all instances of "fully specified >>>>>>>>>>>> algorithm" back to "fully-specified algorithm". >>>>>>>>>>>> >>>>>>>>>>>> Yes, CMOS permits the omission of the hyphen. But including >>>>>>>>>>>> the hyphen makes it sound like my writing, which I've decided >>>>>>>>>>>> is important to me. >>>>>>>>>>>> >>>>>>>>>>>> Thanks all! >>>>>>>>>>>> -- Mike >>>>>>>>>>>> >>>>>>>>>>>> P.S. I'll address the other AUTH48 questions shortly. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Sandy Ginoza <[email protected]> >>>>>>>>>>>> Sent: Friday, September 19, 2025 3:25 PM >>>>>>>>>>>> To: Michael Jones <[email protected]> >>>>>>>>>>>> Cc: RFC Editor <[email protected]>; >>>>>>>>>>>> [email protected]; >>>>>>>>>>>> Alice Russo <[email protected]>; [email protected]; >>>>>>>>>>>> [email protected]; [email protected]; >>>>>>>>>>>> [email protected]; >>>>>>>>>>>> [email protected] >>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864 >>>>>>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your >>>>>>>>>>>> review >>>>>>>>>>>> >>>>>>>>>>>> Hi Mike, >>>>>>>>>>>> >>>>>>>>>>>> Thank for trying to follow the guidance we previously sent! >>>>>>>>>>>> What you said is correct — compound adjectives are hyphenated >>>>>>>>>>>> when appearing before the noun. CMOS treats adverbs ending >>>>>>>>>>>> with -ly differently — that is, no hyphen whether appearing >>>>>>>>>>>> before or after the noun. We removed the hyphen from “fully >>>>>>>>>>>> qualified” for this reason. If you feel strongly about using >>>>>>>>>>>> the hyphen in this case, please let us know. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sandy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Sep 19, 2025, at 10:47 AM, Michael Jones >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the detailed work on this specification, Lynne >>>>>>>>>>>>> and Karen! Before responding to the rest of the feedback, I >>>>>>>>>>>>> wanted to get a broader set of opinions one change made, >>>>>>>>>>>>> including possibly from Sandy and Alice, who I’ve added to >>>>>>>>>>>>> the thread. >>>>>>>>>>>>> >>>>>>>>>>>>> Uses of the compound adjective "fully-specified" (typically >>>>>>>>>>>>> used in the context "fully-specified algorithms") were >>>>>>>>>>>>> changed to "fully specified". The rationale for this change >>>>>>>>>>>>> cited was as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> a) The following term was used inconsistently in this >>>>>>>>>>>>> document. >>>>>>>>>>>>> We chose to use the latter form. Please let us know any >>>>>>>>>>>>> objections. >>>>>>>>>>>>> >>>>>>>>>>>>> fully-specified / >>>>>>>>>>>>> fully specified (e.g., "are fully-specified", "are fully >>>>>>>>>>>>> specified", "fully specified RSA algorithms")* >>>>>>>>>>>>> >>>>>>>>>>>>> * Per the Chicago Manual of Style >>>>>>>>>>>>> ("Compounds formed by an adverb ending in ‑ly plus an >>>>>>>>>>>>> adjective or >>>>>>>>>>>>> participle (such as largely irrelevant or smartly dressed) >>>>>>>>>>>>> are not >>>>>>>>>>>>> hyphenated either before or after a noun, since ambiguity is >>>>>>>>>>>>> virtually impossible (a smartly dressed couple).") >>>>>>>>>>>>> >>>>>>>>>>>>> In previous interactions with the RFC Editor, I’d been told >>>>>>>>>>>>> that the normal convention was to hyphenate compound >>>>>>>>>>>>> adjectives qualifying a noun, such as “fully-specified >>>>>>>>>>>>> algorithms”, but to not hyphenate noun phrases, such as “The >>>>>>>>>>>>> algorithm is fully specified”. Therefore, I followed that >>>>>>>>>>>>> convention in the document. >>>>>>>>>>>>> >>>>>>>>>>>>> Not that this is authoritative, but a Bing search result for >>>>>>>>>>>>> “when to hyphenate words” opens with: >>>>>>>>>>>>> Here are some rules for when to hyphenate words: >>>>>>>>>>>>> • Compound Adjectives: Hyphenate two or more words when they >>>>>>>>>>>>> come before a noun and act as a single idea, such as "well- >>>>>>>>>>>>> written book". >>>>>>>>>>>>> • Modifiers: Use a hyphen when a compound modifier precedes >>>>>>>>>>>>> the noun it modifies, like "high-speed chase". >>>>>>>>>>>>> >>>>>>>>>>>>> This seems to support retaining the hyphenation when used as >>>>>>>>>>>>> a compound adjective. >>>>>>>>>>>>> >>>>>>>>>>>>> Personally, retaining the hyphenation in these contexts >>>>>>>>>>>>> seems more natural to me, the Chicago Manual of Style’s >>>>>>>>>>>>> suggestion notwithstanding. >>>>>>>>>>>>> >>>>>>>>>>>>> But I’d be curious what others think. I’ve added Sandy and >>>>>>>>>>>>> Alice to the thread in case they want to weigh in. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks all, >>>>>>>>>>>>> -- Mike >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: [email protected] <[email protected]> >>>>>>>>>>>>> Sent: Thursday, September 18, 2025 12:52 PM >>>>>>>>>>>>> To: [email protected]; [email protected] >>>>>>>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>>>>>>> [email protected]; [email protected]; >>>>>>>>>>>>> [email protected]; >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864 >>>>>>>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your >>>>>>>>>>>>> review >>>>>>>>>>> >>>>>>>>>>> Authors, >>>>>>>>>>> >>>>>>>>>>> While reviewing this document during AUTH48, please resolve >>>>>>>>>>> (as necessary) the following questions, which are also in the >>>>>>>>>>> source file. >>>>>>>>>>> >>>>>>>>>>> 1) <!-- [rfced] Please note that the document title has been >>>>>>>>>>> updated as follows. The abbreviations "JOSE” and "COSE" have >>>>>>>>>>> been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). >>>>>>>>>>> Please let us know any objections. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Fully-Specified Algorithms for JOSE and COSE >>>>>>>>>>> >>>>>>>>>>> Currently: >>>>>>>>>>> Fully Specified Algorithms for JSON Object Signing and >>>>>>>>>>> Encryption (JOSE) >>>>>>>>>>> and CBOR Object Signing and Encryption (COSE) --> >>>>>>>>>>> >>>>>>>>>>> Mike> The title in the current XML (using "Fully-Specified") >>>>>>>>>>> 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 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 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 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, 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]
