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]
