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]
