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]
