Hi Jim, Thanks for the very quick response! Inline.
On Sat, Sep 3, 2016 at 5:59 PM, Jim Schaad <[email protected]> wrote: > > >> -----Original Message----- >> From: COSE [mailto:[email protected]] On Behalf Of Kathleen Moriarty >> Sent: Friday, September 02, 2016 7:58 PM >> To: [email protected] >> Subject: [COSE] AD review of draft-ietf-cose-msg >> >> 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. > > The formatting issues are going to need to be fixed either by the RFC Editor > or by a new fix to xml2rfc. It has to do with the fact that I do a hanging > text list for a sentence rather than for a key word followed by punctuation. > >> >> >> 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. > > Done > >> >> 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). > > Done > >> 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. > > Done > >> >> 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. > > Done > >> >> 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. >> > > Does this work? > o Signed messages distinguish between the protected and unprotected > parameters that relate to the content from those that relate to the signature. Yes, that reads better to me, thank you! > >> 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/ > > Done > >> >> 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. >> > > Done > > >> 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. > > How does this work? > COSE_Sign allows for one or more signatures to be applied to the same > content. Ah, that's better, thank you! > >> >> 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. > > Does this work? > Parameters related to the content and parameters related to the > signature are carried along with the signature itself. Thank you, that helps me. > >> >> 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. > > Done > >> >> 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. … >> > > If I use the section titles it becomes: > Direct Encryption and Direct Key Agreement: ... > I think this might be better - what do you think? Yes, please do expand that, thank you! That makes sense now. :-) > >> 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. > > Done > >> >> 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. > > Done > >> >> *Many of the places where parenthesis are used, it would be better to remove >> them and leave the sentence as part of the paragraph. > > I have included a note to the RFC editor to look at this as an issue. I > think that they should stay as that is the way that I thought it should be at > the time. OK, fair enough. That's a good way to figure out the best solution. Thanks. > >> >> 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. > > Changed to > The current best attack appears to be brute force on the key. Better, thanks! > >> >> 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. > > Changed to > given to message and tag pairs Ah, ok, thanks. At least there was something to fix there ;-) > >> >> 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. > > Done > >> >> 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. > > Done > >> >> 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. > > Done, along with the rest of the cut and pastes from here. Cool, thanks. > >> >> 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 > > Does not appear to be - It is now expanded Great, thanks! Easy to miss this in a big document when text gets moved around. > >> >> 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? > > Does this make more sense? > > It is intended that a profile of this document be created that > defines the interopability requirements for that specific application. > This section provides a set of guidelines and topics that need to be > considered when profiling this document. > Much better, thank you!! > >> >> 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 > > Typo should have been a period. > Done Thanks! > >> >> 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. > > Does this work any better? > > The length of the encoded value should be weighed against how > many code points of that length are left, the capabilities of devices for > expected use, and the number of code points left that encode to that size. Yes, thank you! > >> >> 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. > > Currently it is just as a comment in the XML to the RFC Editor rather than as > explicit text in the document. I think this meets the spirit of the request > in RFC 7942. Ah, ok, so it is meant to be removed. This may come up in the IESG reviews. If it does either one of us can respond quickly. Good to know the intent. I'd be fine with whatever the WG wanted, but need to know what that is, which is why I asked. It helps to have this knowledge ahead of time. > >> >> 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. > > I have just removed the secondary clause entirely. I don't think it helps > anything anymore. OK, thanks. Thank you! I see you have a separate response for the IANA question. I'll try to get back to you tomorrow or Tuesday on that as it is getting late. Have a nice weekend and thanks again for all your work on this. Kathleen > >> >> >> >> Thank you! It's nice to see this get wrapped up in a timely manner. > > Jim > >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose > -- Best regards, Kathleen _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
