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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 11:16:28 -0700

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 Jun 2020 16:13:15 -0700

-----Original Message-----
From: Robert Wilton via Datatracker <[email-masked]> 
Sent: Tuesday, June 9, 2020 11:16 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Matthew Miller <[email-masked]>; [email-masked]
Subject: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)

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.)

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.

Abstract

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).
[JLS] Fixed in reply to Roman's comment.

Section 7.2

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.
[JLS] Under normal circumstances I would have omitted the definition of the public key from that text.  The problem is that there has been a lot of issues with this because it is the reverse of what is normally done.  Almost all integers are normally big-endian in cryptograph, and thus I am highlighting a single case where it is not.  I will also point to the existence of https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-09 which uses the same curve under a different representation and done the big-endian encoding.  

8.  COSE Capabilities

Perhaps rephrase this to: "This document defines the same concept for COSE."
[JLS] That is better than the wording from Roman - updated to use this.

8.  COSE Capabilities

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.
[JLS] This has already been changed in response to Roman.

8.  COSE Capabilities

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?
[JLS] The whole object is that once registered with IANA, it will never be changed even by IANA.  Thus I believe that the word immutable seems to be correct.  If this is changed then existing signatures will fail and key derivation functions will generate different results.

Should you be using RFC 2119 language here?  And should " key should not be included" be "MUST NOT"?
[JLS] Responded to this point in Roman's comments.

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?
[JLS] Would pointing to the second and third examples in section 8.3 along with some explanatory text?

Jim

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 10 Jun 2020 11:03:15 +0000

Hi Jim,

Please see inline ...

> From: Jim Schaad <[email-masked]>
> Sent: 10 June 2020 00:13
> To: Rob Wilton (rwilton) <[email-masked]>; 'The IESG' <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; 'Matthew Miller' <[email-masked]>
> Subject: RE: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-
> algs-09: (with COMMENT)
> 
> 
> 
> Cc: [email-masked]; [email-masked];
> [email-masked]; Matthew Miller <[email-masked]>;
> [email-masked]
> convinced that the first paragraph is necessarily correct/accurate after
> the document split (in particular the "This document" and "This
> specification"
> bits).
> 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.
> [JLS] Under normal circumstances I would have omitted the definition of
> the public key from that text.  The problem is that there has been a lot
> of issues with this because it is the reverse of what is normally done.
> Almost all integers are normally big-endian in cryptograph, and thus I am
> highlighting a single case where it is not.  I will also point to the
> existence of https://tools.ietf.org/html/draft-ietf-lwig-curve-
> representations-09 which uses the same curve under a different
> representation and done the big-endian encoding.
> 
> 8.  COSE Capabilities
> 
> 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.
> because a new IANA registration would mutate the list.  Perhaps this
> sentence, and the one following it, could be removed?
> [JLS] The whole object is that once registered with IANA, it will never be
> changed even by IANA.  Thus I believe that the word immutable seems to be
> correct.  If this is changed then existing signatures will fail and key
> derivation functions will generate different results.
[RW]

I'm still slightly confused, and alas the more I read the text the more confused I become ;-)

Hence a clarifying question: Does "the list of capabilities is immutable", does it mean that the list of capabilities associated with a given algorithm or key structure is immutable?  Or does it mean that the entire list of defined capabilities as a set is immutable?

And in the following paragraph, where is states "The capability structure is an array of values" does it mean the capability structure associated with a particular algorithm or key?

Another question relates to "The capability structure is an array of values,", does this mean "The capability structure for a given algorithm or key is an ordered array of values, the order ... "

The paragraph below also mentions multiple pairs of capability structures.  Do the capabilities always come as a pair of an algorithm and a key?  If there are multiple pairs then how are they encoded, presumably as an array of pairs?  If capabilities do not always come as a pair then you do you differentiate between a capability defining an algorithm and one defining a key?

> 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?
[RW] 

Perhaps, but I think that it would also be useful to have an example of supporting ECDH-ES with both P-256 and X25519 curves, and how that would be encoded (if that makes sense).

I also couldn't convince myself that the numerical values that are used in the examples are necessary right, please can you check that they are.  E.g., the first two example have the same numeric encoding, and the two ECDH-ES have different encodings of the algorithm.  But perhaps that is just my confusion about how this works.

Regards,
Rob

---

From: Jim Schaad <[email-masked]>
Date: Thu, 18 Jun 2020 10:54:55 -0700

Rob,

I have spent way too long trying to do edits and re-writes and additions and deletions on this.  I don't think that I can even read it anymore.  However, https://cose-wg.github.io/cose-rfc8152bis/draft-ietf-cose-rfc8152bis-algs.html#name-cose-capabilities has an updated version of this that I think will address all of your comments.  Please review.

Thanks, Jim

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: Wednesday, June 10, 2020 4:03 AM
To: Jim Schaad <[email-masked]>; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; 'Matthew Miller' <[email-masked]>
Subject: RE: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)

Hi Jim,

Please see inline ...

> Subject: Robert Wilton's No Objection on 
> draft-ietf-cose-rfc8152bis-algs-
> 09: (with COMMENT)
> 
> 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
> 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?
> [JLS] The whole object is that once registered with IANA, it will 
> never be changed even by IANA.  Thus I believe that the word immutable 
> seems to be correct.  If this is changed then existing signatures will 
> fail and key derivation functions will generate different results.
[RW]

Hence a clarifying question: Does "the list of capabilities is immutable", does it mean that the list of capabilities associated with a given algorithm or key structure is immutable?  Or does it mean that the entire list of defined capabilities as a set is immutable?
[JLS] The intention is to say that it is fixed for a single algorithm or key type and not the entire list.

[JLS] Yes

[JLS] Yes

> duplicated with different "key" entries?  If so, would it help clarify 
> to explicitly state this?
[RW] 

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 19 Jun 2020 15:07:36 +0000

Hi Jim,

Sorry, but I'm still struggling to fully understand the capability text.  That may be because it is too far out of my domain of expertise, or it may be because the text is unclear.  It is also worth noting that I've not read the entire document, just the diffs.  Also note that these are just comments intended to help the readability of the document, they don't block the progression of the document, so the authors are at liberty to ignore them if they choose.

From the latest text on github, the things that I don't fully understand, or potentially find the text somewhat confusing are:

"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."

1. Is the use of a pair of capabilities (algorithm capabilities, key capabilities) normative, or just an example usage?  I.e. is this one way that this could be achieved, or the only way that this would be achieved.

"Just an algorithm capability: This is useful if you want to require a specific algorithm such as ECDSA, but you are agnostic about which curve is being used. See the first example."

2. Is the capability actually saying that a specific algorithm is being used, or is it that a particular key type is being used for the algorithm?  [Given that the algorithm capabilities don't encode the choice of algorithm.]

"Just a key type capability: This is useful if you want to require a specific curve such as P-256, but will accept any algorithm using that curve (e.g. both ECDSA and ECDH). See the second example."

3. Presumably this example is also constraining the key type to EC2 as well as the curve to P-256?

"Both an algorithm and a key type capability: This is used if one needs to nail down all of the options surrounding an algorithm E.g. EdDSA with the curve X25519. See the third example which just concatenates the two capabilities together."

4. Am I right to ensure that a separate specification, where the capabilities structures are being used, would specify that the capabilities are defined as an array of algorithm capabilities followed by key value capabilities. [Related to comment 1 above.]

Nits:

I would suggest that it would be better to switch the order of "8.2 Assignments for Existing Algorithms" and "8.1 Assignments for Existing Key Types", since elsewhere in this section the text always talks about algorithms before key types.

In the examples, you may want to remind that the algorithm type is not included in the capability data because it should already be known from elsewhere.

Finally, in the examples, you might wish to rephase to avoid second person language, such as using "you".

Regards,
Rob

> Sent: 18 June 2020 18:55
> I have spent way too long trying to do edits and re-writes and additions
> and deletions on this.  I don't think that I can even read it anymore.
> However, https://cose-wg.github.io/cose-rfc8152bis/draft-ietf-cose-
> rfc8152bis-algs.html#name-cose-capabilities has an updated version of this
> that I think will address all of your comments.  Please review.
> 
> Thanks, Jim
> 
> 
> 
> Hence a clarifying question: Does "the list of capabilities is immutable",
> does it mean that the list of capabilities associated with a given
> algorithm or key structure is immutable?  Or does it mean that the entire
> list of defined capabilities as a set is immutable?
> And in the following paragraph, where is states "The capability structure
> is an array of values" does it mean the capability structure associated
> with a particular algorithm or key?
> [JLS] Yes
> 
> Another question relates to "The capability structure is an array of
> values,", does this mean "The capability structure for a given algorithm
> or key is an ordered array of values, the order ... "
> [JLS] Yes
> 
> The paragraph below also mentions multiple pairs of capability structures.
> Do the capabilities always come as a pair of an algorithm and a key?  If
> there are multiple pairs then how are they encoded, presumably as an array
> of pairs?  If capabilities do not always come as a pair then you do you
> differentiate between a capability defining an algorithm and one defining
> a key?
> 
> >
> Perhaps, but I think that it would also be useful to have an example of
> supporting ECDH-ES with both P-256 and X25519 curves, and how that would
> be encoded (if that makes sense).
> 
> I also couldn't convince myself that the numerical values that are used in
> the examples are necessary right, please can you check that they are.
> E.g., the first two example have the same numeric encoding, and the two
> ECDH-ES have different encodings of the algorithm.  But perhaps that is
> just my confusion about how this works.
> 
> Regards,
> Rob
> 
> 
> >
> > Jim
> >
> > Thanks,
> > Rob
> >
> >
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 25 Jun 2020 11:12:28 -0700

> Sent: Friday, June 19, 2020 8:08 AM
> Sorry, but I'm still struggling to fully understand the capability text.  That may
> be because it is too far out of my domain of expertise, or it may be because the
> text is unclear.  It is also worth noting that I've not read the entire document,
> just the diffs.  Also note that these are just comments intended to help the
> readability of the document, they don't block the progression of the document,
> so the authors are at liberty to ignore them if they choose.

While this is frustrating to me at the moment.  I think we are still making the document better so I am still willing to try and do some slogging through things.

> 
> From the latest text on github, the things that I don't fully understand, or
> potentially find the text somewhat confusing are:
> 
> 
> "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."
> 
> 1. Is the use of a pair of capabilities (algorithm capabilities, key capabilities)
> normative, or just an example usage?  I.e. is this one way that this could be
> achieved, or the only way that this would be achieved.
This is just and example usage.  I am going to reword to talk about combinations rather than pairs.  And point to the cross product structure for the ECDH element in the last example.

> 
> 
> "Just an algorithm capability: This is useful if you want to require a specific
> algorithm such as ECDSA, but you are agnostic about which curve is being used.
> See the first example."
> 
> 2. Is the capability actually saying that a specific algorithm is being used, or is it
> that a particular key type is being used for the algorithm?  [Given that the
> algorithm capabilities don't encode the choice of algorithm.]

]JLS] It is saying the second statement given that the specific algorithm is not part of the capability.   And yes I am beginning to really regret that decision.

> 
> 
> "Just a key type capability: This is useful if you want to require a specific curve
> such as P-256, but will accept any algorithm using that curve (e.g. both ECDSA
> and ECDH). See the second example."
> 
[JLS] Good point - added the text.

> 
> 
> "Both an algorithm and a key type capability: This is used if one needs to nail
> down all of the options surrounding an algorithm E.g. EdDSA with the curve
> X25519. See the third example which just concatenates the two capabilities
> together."
> 
> 4. Am I right to ensure that a separate specification, where the capabilities
> structures are being used, would specify that the capabilities are defined as an
> array of algorithm capabilities followed by key value capabilities. [Related to
> comment 1 above.]

[JLS] That would be one way that it could be used.  If you look at how it is used in draft-ietf-core-oscore-groupcomm, there is an array of multiple items of which one set each of algorithm and key type capabilities are but two of them.  These are then used as part of a key derivation process to make sure that everybody is agreeing on what is being used.  However the view you gave does look like what I did in example 3.

> 
> 
> Nits:
> 
> I would suggest that it would be better to switch the order of "8.2 Assignments
> for Existing Algorithms" and "8.1 Assignments for Existing Key Types", since
> elsewhere in this section the text always talks about algorithms before key
> types.
> 
> In the examples, you may want to remind that the algorithm type is not
> included in the capability data because it should already be known from
> elsewhere.
> 
[JLS]  All of these things are good and done.

Thanks for working with me.

Jim

> > I have spent way too long trying to do edits and re-writes and
> > additions and deletions on this.  I don't think that I can even read it anymore.
> > rfc8152bis-algs.html#name-cose-capabilities has an updated version of
> > this that I think will address all of your comments.  Please review.
> >
> > Thanks, Jim
> >
> >
> >
> > > 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
> > > 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?
> > > never be changed even by IANA.  Thus I believe that the word
> > > immutable seems to be correct.  If this is changed then existing
> > > signatures will fail and key derivation functions will generate different
> results.
> > [RW]
> >
> > Hence a clarifying question: Does "the list of capabilities is
> > immutable", does it mean that the list of capabilities associated with
> > a given algorithm or key structure is immutable?  Or does it mean that
> > the entire list of defined capabilities as a set is immutable?
> > And in the following paragraph, where is states "The capability
> > structure is an array of values" does it mean the capability structure
> > associated with a particular algorithm or key?
> > [JLS] Yes
> >
> > values,", does this mean "The capability structure for a given
> > algorithm or key is an ordered array of values, the order ... "
> > [JLS] Yes
> >
> > Do the capabilities always come as a pair of an algorithm and a key?
> > If there are multiple pairs then how are they encoded, presumably as
> > an array of pairs?  If capabilities do not always come as a pair then
> > you do you differentiate between a capability defining an algorithm
> > and one defining a key?
> >
> > >
> > > duplicated with different "key" entries?  If so, would it help
> > > clarify to explicitly state this?
> > Perhaps, but I think that it would also be useful to have an example
> > of supporting ECDH-ES with both P-256 and X25519 curves, and how that
> > would be encoded (if that makes sense).
> >
> > I also couldn't convince myself that the numerical values that are
> > used in the examples are necessary right, please can you check that they are.
> > E.g., the first two example have the same numeric encoding, and the
> > two ECDH-ES have different encodings of the algorithm.  But perhaps
> > that is just my confusion about how this works.
> >
> > Regards,
> > Rob
> >
> >
> > >
> > > Jim
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> >