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) -->
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.) -->
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]. -->
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. -->
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. -->
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.
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]
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
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
-->
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]).
-->
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". -->
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". -->
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>. -->
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>. -->
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
... -->
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. -->
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).")
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)
enc value ("alg and enc values") / "enc" value (5 instances)
HSS/LMS / HSS-LMS ("HSS/LMS Hash-Based Digital Signature Algorithm",
"HSS-LMS algorithm")
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" -->
Thank you.
Lynne Bartholomew and Karen Moore
RFC Production Center
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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* 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/authors/rfc9864.xml
https://www.rfc-editor.org/authors/rfc9864.html
https://www.rfc-editor.org/authors/rfc9864.pdf
https://www.rfc-editor.org/authors/rfc9864.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9864-diff.html
https://www.rfc-editor.org/authors/rfc9864-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9864-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9864
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]
