Thanks, Sabrina. Those updates are correct.
We're now just waiting for the IANA approval at
https://www.rfc-editor.org/auth48/rfc9864 before publication, correct Lynne?
Thanks all!
-- Mike
-----Original Message-----
From: Sabrina Tanamal via RT <[email protected]>
Sent: Monday, October 27, 2025 2:27 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]
Subject: [IANA #1434984] [IANA] Re: AUTH48: RFC-to-be 9864
<draft-ietf-jose-fully-specified-algorithms-13> for your review
Hi Lynne,
These updates have been completed:
https://www.iana.org/assignments/jose
https://www.iana.org/assignments/cose
Please let me know if anything was missed.
Thank you,
Sabrina
On Thu Oct 23 16:22:25 2025, [email protected] wrote:
> Dear IANA,
>
> Per the author, please make the following updates on
> <https://www.iana.org/assignments/jose/>:
>
> OLD:
> Ed25519 EdDSA using Ed25519 curve
> Ed448 EdDSA using Ed448 curve
>
> NEW:
> Ed25519 EdDSA using the Ed25519 parameter set in Section 5.1 of
> [RFC8032]
> Ed448 EdDSA using the Ed448 parameter set in Section 5.2 of [RFC8032]
>
> ===============================
>
> Per the author (with apologies for anything that's misordered here as
> compared to the IANA page; we found the process of listing these
> updates very challenging), please make the following updates on
> <https://www.iana.org/assignments/cose/>:
>
> OLD:
> Reference
> [RFC9053][RFC9054][RFC-ietf-jose-fully-specified-algorithms-13,
> Section 4.3.1]
>
> NEW:
> Reference
> [RFC9053][RFC9054][RFC-ietf-jose-fully-specified-algorithms-13,
> Section 4.2]
> = = = = =
> OLD:
>
> ESB512 -268 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> ESB384 -267 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> ESB320 -266 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> ESB256 -265 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> Ed448 -53 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> ESP512 -52 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> ESP384 -51 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> Ed25519 -19 ... [RFC-ietf-jose-fully-specified-algorithms-13]
> ESP256 -9 ... [RFC-ietf-jose-fully-specified-algorithms-13]
>
> NEW:
>
> ESB512 -268 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.1
> ESB384 -267 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.1
> ESB320 -266 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.1
> ESB256 -265 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.1
> Ed448 -53 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.2
> ESP512 -52 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.1
> ESP384 -51 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.1
> Ed25519 -19 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.2
> ESP256 -9 ... [RFC-ietf-jose-fully-specified-algorithms-13], Section
> 2.1
>
> = = = = =
>
> OLD:
> Ed448 -53 EdDSA using Ed448 curve
> Ed25519 -19 EdDSA using Ed25519 curve
>
> NEW:
> Ed448 -53 EdDSA using the Ed448 parameter set in Section 5.2 of
> [RFC8032]
> Ed25519 -19 EdDSA using the Ed25519 parameter set in Section 5.1 of
> [RFC8032]
>
> = = = = =
>
> Please also add "IETF" in the "Change Controller" column for the ES512
> entry:
> OLD:
> ES512 -36 ... [kty] [RFC9053][RFC-ietf-jose-fully-specified-
> algorithms-13]
>
> NEW:
> ES512 -36 ... [kty] IETF [RFC9053][RFC-ietf-jose-fully-specified-
> algorithms-13]
>
> Thank you!
>
> Lynne Bartholomew
> RFC Production Center
>
> > On Oct 23, 2025, at 9:10 AM, Lynne Bartholomew
> > <[email protected]> wrote:
> >
> > Hi, Deb. Thank you for the quick reply! So noted:
> >
> > https://www.rfc-editor.org/auth48/rfc9864
> >
> > We will send the IANA email shortly.
> >
> > Thanks again!
> >
> > Lynne Bartholomew
> > RFC Production Center
> >
> >> On Oct 23, 2025, at 9:04 AM, Deb Cooley <[email protected]>
> >> wrote:
> >>
> >> I approve.
> >>
> >> Deb
> >>
> >> On Thu, Oct 23, 2025 at 11:40 AM Lynne Bartholomew
> >> <[email protected]> wrote:
> >> Hi, Mike and *Deb.
> >>
> >> Mike, thank you for the updated XML file!
> >>
> >> * Deb, please let us know if you approve the change from "must" to
> >> "MUST" in Section 3, Paragraph 6.
> >>
> >> Mike, after we receive AD approval, we will ask IANA to make the
> >> necessary updates. After the IANA updates are complete, we will
> >> prepare this document for publication.
> >>
> >> In the meantime, we have noted your approval on the AUTH48 status
> >> page:
> >>
> >> https://www.rfc-editor.org/auth48/rfc9864
> >>
> >> The latest files are posted here. Please refresh your browser:
> >>
> >> https://www.rfc-editor.org/authors/rfc9864.txt
> >> https://www.rfc-editor.org/authors/rfc9864.pdf
> >> https://www.rfc-editor.org/authors/rfc9864.html
> >> https://www.rfc-editor.org/authors/rfc9864.xml
> >> https://www.rfc-editor.org/authors/rfc9864-diff.html
> >> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side by
> >> side)
> >> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html
> >> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html (side
> >> by side)
> >> https://www.rfc-editor.org/authors/rfc9864-lastdiff.html
> >> https://www.rfc-editor.org/authors/rfc9864-lastrfcdiff.html (side by
> >> side)
> >>
> >> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html
> >> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html
> >>
> >> Thanks again!
> >>
> >> Lynne Bartholomew
> >> RFC Production Center
> >>
> >>
> >>> On Oct 22, 2025, at 5:13 PM, Michael Jones
> >>> <[email protected]> wrote:
> >>>
> >>> The attached source contains three requested changes relative to
> >>> the latest version. They are:
> >>>
> >>> diff "rfc9864.xml~" rfc9864.xml
> >>> 86c86
> >>> < Examples are the <tt>Edwards-curve Digital Signature
> >>> Algorithm (EdDSA)</tt>
> >>> ---
> >>>> Examples are the Edwards-curve Digital Signature Algorithm (EdDSA)
> >>> 238c238
> >>> < The following fully-specified JOSE and COSE
> >>> <tt>EdDSA</tt> algorithms are defined by this specification:
> >>> ---
> >>>> The following fully-specified JOSE and COSE EdDSA algorithms are
> >>>> defined by this specification:
> >>> 323c323
> >>> < the inner "alg" value must specify all parameters for
> >>> symmetric encryption.
> >>> ---
> >>>> the inner "alg" value <bcp14>MUST</bcp14> specify all parameters
> >>>> for symmetric encryption.
> >>>
> >>> For the first two changes, EdDSA should only be in <tt>...</tt>
> >>> when it is an algorithm identifier - not when it is a designator
> >>> for the Edwards-curve Digital Signature Algorithm (EdDSA) signature
> >>> method.
> >>>
> >>> For the third change, it makes the spec consistent in its use of
> >>> MUST within that sentence.
> >>>
> >>> I have reviewed all other changes and agree with them, including
> >>> all the hyphenation decisions. Once my three changes above are
> >>> incorporated, please mark the document approval status for me as
> >>> Yes at https://www.rfc-editor.org/auth48/rfc9864.
> >>>
> >>> Are the next steps to update the IANA registration text that was
> >>> changed?
> >>>
> >>> Thanks all,
> >>> -- Mike
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Lynne Bartholomew <[email protected]>
> >>> Sent: Wednesday, October 22, 2025 8:26 AM
> >>> To: Deb Cooley <[email protected]>
> >>> Cc: Orie <[email protected]>; [email protected]; Michael Jones
> >>> <[email protected]>; [email protected]; jose-
> >>> [email protected]; [email protected]; [email protected]
> >>> Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9864 <draft-ietf-jose-
> >>> fully-specified-algorithms-13> for your review
> >>>
> >>> Hi, Deb. Thanks for the quick reply! We have noted your approval:
> >>>
> >>> https://www.rfc-editor.org/auth48/rfc9864
> >>>
> >>> Regarding your note about hyphenation: We sent the follow-up
> >>> question below to Mike on 6 Oct. We're still waiting for his reply
> >>> (forgot to ping him in yesterday's 11:55 AM email).
> >>>
> >>>>>>>>> 2) <!-- [rfced] Section 2.1: Because it appears that "full-
> >>>>>>>>> specified"
> >>>>>>>>> means "fully specified", we updated this text accordingly.
> >>>>>>>>> If this is incorrect, please let us know what "full-
> >>>>>>>>> specified" means (possibly "specified in full"?).
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are
> >>>>>>>>> full-specified.)
> >>>>>>>>>
> >>>>>>>>> Currently:
> >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are fully
> >>>>>>>>> specified.) -->
> >>>>>>>>>
> >>>>>>>> Mike> This has already been addressed by returning to using
> >>>>>>>> Mike> "fully-specified", etc.
> >>>>>>>
> >>>>>>> We only hyphenated where "fully specified" is used as a
> >>>>>>> modifier. For example, the text still shows "are fully
> >>>>>>> specified. ...". There are currently 12 instances of "fully
> >>>>>>> specified" (no hyphen). Should we hyphenate all of these as
> >>>>>>> well?
> >>>
> >>> Thanks again!
> >>>
> >>> Lynne Bartholomew
> >>> RFC Production Center
> >>>
> >>>> On Oct 21, 2025, at 3:15 PM, Deb Cooley <[email protected]>
> >>>> wrote:
> >>>>
> >>>> The tables are fine. I approve.
> >>>>
> >>>> What I did notice is that there is a mix of 'fully specified' and
> >>>> 'fully-specified' throughout the draft. If that is 'by design',
> >>>> then I'm fine with it. If it is not by design, then I suggest
> >>>> that we pick one and stick with it.
> >>>>
> >>>> Deb
> >>>>
> >>>> On Tue, Oct 21, 2025 at 11:55 AM Lynne Bartholomew
> >>>> <[email protected]> wrote:
> >>>> Hi, Orie and *AD (Deb or Paul).
> >>>>
> >>>> * Deb or Paul, please review the updates to Table 2, Section
> >>>> 4.1.1, and Section 4.2.1, and let us know if you approve. (We're
> >>>> not sure if these updates could be considered "beyond editorial".)
> >>>>
> >>>> Orie, as it appears that you approve this document for publication
> >>>> in its current form, we have noted your approval on the AUTH48
> >>>> status page. Please let us know if we noted your approval in
> >>>> error:
> >>>>
> >>>> https://www.rfc-editor.org/auth48/rfc9864
> >>>>
> >>>> Thank you!
> >>>>
> >>>> Lynne Bartholomew
> >>>> RFC Production Center
> >>>>
> >>>>> On Oct 20, 2025, at 1:39 PM, Orie <[email protected]> wrote:
> >>>>>
> >>>>> I reviewed the diffs. These look good to me.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> OS
> >>>>>
> >>>>> On Mon, Oct 20, 2025 at 10:08 AM Lynne Bartholomew
> >>>>> <[email protected]> wrote:
> >>>>> Hi, Mike and Orie.
> >>>>>
> >>>>> Mike, we do not believe we have heard from you regarding our 6
> >>>>> Oct. email below. Please review, and let us know if further
> >>>>> changes are needed.
> >>>>>
> >>>>> Orie, please review the updated files, and let us know if you
> >>>>> would like to make any changes. Please refresh your browser to
> >>>>> view the latest:
> >>>>>
> >>>>> https://www.rfc-editor.org/authors/rfc9864.txt
> >>>>> https://www.rfc-editor.org/authors/rfc9864.pdf
> >>>>> https://www.rfc-editor.org/authors/rfc9864.html
> >>>>> https://www.rfc-editor.org/authors/rfc9864.xml
> >>>>> https://www.rfc-editor.org/authors/rfc9864-diff.html
> >>>>> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side by
> >>>>> side)
> >>>>> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html
> >>>>> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html
> >>>>> (side by side)
> >>>>> https://www.rfc-editor.org/authors/rfc9864-lastdiff.html
> >>>>> https://www.rfc-editor.org/authors/rfc9864-lastrfcdiff.html (side
> >>>>> by side)
> >>>>>
> >>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html
> >>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html
> >>>>>
> >>>>> Thank you!
> >>>>>
> >>>>> Lynne Bartholomew
> >>>>> RFC Production Center
> >>>>>
> >>>>>> On Oct 6, 2025, at 11:08 AM, Lynne Bartholomew
> >>>>>> <[email protected]> wrote:
> >>>>>>
> >>>>>> Forgot to mention that we are keeping track of the IANA updates
> >>>>>> that we will need to request just prior to publication.
> >>>>>>
> >>>>>>> On Oct 6, 2025, at 11:05 AM, Lynne Bartholomew
> >>>>>>> <[email protected]> wrote:
> >>>>>>>
> >>>>>>> Hi, Mike. Thank you for your replies to our questions.
> >>>>>>>
> >>>>>>> Regarding this question and your reply:
> >>>>>>>
> >>>>>>>>> 2) <!-- [rfced] Section 2.1: Because it appears that "full-
> >>>>>>>>> specified"
> >>>>>>>>> means "fully specified", we updated this text accordingly.
> >>>>>>>>> If this is incorrect, please let us know what "full-
> >>>>>>>>> specified" means (possibly "specified in full"?).
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are
> >>>>>>>>> full-specified.)
> >>>>>>>>>
> >>>>>>>>> Currently:
> >>>>>>>>> (The corresponding JOSE registrations in [RFC7518] are fully
> >>>>>>>>> specified.) -->
> >>>>>>>>>
> >>>>>>>> Mike> This has already been addressed by returning to using
> >>>>>>>> Mike> "fully-specified", etc.
> >>>>>>>
> >>>>>>> We only hyphenated where "fully specified" is used as a
> >>>>>>> modifier. For example, the text still shows "are fully
> >>>>>>> specified. ...". There are currently 12 instances of "fully
> >>>>>>> specified" (no hyphen). Should we hyphenate all of these as
> >>>>>>> well?
> >>>>>>>
> >>>>>>> = = = = =
> >>>>>>>
> >>>>>>> Regarding question 14)b) and your reply:
> >>>>>>>
> >>>>>>>>> alg value (2 instances) / "alg" value (7 instances)
> >>>>>>>>
> >>>>>>>> Mike> Let's use "alg" value.
> >>>>>>>
> >>>>>>>
> >>>>>>> We also changed 'alg numbers' to '"alg" numbers'; although
> >>>>>>> [FIDO2] doesn't use the word "number", we see that "alg" is
> >>>>>>> quoted everywhere. Please let us know if we should revert this
> >>>>>>> change.
> >>>>>>>
> >>>>>>> = = = = =
> >>>>>>>
> >>>>>>> Regarding question 14)c) and your reply:
> >>>>>>>
> >>>>>>>>> c) The following terms appear both with and without <tt> in
> >>>>>>>>> the XML file. Please review, and let us know if the current
> >>>>>>>>> applications of <tt> are correct and consistent.
> >>>>>>>>>
> >>>>>>>>> <tt>Ed25519</tt> (no <tt>s in IANA Considerations section)
> >>>>>>>>> <tt>Ed448</tt> (no <tt>s in IANA Considerations section)
> >>>>>>>>> <tt>EdDSA</tt> usage of <tt> appears to be inconsistent
> >>>>>>>>> (e.g., in
> >>>>>>>>> the XML file, we see
> >>>>>>>>> "This redefines the COSE <tt>EdDSA</tt> algorithm identifier"
> >>>>>>>>> and
> >>>>>>>>> "The following fully specified JOSE and COSE EdDSA
> >>>>>>>>> algorithms" -->
> >>>>>>>>
> >>>>>>>> Mike> Please add <tt> where missing for algorithm names, such
> >>>>>>>> Mike> as "The following fully specified JOSE and COSE
> >>>>>>>> Mike> <tt>EdDSA</tt> algorithms"
> >>>>>>>
> >>>>>>>
> >>>>>>> We're not sure that we understood your request correctly. We
> >>>>>>> updated the example sentence that you listed but are not sure
> >>>>>>> if any other sentences need to be updated. Please review. If
> >>>>>>> further changes are needed, please specify via "Old" and "New"
> >>>>>>> text where we should make additional updates.
> >>>>>>>
> >>>>>>> = = = = =
> >>>>>>>
> >>>>>>> We have also incorporated the updates that you sent on Friday
> >>>>>>> (3 Oct.).
> >>>>>>>
> >>>>>>> The latest files are posted here. Please refresh your browser:
> >>>>>>>
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864.txt
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864.pdf
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864.xml
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-diff.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side
> >>>>>>> by side)
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html
> >>>>>>> (side by side)
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-lastdiff.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-lastrfcdiff.html
> >>>>>>> (side by side)
> >>>>>>>
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html
> >>>>>>>
> >>>>>>> Thanks again!
> >>>>>>>
> >>>>>>> Lynne Bartholomew
> >>>>>>> RFC Production Center
> >>>>>>>
> >>>>>>>
> >>>>>>>> From: Michael Jones <[email protected]>
> >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 <draft-ietf-jose-fully-
> >>>>>>>> specified-algorithms-13> for your review
> >>>>>>>> Date: October 3, 2025 at 3:52:59 AM PDT
> >>>>>>>> To: Lynne Bartholomew <[email protected]>
> >>>>>>>> Cc: "[email protected]" <[email protected]>,
> >>>>>>>> Orie <[email protected]>, "[email protected]" <[email protected]>,
> >>>>>>>> "[email protected]" <[email protected]>,
> >>>>>>>> "[email protected]" <[email protected]>,
> >>>>>>>> "[email protected]" <[email protected]>,
> >>>>>>>> "[email protected]" <[email protected]>
> >>>>>>>>
> >>>>>>>> One other point of clarification came up before AUTH48 that we
> >>>>>>>> should make. These clarifications need to be applied in three
> >>>>>>>> sections.
> >>>>>>>>
> >>>>>>>> In 2.2. Edwards-curve Digital Signature Algorithm (EdDSA):
> >>>>>>>>
> >>>>>>>> Old:
> >>>>>>>> EdDSA using Ed25519 curve
> >>>>>>>> New:
> >>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC
> >>>>>>>> 8032
> >>>>>>>>
> >>>>>>>> Old:
> >>>>>>>> EdDSA using Ed448 curve
> >>>>>>>> New:
> >>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032
> >>>>>>>>
> >>>>>>>> In 4.1.1. Fully-Specified JOSE Algorithm Registrations:
> >>>>>>>>
> >>>>>>>> Old:
> >>>>>>>> EdDSA using Ed25519 curve
> >>>>>>>> New:
> >>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC
> >>>>>>>> 8032
> >>>>>>>>
> >>>>>>>> Old:
> >>>>>>>> EdDSA using Ed448 curve
> >>>>>>>> New:
> >>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032
> >>>>>>>>
> >>>>>>>> In 4.2.1. Fully-Specified COSE Algorithm Registrations:
> >>>>>>>>
> >>>>>>>> Old:
> >>>>>>>> EdDSA using Ed25519 curve
> >>>>>>>> New:
> >>>>>>>> EdDSA using the Ed25519 parameter set in Section 5.1 of RFC
> >>>>>>>> 8032
> >>>>>>>>
> >>>>>>>> Old:
> >>>>>>>> EdDSA using Ed448 curve
> >>>>>>>> New:
> >>>>>>>> EdDSA using the Ed448 parameter set in Section 5.2 of RFC 8032
> >>>>>>>>
> >>>>>>>> Thanks again,
> >>>>>>>> -- Mike
> >>>>>>>
> >>>>>>>> On Oct 2, 2025, at 9:55 AM, Michael Jones
> >>>>>>>> <[email protected]> wrote:
> >>>>>>>>
> >>>>>>>> My replies are inline, prefixed by "Mike>".
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Michael Jones
> >>>>>>>> Sent: Friday, September 26, 2025 4:32 PM
> >>>>>>>> To: 'Lynne Bartholomew' <[email protected]>
> >>>>>>>> Cc: '[email protected]' <[email protected]>;
> >>>>>>>> Orie <[email protected]>; '[email protected]' <[email protected]>;
> >>>>>>>> '[email protected]' <[email protected]>;
> >>>>>>>> '[email protected]' <[email protected]>;
> >>>>>>>> '[email protected]' <[email protected]>;
> >>>>>>>> '[email protected]' <[email protected]>
> >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 <draft-ietf-jose-fully-
> >>>>>>>> specified-algorithms-13> for your review
> >>>>>>>>
> >>>>>>>> Also, please update Orie's author information to:
> >>>>>>>>
> >>>>>>>> <author fullname="Orie Steele" initials="O." surname="Steele">
> >>>>>>>> <organization>Tradeverifyd</organization>
> >>>>>>>> <address>
> >>>>>>>> <email>[email protected]</email>
> >>>>>>>> </address>
> >>>>>>>> </author>
> >>>>>>>>
> >>>>>>>> That's what he asked for in https://github.com/ietf-wg-
> >>>>>>>> jose/draft-ietf-jose-fully-specified-algorithms/pull/34.
> >>>>>>>> (Yes, I realize that we're past the point of using the GitHub
> >>>>>>>> repository anymore.)
> >>>>>>>>
> >>>>>>>> Thanks again,
> >>>>>>>> -- Mike
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Michael Jones
> >>>>>>>> Sent: Friday, September 26, 2025 7:24 AM
> >>>>>>>> To: Lynne Bartholomew <[email protected]>
> >>>>>>>> Cc: [email protected]; [email protected];
> >>>>>>>> [email protected]; [email protected]; [email protected];
> >>>>>>>> [email protected]; [email protected]
> >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9864 <draft-ietf-jose-fully-
> >>>>>>>> specified-algorithms-13> for your review
> >>>>>>>>
> >>>>>>>> Thanks, Lynne. That looks good. I'll respond to the rest of
> >>>>>>>> the questions shortly - probably this weekend.
> >>>>>>>>
> >>>>>>>> Best wishes,
> >>>>>>>> -- Mike
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Lynne Bartholomew <[email protected]>
> >>>>>>>> Sent: Wednesday, September 24, 2025 9:33 AM
> >>>>>>>> To: Michael Jones <[email protected]>
> >>>>>>>> Cc: [email protected]; [email protected];
> >>>>>>>> [email protected]; [email protected]; [email protected];
> >>>>>>>> [email protected]; [email protected]
> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864 <draft-ietf-jose-fully-
> >>>>>>>> specified-algorithms-13> for your review
> >>>>>>>>
> >>>>>>>> Hi, Mike. We've applied consistent hyphenation per your
> >>>>>>>> request.
> >>>>>>>>
> >>>>>>>> Please note that we also hyphenated "fully specified
> >>>>>>>> replacements", "fully specified digital signature algorithm
> >>>>>>>> identifiers", "fully specified COSE ECDSA algorithms", "fully
> >>>>>>>> specified encryption", etc., because "fully specified" also
> >>>>>>>> acts as a modifier in these instances.
> >>>>>>>>
> >>>>>>>> The latest files are posted here. Please refresh your
> >>>>>>>> browser:
> >>>>>>>>
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.txt
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.pdf
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.html
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864.xml
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-diff.html
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side
> >>>>>>>> by side)
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48diff.html
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-auth48rfcdiff.html
> >>>>>>>> (side by side)
> >>>>>>>>
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9864-xmldiff2.html
> >>>>>>>>
> >>>>>>>> Please review our updates carefully, and let us know if
> >>>>>>>> anything is incorrect.
> >>>>>>>>
> >>>>>>>> Thank you!
> >>>>>>>>
> >>>>>>>> Lynne Bartholomew
> >>>>>>>> RFC Production Center
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Sep 20, 2025, at 1:40 PM, Michael Jones
> >>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>
> >>>>>>>>> Thanks for your input, Sandy. I've thought about it since
> >>>>>>>>> receiving your note yesterday, and I'd be more comfortable if
> >>>>>>>>> we restored the hyphens to the compound adjective uses. In
> >>>>>>>>> particular, please change all instances of "fully specified
> >>>>>>>>> algorithm" back to "fully-specified algorithm".
> >>>>>>>>>
> >>>>>>>>> Yes, CMOS permits the omission of the hyphen. But including
> >>>>>>>>> the hyphen makes it sound like my writing, which I've decided
> >>>>>>>>> is important to me.
> >>>>>>>>>
> >>>>>>>>> Thanks all!
> >>>>>>>>> -- Mike
> >>>>>>>>>
> >>>>>>>>> P.S. I'll address the other AUTH48 questions shortly.
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Sandy Ginoza <[email protected]>
> >>>>>>>>> Sent: Friday, September 19, 2025 3:25 PM
> >>>>>>>>> To: Michael Jones <[email protected]>
> >>>>>>>>> Cc: RFC Editor <[email protected]>;
> >>>>>>>>> [email protected];
> >>>>>>>>> Alice Russo <[email protected]>; [email protected];
> >>>>>>>>> [email protected]; [email protected];
> >>>>>>>>> [email protected];
> >>>>>>>>> [email protected]
> >>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864
> >>>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your
> >>>>>>>>> review
> >>>>>>>>>
> >>>>>>>>> Hi Mike,
> >>>>>>>>>
> >>>>>>>>> Thank for trying to follow the guidance we previously sent!
> >>>>>>>>> What you said is correct — compound adjectives are hyphenated
> >>>>>>>>> when appearing before the noun. CMOS treats adverbs ending
> >>>>>>>>> with -ly differently — that is, no hyphen whether appearing
> >>>>>>>>> before or after the noun. We removed the hyphen from “fully
> >>>>>>>>> qualified” for this reason. If you feel strongly about using
> >>>>>>>>> the hyphen in this case, please let us know.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Sandy
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Sep 19, 2025, at 10:47 AM, Michael Jones
> >>>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Thanks for the detailed work on this specification, Lynne
> >>>>>>>>>> and Karen! Before responding to the rest of the feedback, I
> >>>>>>>>>> wanted to get a broader set of opinions one change made,
> >>>>>>>>>> including possibly from Sandy and Alice, who I’ve added to
> >>>>>>>>>> the thread.
> >>>>>>>>>>
> >>>>>>>>>> Uses of the compound adjective "fully-specified" (typically
> >>>>>>>>>> used in the context "fully-specified algorithms") were
> >>>>>>>>>> changed to "fully specified". The rationale for this change
> >>>>>>>>>> cited was as follows:
> >>>>>>>>>>
> >>>>>>>>>> a) The following term was used inconsistently in this
> >>>>>>>>>> document.
> >>>>>>>>>> We chose to use the latter form. Please let us know any
> >>>>>>>>>> objections.
> >>>>>>>>>>
> >>>>>>>>>> fully-specified /
> >>>>>>>>>> fully specified (e.g., "are fully-specified", "are fully
> >>>>>>>>>> specified", "fully specified RSA algorithms")*
> >>>>>>>>>>
> >>>>>>>>>> * Per the Chicago Manual of Style
> >>>>>>>>>> ("Compounds formed by an adverb ending in ‑ly plus an
> >>>>>>>>>> adjective or
> >>>>>>>>>> participle (such as largely irrelevant or smartly dressed)
> >>>>>>>>>> are not
> >>>>>>>>>> hyphenated either before or after a noun, since ambiguity is
> >>>>>>>>>> virtually impossible (a smartly dressed couple).")
> >>>>>>>>>>
> >>>>>>>>>> In previous interactions with the RFC Editor, I’d been told
> >>>>>>>>>> that the normal convention was to hyphenate compound
> >>>>>>>>>> adjectives qualifying a noun, such as “fully-specified
> >>>>>>>>>> algorithms”, but to not hyphenate noun phrases, such as “The
> >>>>>>>>>> algorithm is fully specified”. Therefore, I followed that
> >>>>>>>>>> convention in the document.
> >>>>>>>>>>
> >>>>>>>>>> Not that this is authoritative, but a Bing search result for
> >>>>>>>>>> “when to hyphenate words” opens with:
> >>>>>>>>>> Here are some rules for when to hyphenate words:
> >>>>>>>>>> • Compound Adjectives: Hyphenate two or more words when they
> >>>>>>>>>> come before a noun and act as a single idea, such as "well-
> >>>>>>>>>> written book".
> >>>>>>>>>> • Modifiers: Use a hyphen when a compound modifier precedes
> >>>>>>>>>> the noun it modifies, like "high-speed chase".
> >>>>>>>>>>
> >>>>>>>>>> This seems to support retaining the hyphenation when used as
> >>>>>>>>>> a compound adjective.
> >>>>>>>>>>
> >>>>>>>>>> Personally, retaining the hyphenation in these contexts
> >>>>>>>>>> seems more natural to me, the Chicago Manual of Style’s
> >>>>>>>>>> suggestion notwithstanding.
> >>>>>>>>>>
> >>>>>>>>>> But I’d be curious what others think. I’ve added Sandy and
> >>>>>>>>>> Alice to the thread in case they want to weigh in.
> >>>>>>>>>>
> >>>>>>>>>> Thanks all,
> >>>>>>>>>> -- Mike
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: [email protected] <[email protected]>
> >>>>>>>>>> Sent: Thursday, September 18, 2025 12:52 PM
> >>>>>>>>>> To: [email protected]; [email protected]
> >>>>>>>>>> Cc: [email protected]; [email protected];
> >>>>>>>>>> [email protected]; [email protected];
> >>>>>>>>>> [email protected];
> >>>>>>>>>> [email protected]
> >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9864
> >>>>>>>>>> <draft-ietf-jose-fully-specified-algorithms-13> for your
> >>>>>>>>>> review
> >>>>>>>>
> >>>>>>>> Authors,
> >>>>>>>>
> >>>>>>>> While reviewing this document during AUTH48, please resolve
> >>>>>>>> (as necessary) the following questions, which are also in the
> >>>>>>>> source file.
> >>>>>>>>
> >>>>>>>> 1) <!-- [rfced] Please note that the document title has been
> >>>>>>>> updated as follows. The abbreviations "JOSE” and "COSE" have
> >>>>>>>> been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide").
> >>>>>>>> Please let us know any objections.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Fully-Specified Algorithms for JOSE and COSE
> >>>>>>>>
> >>>>>>>> Currently:
> >>>>>>>> Fully Specified Algorithms for JSON Object Signing and
> >>>>>>>> Encryption (JOSE)
> >>>>>>>> and CBOR Object Signing and Encryption (COSE) -->
> >>>>>>>>
> >>>>>>>> Mike> The title in the current XML (using "Fully-Specified")
> >>>>>>>> Mike> is appropriate.
> >>>>>>>>
> >>>>>>>> 2) <!-- [rfced] Section 2.1: Because it appears that "full-
> >>>>>>>> specified"
> >>>>>>>> means "fully specified", we updated this text accordingly. If
> >>>>>>>> this is incorrect, please let us know what "full-specified"
> >>>>>>>> means (possibly "specified in full"?).
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> (The corresponding JOSE registrations in [RFC7518] are
> >>>>>>>> full-specified.)
> >>>>>>>>
> >>>>>>>> Currently:
> >>>>>>>> (The corresponding JOSE registrations in [RFC7518] are fully
> >>>>>>>> specified.) -->
> >>>>>>>>
> >>>>>>>> Mike> This has already been addressed by returning to using
> >>>>>>>> Mike> "fully-specified", etc.
> >>>>>>>>
> >>>>>>>> 3) <!-- [rfced] Section 3: We see "COSE_Encrypt" but not
> >>>>>>>> "COSE Encrypt"
> >>>>>>>> in RFC 9052, and we do not see "COSE Encrypt" or
> >>>>>>>> "COSE_Encrypt" in RFC 9053. Please let us know how/if this
> >>>>>>>> sentence should be updated so that it is clear to readers.
> >>>>>>>> For example, we see "using COSE_Encrypt, as specified in
> >>>>>>>> Section 5.1 of [RFC9052]" later in this section.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> This section describes the construction of fully-specified
> >>>>>>>> encryption algorithm identifiers in the context of the JOSE
> >>>>>>>> and COSE encryption schemes JSON Web Encryption (JWE), as
> >>>>>>>> described in [RFC7516] and [RFC7518], and COSE Encrypt, as
> >>>>>>>> described in [RFC9052] and [RFC9053]. -->
> >>>>>>>>
> >>>>>>>> Mike> Let's change "COSE Encrypt" to "COSE encryption".
> >>>>>>>>
> >>>>>>>> New:
> >>>>>>>> This section describes the construction of fully-specified
> >>>>>>>> encryption algorithm identifiers in the context of the JOSE
> >>>>>>>> and COSE encryption schemes
> >>>>>>>> JSON Web Encryption (JWE), as described in <xref
> >>>>>>>> target="RFC7516"/> and <xref target="RFC7518"/>, and
> >>>>>>>> COSE encryption, as described in <xref target="RFC9052"/>
> >>>>>>>> and <xref target="RFC9053"/>.
> >>>>>>>>
> >>>>>>>> 4) <!-- [rfced] Section 3: Please confirm that "must specify"
> >>>>>>>> in this sentence shouldn't be "MUST specify".
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> To perform fully-specified encryption in COSE, the outer "alg"
> >>>>>>>> value MUST specify all parameters for key establishment and
> >>>>>>>> the inner "alg"
> >>>>>>>> value must specify all parameters for symmetric encryption.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>> Mike> The original text with "MUST specify" is fine.
> >>>>>>>>
> >>>>>>>> 5) <!-- [rfced] Section 3.1: "as are the key wrapping with
> >>>>>>>> AES GCM algorithms" reads oddly. Should "key wrapping with
> >>>>>>>> AES GCM" be placed in quotes, per the quoted algorithm types
> >>>>>>>> in the next paragraph?
> >>>>>>>>
> >>>>>>>> We have the same question for "The JOSE Key Encryption with
> >>>>>>>> PBES2 algorithms" two paragraphs later.
> >>>>>>>>
> >>>>>>>> Original (all three paragraphs included for context):
> >>>>>>>> In both JOSE and COSE, all registered key wrapping algorithms
> >>>>>>>> are fully specified, as are the key wrapping with AES GCM
> >>>>>>>> algorithms. An example of a fully-specified key wrapping
> >>>>>>>> algorithm is "A128KW" (AES Key Wrap using 128-bit key).
> >>>>>>>>
> >>>>>>>> The JOSE "dir" and COSE "direct" algorithms are fully
> >>>>>>>> specified. The COSE direct+HKDF algorithms are fully
> >>>>>>>> specified.
> >>>>>>>>
> >>>>>>>> The JOSE Key Encryption with PBES2 algorithms are fully
> >>>>>>>> specified. -->
> >>>>>>>>
> >>>>>>>> Mike> Let's change
> >>>>>>>> "the key wrapping with AES GCM algorithms"
> >>>>>>>> to
> >>>>>>>> "the algorithms performing key wrapping using AES GCM"
> >>>>>>>>
> >>>>>>>> Mike> Let's change
> >>>>>>>> "The JOSE Key Encryption with PBES2 algorithms are fully
> >>>>>>>> specified."
> >>>>>>>> to
> >>>>>>>> "The JOSE algorithms performing Key Encryption with PBES2 are
> >>>>>>>> fully specified."
> >>>>>>>>
> >>>>>>>> 6) <!-- [rfced] We have included some specific questions about
> >>>>>>>> the IANA text below. In addition to responding to those
> >>>>>>>> questions, please review all of the IANA-related updates
> >>>>>>>> carefully and let us know if any further updates are needed.
> >>>>>>>>
> >>>>>>>> "JSON Web Signature and Encryption Algorithms" registry:
> >>>>>>>> https://www.iana.org/assignments/jose
> >>>>>>>>
> >>>>>>>> "COSE Algorithms" registry:
> >>>>>>>> https://www.iana.org/assignments/cose
> >>>>>>>>
> >>>>>>>> a) Section 4.1: As the "JSON Web Signature and Encryption
> >>>>>>>> Algorithms"
> >>>>>>>> registry was established by RFC 7518, we have replaced RFC
> >>>>>>>> 7515 with RFC 7518 as shown below. We have also removed RFC
> >>>>>>>> 7515 from the normative references section as it was only
> >>>>>>>> mentioned in Section 4.1.
> >>>>>>>> Note that RFC 7518 is listed as an informative reference;
> >>>>>>>> please let us know if this is okay as is or if it should be
> >>>>>>>> normative.
> >>>>>>>>
> >>>>>>>> We also included that this document was listed as an
> >>>>>>>> additional reference for the registry at the end of the
> >>>>>>>> sentence below (and have removed the related text from Section
> >>>>>>>> 4.3, which describes the updates to the review instructions
> >>>>>>>> for the DEs).
> >>>>>>>> Note that a similar change was made to Section 4.2 for the
> >>>>>>>> "COSE Algorithms" registry, as shown below.
> >>>>>>>>
> >>>>>>>> Please review and let us know of any objections.
> >>>>>>>>
> >>>>>>>> Original (Section 4.1):
> >>>>>>>> This section registers the following values in the IANA "JSON
> >>>>>>>> Web Signature and Encryption Algorithms" registry [IANA.JOSE]
> >>>>>>>> established by [RFC7515].
> >>>>>>>>
> >>>>>>>> Currently:
> >>>>>>>> IANA has registered the values in this section in the "JSON
> >>>>>>>> Web Signature and Encryption Algorithms" registry [IANA.JOSE]
> >>>>>>>> established by [RFC7518] and has listed this document as an
> >>>>>>>> additional reference for the registry.
> >>>>>>>>
> >>>>>>>> ...
> >>>>>>>> Original (Section 4.2):
> >>>>>>>> This section registers the following values in the IANA "COSE
> >>>>>>>> Algorithms" registry [IANA.COSE].
> >>>>>>>>
> >>>>>>>> Currently:
> >>>>>>>> IANA has registered the following values in the "COSE
> >>>>>>>> Algorithms"
> >>>>>>>> registry [IANA.COSE] established by [RFC9053] and [RFC9054]
> >>>>>>>> and has added this document as an additional reference for the
> >>>>>>>> registry.
> >>>>>>>>
> >>>>>>>> Mike> I agree with both of those changes.
> >>>>>>>>
> >>>>>>>> b) Per the changes noted in a) above, we will ask IANA to
> >>>>>>>> update the reference for the "COSE Algorithms" registry as
> >>>>>>>> shown below (i.e., update the section number listed for this
> >>>>>>>> document).
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Reference
> >>>>>>>> [RFC9053][RFC9054][draft-ietf-jose-fully-specified-algorithms-
> >>>>>>>> 13,
> >>>>>>>> Section 4.3.1]
> >>>>>>>>
> >>>>>>>> Suggested:
> >>>>>>>> Reference
> >>>>>>>> [RFC9053][RFC9054][RFC9864, Section 4.2]
> >>>>>>>>
> >>>>>>>> Mike> Good
> >>>>>>>>
> >>>>>>>> c) In Section 4.2.1, we note that this document lists section
> >>>>>>>> numbers for the algorithms but the "COSE Algorithm" registry
> >>>>>>>> does not, so there is a mismatch. Should "Section 2.1" and
> >>>>>>>> "Section 2.2" be removed from this document for consistency
> >>>>>>>> with the registry, or should IANA add "Section 2.1" and
> >>>>>>>> "Section 2.2" accordingly for consistency with this document?
> >>>>>>>>
> >>>>>>>> Section 2.1 listed in the document
> >>>>>>>> but not in the registry for:
> >>>>>>>> ESP256
> >>>>>>>> ESP384
> >>>>>>>> ESP512
> >>>>>>>> ESB256
> >>>>>>>> ESB320
> >>>>>>>> ESB384
> >>>>>>>> ESB512
> >>>>>>>>
> >>>>>>>> Section 2.2 listed in the document
> >>>>>>>> but not in the registry for:
> >>>>>>>> Ed25519
> >>>>>>>> Ed448
> >>>>>>>>
> >>>>>>>> Mike> Thanks for noting the inconsistency. Please include the
> >>>>>>>> Mike> section numbers everywhere.
> >>>>>>>>
> >>>>>>>> d) For "ES512" in the "COSE Algorithm" registry, we note that
> >>>>>>>> "IETF"
> >>>>>>>> is not listed under "Change Controller". Should "IETF" be
> >>>>>>>> added to the registry or removed from this document?
> >>>>>>>>
> >>>>>>>> Currently in this document:
> >>>>>>>> Name: ES512
> >>>>>>>> Value: -36
> >>>>>>>> Description: ECDSA w/ SHA-512
> >>>>>>>> Capabilities: [kty]
> >>>>>>>> Change Controller: IETF
> >>>>>>>> Reference: [RFC9053] and RFC 9864
> >>>>>>>> Recommended: Deprecated
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>> Mike> Please add IETF as the change controller
> >>>>>>>>
> >>>>>>>> 7) <!-- [rfced] RFC 8152 has been obsoleted by RFC 9052. May
> >>>>>>>> we replace all instances of RFC 8152 with RFC 9052, or may we
> >>>>>>>> add the following sentence to the first mention of RFC 8152?
> >>>>>>>> Please let us know your preference.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Furthermore, while in [RFC7518] JOSE specifies that both
> >>>>>>>> "Deprecated"
> >>>>>>>> and "Prohibited" can be used, in [RFC8152] COSE specifies the
> >>>>>>>> use
> >>>>>>>> of "Deprecated" but not "Prohibited".
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> Furthermore, while in [RFC7518] JOSE specifies that both
> >>>>>>>> "Deprecated"
> >>>>>>>> and "Prohibited" can be used, in [RFC8152] COSE specifies the
> >>>>>>>> use
> >>>>>>>> of "Deprecated" but not "Prohibited" (note that [RFC8152] has
> >>>>>>>> been
> >>>>>>>> obsoleted by [RFC9052]).
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>> Mike> We kept the reference to 8152 because the referenced
> >>>>>>>> Mike> text wasn't carried forward into the documents that
> >>>>>>>> Mike> replaced it. Let's go with this:
> >>>>>>>>
> >>>>>>>> New:
> >>>>>>>> Furthermore, while in [RFC7518] JOSE specifies that both
> >>>>>>>> "Deprecated"
> >>>>>>>> and "Prohibited" can be used, in [RFC8152] COSE specifies the
> >>>>>>>> use
> >>>>>>>> of "Deprecated" but not "Prohibited". (Note that [RFC8152] has
> >>>>>>>> been
> >>>>>>>> obsoleted by [RFC9052].)
> >>>>>>>>
> >>>>>>>> 8) <!-- [rfced] Section 4.4: We see that the entry for
> >>>>>>>> "Recommended"
> >>>>>>>> is formatted differently than the entries for "Deprecated" and
> >>>>>>>> "Prohibited" that appear just before it. Would you like all
> >>>>>>>> three entries to be formatted in the same way?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Deprecated
> >>>>>>>> There is a preferred mechanism to achieve similar
> >>>>>>>> functionality to
> >>>>>>>> that referenced by the identifier; this replacement
> >>>>>>>> functionality
> >>>>>>>> SHOULD be utilized in new deployments in preference to the
> >>>>>>>> deprecated identifier, unless there exist documented
> >>>>>>>> operational
> >>>>>>>> or regulatory requirements that prevent migration away from
> >>>>>>>> the
> >>>>>>>> deprecated identifier.
> >>>>>>>>
> >>>>>>>> Prohibited
> >>>>>>>> The identifier and the functionality that it references MUST
> >>>>>>>> NOT
> >>>>>>>> be used. (Identifiers may be designated as "Prohibited" due
> >>>>>>>> to
> >>>>>>>> security flaws, for instance.)
> >>>>>>>> ...
> >>>>>>>> Recommended: Does the IETF have a consensus recommendation to
> >>>>>>>> use
> >>>>>>>> the algorithm? The legal values are "Yes", "No", "Filter
> >>>>>>>> Only",
> >>>>>>>> "Prohibited", and "Deprecated".
> >>>>>>>>
> >>>>>>>> Possibly:
> >>>>>>>> Recommended
> >>>>>>>> Does the IETF have a consensus recommendation to use the
> >>>>>>>> algorithm? The legal values are "Yes", "No", "Filter Only",
> >>>>>>>> "Prohibited", and "Deprecated". -->
> >>>>>>>>
> >>>>>>>> Mike> Yes, please make the formatting consistent in the way
> >>>>>>>> Mike> that you suggest.
> >>>>>>>>
> >>>>>>>> 9) <!-- [rfced] Section 4.4: Because the title of RFC 8996 is
> >>>>>>>> "Deprecating TLS 1.0 and TLS 1.1", should 'the term
> >>>>>>>> "Deprecated" is used in the title of [RFC8996]' be 'a
> >>>>>>>> variation of the term "Deprecated" is used in the title of
> >>>>>>>> [RFC8996]'?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> For instance, the term "Deprecated" is used in the title of
> >>>>>>>> [RFC8996], but the actual specification text uses the
> >>>>>>>> terminology "MUST NOT be used". -->
> >>>>>>>>
> >>>>>>>> Mike> Yes. 'a variation of the term "Deprecated" is used in
> >>>>>>>> Mike> the title of [RFC8996]' works for me.
> >>>>>>>>
> >>>>>>>> 10) <!-- [rfced] [OpenID.Discovery]: We see "Jones, M.B." in
> >>>>>>>> this document but "M. Jones" on the provided web page. We
> >>>>>>>> normally make the author listings in the document match what
> >>>>>>>> we see on the provided web page. Would it be possible for
> >>>>>>>> Mike to update <https://openid.net/specs/openid-connect-
> >>>>>>>> discovery-1_0.html> and list his name as "M.B. Jones", or
> >>>>>>>> should we change "Jones, M.B." to "Jones, M." here?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> [OpenID.Discovery]
> >>>>>>>> Sakimura, N., Bradley, J., Jones, M.B., and E. Jay,
> >>>>>>>> "OpenID Connect Discovery 1.0", 15 December 2023,
> >>>>>>>> <https://openid.net/specs/openid-connect-discovery-
> >>>>>>>> 1_0.html>. -->
> >>>>>>>>
> >>>>>>>> Mike> https://openid.net/specs/openid-connect-discovery-
> >>>>>>>> Mike> 1_0.html cannot be changed. Please update the reference
> >>>>>>>> Mike> to match the referenced specification by removing the
> >>>>>>>> Mike> "B." in this case.
> >>>>>>>>
> >>>>>>>> 11) <!-- [rfced] The provided URL for [FIDO2] yields a 404.
> >>>>>>>> May we update as suggested (which includes correcting the
> >>>>>>>> names of the last two authors in the list)? If not, please
> >>>>>>>> provide a working URL and correct information.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> [FIDO2] Bradley, J., Jones, M., Kumar, A., Lindemann, R.,
> >>>>>>>> Johan,
> >>>>>>>> J., and D. David, "Client to Authenticator Protocol
> >>>>>>>> (CTAP)", FIDO Alliance Proposed Standard, 28 February
> >>>>>>>> 2025, <https://fidoalliance.org/specs/fido-v2.2-ps-
> >>>>>>>> 20250228/fido-client-to-authenticator-protocol-v2.2-ps-
> >>>>>>>> 20250228.html>.
> >>>>>>>>
> >>>>>>>> Suggested:
> >>>>>>>> [FIDO2] Bradley, J., Jones, M.B., Kumar, A., Lindemann, R.,
> >>>>>>>> Verrept, J., and D. Waite, "Client to Authenticator
> >>>>>>>> Protocol (CTAP)", FIDO Alliance Proposed Standard, 14
> >>>>>>>> July 2025, <https://fidoalliance.org/specs/
> >>>>>>>> fido-v2.2-ps-20250714/
> >>>>>>>> fido-client-to-authenticator-protocol-v2.2-ps-
> >>>>>>>> 20250714.html>. -->
> >>>>>>>>
> >>>>>>>> Mike> Yes, please apply this correction.
> >>>>>>>>
> >>>>>>>> 12) <!-- [rfced] Acknowledgements: John Preuß Mattsson
> >>>>>>>> recently informed us that his last name is "Preuß Mattsson".
> >>>>>>>> Because it appears that the names should be listed in
> >>>>>>>> alphabetical order, we moved John's name in the list
> >>>>>>>> accordingly. Please let us know any concerns.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> ...
> >>>>>>>> Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias
> >>>>>>>> Looker, Neil Madden, John Preuß Mattsson, Kathleen Moriarty,
> >>>>>>>> Jeremy O'Donoghue, Anders Rundgren, Göran Selander, Filip
> >>>>>>>> Skokan, Oliver Terbu, Hannes ...
> >>>>>>>>
> >>>>>>>> Currently:
> >>>>>>>> ...
> >>>>>>>> Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias
> >>>>>>>> Looker, Neil Madden, Kathleen Moriarty, Jeremy O'Donoghue,
> >>>>>>>> John Preuß Mattsson, Anders Rundgren, Göran Selander, Filip
> >>>>>>>> Skokan, Oliver Terbu, Hannes ... -->
> >>>>>>>>
> >>>>>>>> Mike> Works for me.
> >>>>>>>>
> >>>>>>>> 13) <!-- [rfced] Please review the "Inclusive Language"
> >>>>>>>> portion of the online Style Guide at <https://www.rfc-/
> >>>>>>>> editor.org/styleguide/part2/#inclusive_language>,
> >>>>>>>> and let us know if any changes are needed. Updates of this
> >>>>>>>> nature typically result in more precise language, which is
> >>>>>>>> helpful for readers.
> >>>>>>>>
> >>>>>>>> Note that our script did not flag any words in particular, but
> >>>>>>>> this should still be reviewed as a best practice. -->
> >>>>>>>>
> >>>>>>>> Mike> I am not aware of any inclusive language changes needed.
> >>>>>>>>
> >>>>>>>> 14) <!-- [rfced] Please let us know if any changes are needed
> >>>>>>>> for the
> >>>>>>>> following:
> >>>>>>>>
> >>>>>>>> a) The following term was used inconsistently in this
> >>>>>>>> document.
> >>>>>>>> We chose to use the latter form. Please let us know any
> >>>>>>>> objections.
> >>>>>>>>
> >>>>>>>> fully-specified /
> >>>>>>>> fully specified (e.g., "are fully-specified", "are fully
> >>>>>>>> specified", "fully specified RSA algorithms")*
> >>>>>>>>
> >>>>>>>> * Per the Chicago Manual of Style
> >>>>>>>> ("Compounds formed by an adverb ending in ‑ly plus an
> >>>>>>>> adjective or participle (such as largely irrelevant or
> >>>>>>>> smartly dressed) are not hyphenated either before or after a
> >>>>>>>> noun, since ambiguity is virtually impossible (a smartly
> >>>>>>>> dressed couple).")
> >>>>>>>>
> >>>>>>>> Mike> We decided earlier to go with "fully-specified". No
> >>>>>>>> Mike> additional changes are needed in this regard.
> >>>>>>>>
> >>>>>>>> b) The following terms appear to be used inconsistently in
> >>>>>>>> this document. Please let us know which form is preferred.
> >>>>>>>>
> >>>>>>>> alg value (2 instances) / "alg" value (7 instances)
> >>>>>>>>
> >>>>>>>> Mike> Let's use "alg" value.
> >>>>>>>>
> >>>>>>>> enc value ("alg and enc values") / "enc" value (5 instances)
> >>>>>>>>
> >>>>>>>> Mike> Let's use "enc" value.
> >>>>>>>>
> >>>>>>>> HSS/LMS / HSS-LMS ("HSS/LMS Hash-Based Digital Signature
> >>>>>>>> Algorithm",
> >>>>>>>> "HSS-LMS algorithm")
> >>>>>>>>
> >>>>>>>> Mike> Both "HSS-LMS" and "HSS/LMS hash-based digital
> >>>>>>>> Mike> signature" are used in the COSE algorithms registry.
> >>>>>>>> Mike> Therefore, the current text is consistent with the
> >>>>>>>> Mike> registry entry. No change is needed.
> >>>>>>>>
> >>>>>>>> c) The following terms appear both with and without <tt> in
> >>>>>>>> the XML file. Please review, and let us know if the current
> >>>>>>>> applications of <tt> are correct and consistent.
> >>>>>>>>
> >>>>>>>> <tt>Ed25519</tt> (no <tt>s in IANA Considerations section)
> >>>>>>>> <tt>Ed448</tt> (no <tt>s in IANA Considerations section)
> >>>>>>>> <tt>EdDSA</tt> usage of <tt> appears to be inconsistent
> >>>>>>>> (e.g., in
> >>>>>>>> the XML file, we see
> >>>>>>>> "This redefines the COSE <tt>EdDSA</tt> algorithm identifier"
> >>>>>>>> and
> >>>>>>>> "The following fully specified JOSE and COSE EdDSA algorithms"
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>> Mike> Please add <tt> where missing for algorithm names, such
> >>>>>>>> Mike> as "The following fully specified JOSE and COSE
> >>>>>>>> Mike> <tt>EdDSA</tt> algorithms"
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>>
> >>>>>>>> Lynne Bartholomew and Karen Moore
> >>>>>>>> RFC Production Center
> >>>>>>>>
> >>>>>>>> Mike> Thank you!
> >>>>>>>>
> >>>>>>>>>> On Sep 18, 2025, at 12:48 PM, RFC Editor via auth48archive
> >>>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>>
> >>>>>>>>>> *****IMPORTANT*****
> >>>>>>>>>>
> >>>>>>>>>> Updated 2025/09/18
> >>>>>>>>>>
> >>>>>>>>>> RFC Author(s):
> >>>>>>>>>> --------------
> >>>>>>>>>>
> >>>>>>>>>> Instructions for Completing AUTH48
> >>>>>>>>>>
> >>>>>>>>>> Your document has now entered AUTH48. Once it has been
> >>>>>>>>>> reviewed and approved by you and all coauthors, it will be
> >>>>>>>>>> published as an RFC.
> >>>>>>>>>> If an author is no longer available, there are several
> >>>>>>>>>> remedies available as listed in the FAQ (https://www.rfc-/
> >>>>>>>>>> editor.org/faq/).
> >>>>>>>>>>
> >>>>>>>>>> You and you coauthors are responsible for engaging other
> >>>>>>>>>> parties (e.g., Contributors or Working Group) as necessary
> >>>>>>>>>> before providing your approval.
> >>>>>>>>>>
> >>>>>>>>>> Planning your review
> >>>>>>>>>> ---------------------
> >>>>>>>>>>
> >>>>>>>>>> Please review the following aspects of your document:
> >>>>>>>>>>
> >>>>>>>>>> * RFC Editor questions
> >>>>>>>>>>
> >>>>>>>>>> Please review and resolve any questions raised by the RFC
> >>>>>>>>>> Editor
> >>>>>>>>>> that have been included in the XML file as comments marked
> >>>>>>>>>> as
> >>>>>>>>>> follows:
> >>>>>>>>>>
> >>>>>>>>>> <!-- [rfced] ... -->
> >>>>>>>>>>
> >>>>>>>>>> These questions will also be sent in a subsequent email.
> >>>>>>>>>>
> >>>>>>>>>> * Changes submitted by coauthors
> >>>>>>>>>>
> >>>>>>>>>> Please ensure that you review any changes submitted by your
> >>>>>>>>>> coauthors. We assume that if you do not speak up that you
> >>>>>>>>>> agree to
> >>>>>>>>>> changes submitted by your coauthors.
> >>>>>>>>>>
> >>>>>>>>>> * Content
> >>>>>>>>>>
> >>>>>>>>>> Please review the full content of the document, as this
> >>>>>>>>>> cannot
> >>>>>>>>>> change once the RFC is published. Please pay particular
> >>>>>>>>>> attention to:
> >>>>>>>>>> - IANA considerations updates (if applicable)
> >>>>>>>>>> - contact information
> >>>>>>>>>> - references
> >>>>>>>>>>
> >>>>>>>>>> * Copyright notices and legends
> >>>>>>>>>>
> >>>>>>>>>> Please review the copyright notice and legends as defined in
> >>>>>>>>>> RFC
> >>>>>>>>>> 5378 and the Trust Legal Provisions (TLP –
> >>>>>>>>>> https://trustee.ietf.org/license-info).
> >>>>>>>>>>
> >>>>>>>>>> * Semantic markup
> >>>>>>>>>>
> >>>>>>>>>> Please review the markup in the XML file to ensure that
> >>>>>>>>>> elements of
> >>>>>>>>>> content are correctly tagged. For example, ensure that
> >>>>>>>>>> <sourcecode>
> >>>>>>>>>> and <artwork> are set correctly. See details at
> >>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
> >>>>>>>>>>
> >>>>>>>>>> * Formatted output
> >>>>>>>>>>
> >>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that
> >>>>>>>>>> the
> >>>>>>>>>> formatted output, as generated from the markup in the XML
> >>>>>>>>>> file, is
> >>>>>>>>>> reasonable. Please note that the TXT will have formatting
> >>>>>>>>>> limitations compared to the PDF and HTML.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Submitting changes
> >>>>>>>>>> ------------------
> >>>>>>>>>>
> >>>>>>>>>> To submit changes, please reply to this email using ‘REPLY
> >>>>>>>>>> ALL’ as
> >>>>>>>>>> all the parties CCed on this message need to see your
> >>>>>>>>>> changes. The
> >>>>>>>>>> parties
> >>>>>>>>>> include:
> >>>>>>>>>>
> >>>>>>>>>> * your coauthors
> >>>>>>>>>>
> >>>>>>>>>> * [email protected] (the RPC team)
> >>>>>>>>>>
> >>>>>>>>>> * other document participants, depending on the stream
> >>>>>>>>>> (e.g.,
> >>>>>>>>>> IETF Stream participants are your working group chairs, the
> >>>>>>>>>> responsible ADs, and the document shepherd).
> >>>>>>>>>>
> >>>>>>>>>> * [email protected], which is a new archival
> >>>>>>>>>> mailing list
> >>>>>>>>>> to preserve AUTH48 conversations; it is not an active
> >>>>>>>>>> discussion
> >>>>>>>>>> list:
> >>>>>>>>>>
> >>>>>>>>>> * More info:
> >>>>>>>>>>
> >>>>>>>>>> https://maila/
> >>>>>>>>>> rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-
> >>>>>>>>>> 4Q9l2USxIAe6P
> >>>>>>>>>> 8
> >>>>>>>>>> O4Zc&data=05%7C02%7C%7C761b71ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f
> >>>>>>>>>> 6
> >>>>>>>>>> 40afb435aaaaaaaaaaaa%7C1%7C0%7C638939174977368758%7CUnknown%7CTWFpbGZ
> >>>>>>>>>> s
> >>>>>>>>>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> >>>>>>>>>> j
> >>>>>>>>>> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c67E5JmKVA73PwHxHTAjKpB
> >>>>>>>>>> j
> >>>>>>>>>> ckPOveGLD5eLfMLHLPU%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> * The archive itself:
> >>>>>>>>>>
> >>>>>>>>>> https://maila/
> >>>>>>>>>> rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7C%7C
> >>>>>>>>>> 7
> >>>>>>>>>> 61b71ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C
> >>>>>>>>>> 1
> >>>>>>>>>> %7C0%7C638939174977385249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> >>>>>>>>>> y
> >>>>>>>>>> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> >>>>>>>>>> %
> >>>>>>>>>> 3D%7C0%7C%7C%7C&sdata=TaXkq4q%2BqGcE0jxkrRshom%2F30XVg%2BqzoLR82FE1tL
> >>>>>>>>>> K
> >>>>>>>>>> 0%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> * Note: If only absolutely necessary, you may temporarily
> >>>>>>>>>> opt out
> >>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive
> >>>>>>>>>> matter).
> >>>>>>>>>> If needed, please add a note at the top of the message that
> >>>>>>>>>> you
> >>>>>>>>>> have dropped the address. When the discussion is concluded,
> >>>>>>>>>> [email protected] will be re-added to the CC
> >>>>>>>>>> list and
> >>>>>>>>>> its addition will be noted at the top of the message.
> >>>>>>>>>>
> >>>>>>>>>> You may submit your changes in one of two ways:
> >>>>>>>>>>
> >>>>>>>>>> An update to the provided XML file
> >>>>>>>>>> — OR —
> >>>>>>>>>> An explicit list of changes in this format
> >>>>>>>>>>
> >>>>>>>>>> Section # (or indicate Global)
> >>>>>>>>>>
> >>>>>>>>>> OLD:
> >>>>>>>>>> old text
> >>>>>>>>>>
> >>>>>>>>>> NEW:
> >>>>>>>>>> new text
> >>>>>>>>>>
> >>>>>>>>>> You do not need to reply with both an updated XML file and
> >>>>>>>>>> an explicit list of changes, as either form is sufficient.
> >>>>>>>>>>
> >>>>>>>>>> We will ask a stream manager to review and approve any
> >>>>>>>>>> changes that seem beyond editorial in nature, e.g., addition
> >>>>>>>>>> of new text, deletion of text, and technical changes.
> >>>>>>>>>> Information about stream managers can be found in the FAQ.
> >>>>>>>>>> Editorial changes do not require approval from a stream
> >>>>>>>>>> manager.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Approving for publication
> >>>>>>>>>> --------------------------
> >>>>>>>>>>
> >>>>>>>>>> To approve your RFC for publication, please reply to this
> >>>>>>>>>> email stating that you approve this RFC for publication.
> >>>>>>>>>> Please use ‘REPLY ALL’, as all the parties CCed on this
> >>>>>>>>>> message need to see your approval.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Files
> >>>>>>>>>> -----
> >>>>>>>>>>
> >>>>>>>>>> The files are available here:
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9864.xml&data=05%7C02%7C%7C91aa2df0daa5
> >>>>>>>>>> 4943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638
> >>>>>>>>>> 943284065580201%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> >>>>>>>>>> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> >>>>>>>>>> C%7C%7C&sdata=J%2B%2BbnL37e54MKyJRORpcnBYmCykPfGy8DE5WZCZdWWI%3D&rese
> >>>>>>>>>> rved=0
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9864.html&data=05%7C02%7C%7C91aa2df0daa
> >>>>>>>>>> 54943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63
> >>>>>>>>>> 8943284065596919%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> >>>>>>>>>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%
> >>>>>>>>>> 7C%7C%7C&sdata=q01yZ03I%2FviVW6nDhK2aVURwm9IVrZ0tretGnwYSYqQ%3D&reser
> >>>>>>>>>> ved=0
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> rfc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9864.pdf&data=05%7C02%7C%7C91aa2df0daa5
> >>>>>>>>>> 4943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638
> >>>>>>>>>> 943284065613325%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> >>>>>>>>>> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> >>>>>>>>>> C%7C%7C&sdata=9AWfQDiclBkvJu%2FRag2iAWy82RqR%2FiBXZ0%2BjGOJGzqE%3D&re
> >>>>>>>>>> served=0
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f
> >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065629453%7CUnknown%7CTWFpbG
> >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF
> >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kB71H%2F%2B2fbtM%2BI
> >>>>>>>>>> t8vVSL56Va42PeWdjLFpCcaQV3zrY%3D&reserved=0
> >>>>>>>>>> fc-
> >>>>>>>>>> editor.org%2Fauthors%2Frfc9864.txt&data=05%7C02%7C%7C761b71ce49ea4
> >>>>>>>>>> 2
> >>>>>>>>>> e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63893
> >>>>>>>>>> 9
> >>>>>>>>>> 174977450136%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> >>>>>>>>>> L
> >>>>>>>>>> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> >>>>>>>>>> %
> >>>>>>>>>> 7C&sdata=Sw4hdekzH6euwekPdmkgArRgDE9jxN%2FBbxniPqBXGb4%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> Diff file of the text:
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> rfc-editor.org%2Fauthors%2Frfc9864-
> >>>>>>>>>> diff.html&data=05%7C02%7C%7C91aa2d
> >>>>>>>>>> f0daa54943e1e708ddfb881343%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0
> >>>>>>>>>> %7C638943284065645773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> >>>>>>>>>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> >>>>>>>>>> %7C0%7C%7C%7C&sdata=61beAaISKTA9xH5PalRDeAINUUCL23Ie3dDucrqSf9Q%3D&re
> >>>>>>>>>> served=0
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f
> >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065664319%7CUnknown%7CTWFpbG
> >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF
> >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VZi1WfQUh8aqDbh5FgtP
> >>>>>>>>>> 3BCPWS3qiwliQEcgLAhf33g%3D&reserved=0
> >>>>>>>>>> fc-editor.org%2Fauthors%2Frfc9864-
> >>>>>>>>>> rfcdiff.html&data=05%7C02%7C%7C761b
> >>>>>>>>>> 7
> >>>>>>>>>> 1ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C
> >>>>>>>>>> 0
> >>>>>>>>>> %7C638939174977482323%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> >>>>>>>>>> s
> >>>>>>>>>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> >>>>>>>>>> 7
> >>>>>>>>>> C0%7C%7C%7C&sdata=EvN4SdkHmBnKNv4SjQPMZT3Crd9P%2FAdrRVzHTQJ50WU%3D&re
> >>>>>>>>>> s
> >>>>>>>>>> erved=0 (side by side)
> >>>>>>>>>>
> >>>>>>>>>> Diff of the XML:
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f
> >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065680577%7CUnknown%7CTWFpbG
> >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF
> >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mQFxALBZrQ5Egd7CsSIS
> >>>>>>>>>> j3tosB3tyHFlqc8mZAYgoCk%3D&reserved=0
> >>>>>>>>>> fc-editor.org%2Fauthors%2Frfc9864-
> >>>>>>>>>> xmldiff1.html&data=05%7C02%7C%7C761
> >>>>>>>>>> b
> >>>>>>>>>> 71ce49ea42e893e008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7
> >>>>>>>>>> C
> >>>>>>>>>> 0%7C638939174977501023%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> >>>>>>>>>> U
> >>>>>>>>>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> >>>>>>>>>> %
> >>>>>>>>>> 7C0%7C%7C%7C&sdata=zb%2BxMfmrtEW4EzQuOyYybMEbf%2BPxJ%2FYy1xLdb5VWkig%
> >>>>>>>>>> 3
> >>>>>>>>>> D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Tracking progress
> >>>>>>>>>> -----------------
> >>>>>>>>>>
> >>>>>>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>>>>>
> >>>>>>>>>> https://www/.
> >>>>>>>>>> r%2F&data=05%7C02%7C%7C91aa2df0daa54943e1e708ddfb881343%7C84df9e7fe9f
> >>>>>>>>>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638943284065697092%7CUnknown%7CTWFpbG
> >>>>>>>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF
> >>>>>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OKWb9Ta3CEbIuo8DrYng
> >>>>>>>>>> nphBXzbyeulO%2FcvFWk1vADw%3D&reserved=0
> >>>>>>>>>> fc-
> >>>>>>>>>> editor.org%2Fauth48%2Frfc9864&data=05%7C02%7C%7C761b71ce49ea42e893
> >>>>>>>>>> e
> >>>>>>>>>> 008ddf7cb5bc1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389391749
> >>>>>>>>>> 7
> >>>>>>>>>> 7517704%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> >>>>>>>>>> D
> >>>>>>>>>> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> >>>>>>>>>> d
> >>>>>>>>>> ata=IqovDgFGL85gX%2B3TddI%2FRyWRSVYSIszXtFZnxn1f9%2Bs%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> Please let us know if you have any questions.
> >>>>>>>>>>
> >>>>>>>>>> Thank you for your cooperation,
> >>>>>>>>>>
> >>>>>>>>>> RFC Editor
> >>>>>>>>>>
> >>>>>>>>>> --------------------------------------
> >>>>>>>>>> RFC9864 (draft-ietf-jose-fully-specified-algorithms-13)
> >>>>>>>>>>
> >>>>>>>>>> Title : Fully-Specified Algorithms for JOSE and
> >>>>>>>>>> COSE
> >>>>>>>>>> Author(s) : M.B. Jones, O. Steele
> >>>>>>>>>> WG Chair(s) : John Bradley, John Preuß Mattsson, Karen
> >>>>>>>>>> O'Donoghue
> >>>>>>>>>>
> >>>>>>>>>> Area Director(s) : Deb Cooley, Paul Wouters
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>> <rfc9864.xml>
> >>
> >
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
