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 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]
