Hi Russ,

I'm more thinking that when some is looking at the registry on the IANA pages 
rather than looking at this RFC.   I.e., when someone is looking at CBOR Object 
Signing and Encryption (COSE) 
(iana.org)<https://www.iana.org/assignments/cose/cose.xhtml>, then it still 
feels like this is redefining the meaning of "deprecated" to mean something 
else, or otherwise if we really think that these shouldn't be used, and a 
different algorithm should be chosen in their place, then why are we 
standardizing them and allocating code points?  "Here are some new code points 
for you that you should not use!"

Regards,
Rob


From: Russ Housley <[email protected]>
Sent: 16 May 2023 17:09
To: Rob Wilton (rwilton) <[email protected]>
Cc: IESG <[email protected]>; [email protected]; Cose Chairs 
Wg <[email protected]>; cose <[email protected]>; [email protected]
Subject: Re: Robert Wilton's No Objection on 
draft-ietf-cose-aes-ctr-and-cbc-04: (with COMMENT)

Rob:

(3) p 6, sec 5.2.  AES-CBC COSE Algoritm Identifiers

 The following table defines the COSE AES-CBC algorithm values.  Note
 that these algorithms are being registered as "Deprecated" to avoid
 accidental use without a companion integrity protection mechanism.
+=========+=======+==========+========================+=========
====+

 | Name    | Value | Key Size |      Description       | Recommended |
+=========+=======+==========+========================+=========
====+

 | A128CBC |  TBD4 |   128    |       AES-CBC w/       |  Deprecated |
 |         |       |          |      128-bit key       |             |
 +---------+-------+----------+------------------------+-------------+
 | A192CBC |  TBD5 |   192    |       AES-CBC w/       |  Deprecated |
 |         |       |          |      192-bit key       |             |
 +---------+-------+----------+------------------------+-------------+
 | A256CBC |  TBD6 |   256    |       AES-CBC w/       |  Deprecated |
 |         |       |          |      256-bit key       |             |
 +---------+-------+----------+------------------------+-------------+

I wanted to check that "Deprecated" is really the best choice for
"Recommended"

for both AES-CTR and AES-CBC.  I read 'deprecated' as meaning that other
COSE

algorithms should be used in preference to these, but it wasn't clear that is
the intent here.  I note that this column contains some entries with a value
such as "Filter Only", hence wondering it these should be labelled as
"Confidentiality only", perhaps with the description indicating that
integrity

must be handled separately?

This was the consensus of the COSE WG since these algorithms do not
provide both confidentiality and integrity.
[Rob Wilton (rwilton)]

Presumably these aren't currently used (because they don't have a value 
assigned), and if users should always use a different protocol in preference 
(because these are marked as deprecated), then I'm struggling to understand why 
we are publishing this at all?  Or in summary, I think that the calling them 
deprecated may cause confusion.

I think the text above the table provides the explanation.  Repeating it:

   The following table defines the COSE AES-CTR algorithm values.  Note
   that these algorithms are being registered as "Deprecated" to avoid
   accidental use without a companion integrity protection mechanism.

The COSE WG felt that "Not Recommendd" was not strong enough.

Russ

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to