Hi Deb,

Thanks for the note. I confirm that I have read that blob as part of the 
write-up from Karen. I don’t think we need to go that path.

Michael’s PR is great 
(https://github.com/ietf-wg-jose/draft-ietf-jose-fully-specified-algorithms/pull/31),though.

Looking forward seeing the new version.

Cheers,
Med

De : Deb Cooley <[email protected]>
Envoyé : jeudi 1 mai 2025 21:28
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
Cc : The IESG <[email protected]>; 
[email protected]; [email protected]; 
[email protected]; [email protected]
Objet : Re: Mohamed Boucadair's Discuss on 
draft-ietf-jose-fully-specified-algorithms-09: (with DISCUSS and COMMENT)

Please note that the ballot text explains the update of an obsoleted RFC.

Deb

On Mon, Apr 28, 2025 at 11:56 AM Mohamed Boucadair via Datatracker 
<[email protected]<mailto:[email protected]>> wrote:
Mohamed Boucadair has entered the following ballot position for
draft-ietf-jose-fully-specified-algorithms-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Michael & Orie,

Thanks for the effort put into this specification.

I like the clarity provided by the definition of "deprecated" and "prohibited",
especially in reference to deployment impacts.

I have two DISCUSS points and some very minor comments.

# Update an obsoleted RFC

It seems weird to me that we are updating an obsoleted RFC (RFC8152). Maybe
cleaner to include a complete updated definition of the "Recommended" column.

# The update may not be complete

CURRENT:
   (Note that [RFC9053] did not carry the definitions of
   the "Recommended" registry columns forward, so [RFC8152] remains
   definitive in this regard.)

I'd like to double check this part. RFC8152 says:

   Recommended:  Does the IETF have a consensus recommendation to use
      the algorithm?  The legal values are 'Yes', 'No', and
      'Deprecated'.

However, other values are used in the registry (Filter Only, for example).
Where that value is defined as "legal"?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Expand JOSE/COSE in the title

# Abstract

(1) Delete "etc." as "including" is expected to provide concrete examples.

(2) s/being "fully specified"/being "fully-specified" (to be consistent with
the use in the document)

# Introduction

CURRENT:
   Fully Specified
      Those that fully determine the cryptographic operations to be
      performed, including any curve, key derivation function (KDF), and
      hash functions, etc.  Examples are RS256 and ES256K in both JOSE
      and COSE  and ES256 in JOSE.

* Delete "etc."
* Cite authoritative references to COSE/JOSE

# "current"

   [RFC9053] defines the current use of the Elliptic Curve Digital
   Signature Algorithm (ECDSA) by COSE.

and

   [RFC8037] defines the current use of the Edwards-Curve Digital
   Signature Algorithm (EdDSA) by JOSE and [RFC9053] defines its current
   use by COSE.

What do we mean by "current" here? Do we mean "initial"?

# Section 3

(1) Please check the following

CURRENT:
   This section describes the construction of fully-specified encryption
   algorithm identifiers in the context of existing the JOSE and COSE
                                                    ^^^^
   encryption schemes JSON Web Encryption, (JWE) as described in
                                        ^^^^^^^^

(2) What is meant by "essential" in the following (and other similar
occurrences)? Do we mean "required"? Mandatory? something else?

CURRENT:
  To perform fully-specified encryption in JOSE, the "alg" value MUST
   specify all essential parameters for key establishment or derive some
   of them from the accompanying "enc" value and the "enc" value MUST
   specify all essential parameters for symmetric encryption.

(3) cite where the outer "alg" is defined

CURRENT:
   To perform fully-specified encryption in COSE, the outer "alg" value

# Section 4.1

CURRENT:
   This section registers the following values in the IANA "JSON Web
   Signature and Encryption Algorithms" registry [IANA.JOSE] established
   by [RFC7515].

Move the text to be under 4.1.1 given that 4.1.2 is about updating a
registration.

# Section 4.2

CURRENT:
   This section registers the following values in the IANA "COSE
   Algorithms" registry [IANA.COSE].

Move to text to be under 4.2.1.

# Section 4.4

CURRENT:
     (Identifiers MAY be designated as "Prohibited" due to
      security flaws, for instance.)

Inappropriate use of normative language as this is an example. s/MAY/may.

# Section 6

This is a general comment for this section.

What is the value of having this in the final RFC? We don't document all points
discussed by WG, after all.

The final document will reflect the IETF consensus. I would delete at least all
mentions with "The working group has discussed".

Cheers,
Med


____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to