Rob: At this point, I think the COSE WG Chairs need to speak up.
Russ > On May 16, 2023, at 12:26 PM, Rob Wilton (rwilton) <[email protected]> wrote: > > 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] <mailto:[email protected]>> > Sent: 16 May 2023 17:09 > To: Rob Wilton (rwilton) <[email protected] <mailto:[email protected]>> > Cc: IESG <[email protected] <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]>; Cose Chairs Wg > <[email protected] <mailto:[email protected]>>; cose <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[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
