Hi Jim, Please see inline ...
> -----Original Message----- > From: Jim Schaad <[email protected]> > Sent: 10 June 2020 00:13 > To: Rob Wilton (rwilton) <[email protected]>; 'The IESG' <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; 'Matthew Miller' <[email protected]> > Subject: RE: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis- > algs-09: (with COMMENT) > > > > -----Original Message----- > From: Robert Wilton via Datatracker <[email protected]> > Sent: Tuesday, June 9, 2020 11:16 AM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; Matthew Miller <[email protected]>; > [email protected] > Subject: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs- > 09: (with COMMENT) > > 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). > [JLS] Fixed in reply to Roman's comment. > > 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. > [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 > > The concept is being pulled forward and defined now for > COSE. > > 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 > > 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. > [JLS] This has already been changed in response to Roman. > > 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? > [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? > > 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"? > [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? [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 > > Jim > > Thanks, > Rob > > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
