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 > > >>>> > > >>> > > >> > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
