Hello,
Thank you all for your work on draft-ietf-cose-msg. I mainly have
nits to fix in my comments, which is bound to happen with such a long
draft. Sorry for the time it took to turn this review around.
I haven't looked at the shepherd report yet, but it will need to
include any remaining downrefs - assuming some of the idnits for this
can be cleaned up. The idnits need to be checked as well as there are
some formatting problems that can easily be corrected.
Nits:
Abstract
Change from:
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size. There is a need for the
ability to have the basic security services defined for this data
format.
To:
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.
Introduction:
Change from:
There has been an increased focus on the small, constrained devices
that make up the Internet of Things (IoT).
To:
There has been an increased focus on small, constrained devices
that make up the Internet of Things (IoT).
Change from:
A need exists to provide message security
services for IoT and using CBOR as the message encoding format makes
sense.
To:
A need exists to provide message security
services for IoT, using CBOR as the message encoding format makes
sense.
Section 1.1
Change from:
o Define a single top message structure so that encrypted, signed
and MACed messages can easily identified and still have a
consistent view.
To:
o Define a single top message structure so that encrypted, signed
and MACed messages can easily be identified and still have a
consistent view.
For the following, I am not sure I am parsing this correctly, can it
be rephrased:
o Signed messages separate the concept of protected and unprotected
parameters that are for the content and the signature.
Section 3:
In the 'protected' bucket definition:
change from:
Senders SHOULD encode an zero length map as a zero
length string rather than as a zero length map (encoded as h'a0').
To:
Senders SHOULD encode a zero length map as a zero
length string rather than as a zero length map (encoded as h'a0').
s/an/a/
Change from:
After encoding the map the value is
wrapped in the binary object.
To:
After encoding the map, the value is
wrapped in the binary object.
Section 4: Second sentence:
Can this be reworded from:
COSE_Sign allows
for one or more signers to be applied to a single content.
To: COSE_Sign allows
for one or more signers to be applied to a single piece of content.
It doesn't read well to me, but if that is a well understood way to
phrase this, let me know.
Section 4.1: Can the second "about" be changed to "for" or
"describing"? It took me a few times reading this to get it.
current:
There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.
Section 4.1 middle of second paragraph:
Change from:
Support of different communities of
recipients is the primary reason that signers choose to include more
than one signature.
To:
Support for different communities of
recipients is the primary reason that signers choose to include more
than one signature.
Section 5.4, second bullet #3
Is this intended to be "Direct and Direct"?
Direct and Direct Key Agreement: The key is determined by the
key and algorithm in the recipient structure. …
Section 6.4:
Change from:
How to verify a MAC are:
To:
The steps of how to verify a MAC are:
You don't save a line of text, so it would be better to include what
is needed for it to be easily understood.
Section 9, first paragraph:
Remove the parens and s/One/A MAC/
Change from:
(One cannot, for example, be used to prove the identity
of the sender to a third party.)
To: A MAC cannot, for example, be used to prove the identity
of the sender to a third party.
*Many of the places where parenthesis are used, it would be better to
remove them and leave the sentence as part of the paragraph.
Section 9.1.1: second sentence should be more clear that the "method
is an attack method. How about change from:
The current best method appears to be a
brute force attack on the key.
To:
The current best attack method appears to be
brute force on the key.
Section 9.2.1, first bullet, second sentence:
Remove the last comma.
change from:
If this is not the case, an attacker will be able to
generate a message with a valid tag given two message, tag pairs.
To:
If this is not the case, an attacker will be able to
generate a message with a valid tag given two message tag pairs.
Same section, the second bullet doesn't read well. The current text:
o If the same key is used for both encryption and authentication
operations, using CBC modes an attacker can produce messages with
a valid authentication code.
How about:
o When using CBC mode, if the same key is used for both encryption
and authentication
operations, an attacker can produce messages with
a valid authentication code.
Section 10.2, 4th paragraph, second to last sentence:
Change from (s/user/use/):
Less constrained devices will want to be able to user
larger messages and are more willing to generate new keys for every
operation. This favors larger values of L and M.
To:
Less constrained devices will want to be able to use
larger messages and are more willing to generate new keys for every
operation. This favors larger values of L and M.
Same section, third to last bullet, add "is":
Change from:
o If the 'alg' field present, it MUST match the AES-CCM algorithm
being used.
To:
o If the 'alg' field is present, it MUST match the AES-CCM algorithm
being used.
Section 12.1.2.1
Is PFS spelled out in the draft before this use? Just checking… It
might not be as it appears as "perfect forward secrecy (no
abbreviation) and RFC4949 in section 12.4
Section 15, second paragraph:
It reads oddly to me…
Applications are therefore intended to profile the usage of this
document. This section provides a set of guidelines and topics that
applications need to consider when using this document.
What do you mean by 'profile the usage'? Should this be worded differently?
Section 16.2
I think it's a little confusing to state the registry values require
expert review, then buried in the 'label' description say it can be
specification required. Wouldn't it be more clear to state that a
dependency exists and a specification is required in the intro
paragraph for this section? This applies to the other sections that
also require a specification as it don't seem that all registries do.
Section 16.7
There is a spurious > character
It is requested that IANA create a new registry "COSE Key Type
Registry"> The
Section 16.11, third bullet: Can you rephrase the following sentence,
it could read better:
Some
of the ranges are restricted in range, items that are not expected
to be common or are not expected to be used in constrained
environments should be assigned to values which will encode to
longer byte strings.
Section 17.
I don't see theft that says this section should be removed upon
publication. Is it supposed to be retained in the document? Just
checking as I thought the boiler plate for this has them being
removed.
Section 18: This bullet is difficult to read, is it missing an "or"?:
o Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm, either directly in a separate message,
exposes the direct key to the second recipient.
How about:
o Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm, either directly or in a separate message,
exposes the direct key to the second recipient.
Thank you! It's nice to see this get wrapped up in a timely manner.
--
Best regards,
Kathleen
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
