-----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.
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?
Jim
Thanks,
Rob
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
