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]; > > [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 > >>>>>> "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 > >>>>>> "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 as "The > >>>>>> following fully specified JOSE and COSE <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") 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 > >>>>>> "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 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 text wasn't > >>>>>> carried forward into the documents that 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 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 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-1_0.html > >>>>>> cannot be changed. Please update the reference to match the > >>>>>> referenced specification by removing the "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 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 signature" are > >>>>>> used in the COSE algorithms registry. Therefore, the current text is > >>>>>> consistent with the 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 as "The > >>>>>> following fully specified JOSE and COSE <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]
