[COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-cose-rfc8152bis-algs-09: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/



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

Hi,

I've only reviewed the diff against RFC8152.   The vast majority of this
document seemed to have only minimal changes and looked fine from what I could
see.

A few minor comments that may help improve the document:

Abstract

   Concise Binary Object Representation (CBOR) is a data format designed
   for small code size and small message size.  There is a need for the
   ability to have basic security services defined for this data format.
   This document defines the CBOR Object Signing and Encryption (COSE)
   protocol.  This specification describes how to create and process
   signatures, message authentication codes, and encryption using CBOR
   for serialization.  COSE additionally describes how to represent
   cryptographic keys using CBOR.

   In this specification the conventions for the use of a number of
   cryptographic algorithms with COSE.

First sentence of the second paragraph doesn't quite scan, and I wasn't
convinced that the first paragraph is necessarily correct/accurate after the
document split (in particular the "This document" and "This specification"
bits).

Section 7.2

   x:   This contains the public key.  The byte string contains the
        public key as defined by the algorithm.  (For X25591, internally
        it is a little-endian integer.)

   d:   This contains the private key.

One minor thing that I noted, is that you define that the public key is defined
by the algorithm, but don't say the same thing for the private key.  If you
change this, then you might want to check other references to "private key" as
well.

8.  COSE Capabilities

   The concept is being pulled forward and defined now for
   COSE.

Perhaps rephrase this to: "This document defines the same concept for COSE."

8.  COSE Capabilities

   The algorithm identifier is not part of the capabilities data as it
   should already be part of message structure.  There is a presumption
   in the way that this is laid out is that the algorithm identifier
   itself is not needed to be a part of this as it is specified in a
   different location.

I found the second sentence somewhat unclear and could probably be wordsmithed,
in particular does "this" refer to the capabilities data or the message
structure.

8.  COSE Capabilities

   Two different types of capabilities are defined: capabilities for
   algorithms and capabilities for key structures.  Once defined by
   registration with IANA, the list of capabilities is immutable.  If it
   is later found that a new capability is needed for a key type or an
   algorithm, it will require that a new code point be assigned to deal
   with that.  As a general rule, the capabilities are going to map to
   algorithm-specific header parameters or key parameters, but they do
   not need to do so.  An example of this is the HSS-LMS key
   capabilities defined below where the hash algorithm used is included.

Defining the capabilities list as immutable seemed like a misnomer to me
because a new IANA registration would mutate the list.  Perhaps this sentence,
and the one following it, could be removed?

   The capability structure is an array of values, the order being
   dependent on the specific algorithm or key.  For an algorithm, the
   first element should always be a key type value, but the items that
   are specific to a key should not be included in the algorithm
   capabilities.  This means that if one wishes to enumerate all of the
   capabilities for a device which implements ECDH, it requires multiple
   pairs of capability structures (algorithm, key) to deal with the
   different key types and curves that are supported.  For a key, the
   first element should also be a key type value.  While this means that
   this value will be duplicated if both an algorithm and key capability
   are used, the key type is needed in order to understand the rest of
   the values.

Should you be using RFC 2119 language here?  And should " key should not be
included" be "MUST NOT"?

For the ECDH case, does that mean that the "algorithm" entry will be duplicated
with different "key" entries?  If so, would it help clarify to explicitly state
this?

Thanks,
Rob