Lots of comments inline. I have removed some of the things that seem to be closed.
Jim From: COSE [mailto:[email protected]] On Behalf Of Samuel Erdtman Sent: Tuesday, August 02, 2016 3:22 PM To: Jim Schaad <[email protected]>; Göran Selander <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] draft-ietf-cose-msg-15 review Thanks for the quick reply Jim, I have fond another thing I want to ask about and then I have added comments inline. I added you Göran in direct message because I had a question on a formulation that you had requested, search for your name in the response form Jim and you´ll find the question. I might just be lacking in CBOR skills but to see it seems like an inconsistency 3. Header Parameters “Senders SHOULD encode an empty protected map as a zero length binary object (i.e., the byte string h'a0'). This encoding is used because it is both shorter and the version used in the serialization structures for cryptographic computation.” Does it help if this is re-written as: Senders SHOULD encode an empty protected map as a zero length binary (encoding h’40’) rather than as a zero length map wrapped in a binary (encoding h’41a0’). The zero length binary encoding is preferred because it is both shorter and is the encoding used in the serialization structures for cryptographic computation. This fixes my CBOR encoding error as well as presenting both of the encodings so it is clear what is being discussed. Here it says that I should use the “zero length binary object” since it is the form used in “the serialization structures for cryptographic computation.”, but in section “4.4. Signing and Verification Process” and “6.3. How to compute and verify a MAC” it says when creating the MAC_structure or Sig_structure: “The protected attributes from the COSE_MAC structure. If there are no protected attributes, a zero length bstr is used.” and “The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used.” //Samuel On Sun, Jul 31, 2016 at 10:14 PM, Jim Schaad <[email protected] <mailto:[email protected]> > wrote: First, thanks for the review comments. It is never too late until the RFC is actually published and even then a new version can be published to address future issues. Individual comments inline Jim From: Samuel Erdtman [mailto:[email protected] <mailto:[email protected]> ] Sent: Sunday, July 31, 2016 12:42 AM To: cose <[email protected] <mailto:[email protected]> >; Jim Schaad <[email protected] <mailto:[email protected]> > Subject: draft-ietf-cose-msg-15 review Hi I after reading the specification a second time and started on a JavaScript implementation things are starting to make sense and I like it. Maybe a bit long (feels like a mountain to climb) before starting to work with it. However well done Jim and all others that has contributed. I like the combination of prose and CDDL, it is great to have the same thing described in two ways. If it´s not to late I would like to contribute with a set of comments. == General comments * Encryption section, 5, was harder to read then Signing, section 4, and Mac, section 6. It felt a more mixed up, but I don’t have any concert suggestions that would make it much better. [JLS] I have a feeling that this is because of the recursive nature of how encryption is done. Mac does not suffer from that because all of the recipient processing is covered in encryption. Without a specific suggestion it is hard to figure out what to do. It will be interesting to see if others have suggestions. I´ll reread and think about it. === 3.1. Common COSE Headers Parameters * Why is some of the headers shortened (alg, crit) but not all (content type)? I would prefer if we could map as close to JOSE as possible and I would also like to avoid spaces in the names because then I can very easily do JSON input to my implementation and have it do the transformation of labels from strings to integers. When reading more I see that this applies to more sections. [JLS] I have kept the same names where it seemed reasonable, but used new names where it seemed more appropriate. For 'content type', what is defined here does not have an exact match in the JWS world. It ends up combining some of both the 'typ' and 'ctyp' fields of JOSE. If you have a JWT, then I have been told you put that into the 'typ' field of JWS, but it goes into the 'content type' field of COSE. The other two which have spaces in them do not have a counterpart in JOSE. However, given that the string names are just for discussion purposes I am not sure that using really short names is generally a good way to go. Would it not make sense then to have no shortened names. If I understand things correctly all labels have descriptions in the specification, there is no labels where we just refer to the JOSE description. I don´t really need the shortening, what i need/want is names I can use directly in variable/constant names. In the implementation I´m working on I try to keep the user from knowing about the integer labels, letting the library do the translation to and from names and then it would be more convenient if the names where possible to user directly as variables/constants i.e. no spaces in the names. [JLS] I kept the short names for compatibility with JOSE so that people would transition faster. However, if people thing we should I have no problems with moving to longer names in all cases. “(The algorithm range is -1 to -65536; the higher end is for more optional algorithm specific items.)” * How does this relate to “Integer labels in the range -1 to -255 can be omitted”? * With the “higher end” are you referring to -1? it seem strange to have the more optional parameters in that end to me [JLS] The intention is to say greater in absolute magnitude. If you have a better term then please share it. Smaller and lower seem to have the same problem as higher does. That is a challenge, when I read it again I see two other problems what does "more optional" meed and where is the breaking point between more and less optional items (similar to 1024 for TCP and UDP ports). Maybe it would be okay to remove the content of the parentheses. [JLS] OK – I am going to re-write this because it is just too hard to keep as it is. New text will be: Integer label sin the range -1 to -128 can be omitted as they are algorithm dependent. If an application can correctly process an algorithm, it can be assumed that it will correctly process all of the common parameters associated with that algorithm. Integer labels in the range of -129 to -65536 SHOULD be included as these would be less common parameters that might not be generally supported. <back to message> One of the ways that this might be implemented would be to add two new parameters in the future to do something similar to draft-selander-ace-cose-ecdhe, but without the worry about doing PFS. We would define the following algorithm dependent items: ECDH-SS-Assign-Key-With-kid ECDH-SS-Set-Key-Lifetime When these items are used, the resultant key from the key agreement step would be named with a kid and potentially given a lifetime (either in messages or time) and then used in a sequence of future messages until such a time as it expires. The static-static ECDH would provide the needed information to do authorization which can then be placed on the short time key. If a client wants to use this feature, it could then put the new attributes in the ‘crit’ field and know that the server would reject the message if it does not support them. Alternatively, it could just try and use them and hope for the best in terms of trying to figure out if they are supported. A returned message might indicate that the assign kid attribute is supported, but it would not indicate if the key lifetime attribute is also supported. “As the IV is authenticated by the encryption process, it SHOULD be placed in the unprotected header bucket.” * Is there a good reason for this SHOULD? why is it better to put it in the unprotected header? if I could I would put all my headers in the protected and not have to bother with the unprotected part. I would prefer the phrasing under Partial IV to be “As the IV is authenticated by the encryption process, this value can be placed in the unprotected header bucket” [JLS] The strengthening of this statement was made at the request of Göran so he should probably respond. === 5.1. Enveloped COSE Structure * This might have been up before, but has it been considered to swap place of ciphertext and recipients so that not the full message has to be received before the CEK can be retrieved and maybe the ciphertext can be decrypted as the message is received. [JLS] No that was never discussed. Given that we are focused on small messages I don't think that it would be a big win given that it would make the processing of the encryption structures more complicated. If that is something that is desired, I would recommend that such an application uses a detached content and send the COSE structure followed by the ciphertext stream. Seems reasonable I thought about the added code complexity but not about the detached solution. * I cannot se any language on the key format in the recipients structure is is always a COSE key? should the content type header be used to describe the key format? or is it implicitly known by the application context? [JLS] There is no format for a key, it is a binary value. You are the second person who seem to think it should be structured content. Please let me know what in the text made you think this as it is clearly not sufficiently explicit. Not sure, I think I noted it when implementing (or thinking about) and had to understand how to take the decrypted CEK and input it to the underlying crypto engine. When implementing both sides i would know the format i.e. application context but if I would like to be more flexible and support to handle different key formats (e.g. in a server) then I would need to know the format of the key, right? [JLS] You are overthinking the problem. We only transport binary secrets within the encrypted content portion of a recipient structure. We do not transport EC or RSA keys here. I think that I am going to look at modifying the description of ciphertext in the recipient structure. === 7. Key Objects * The CDDL example looks different, in my opinion worse, compared to the other earlier examples. [JLS] This was done in response to an earlier review where it was noted that the strings in the CDDL and the strings in the text did not match. Since the numbers are not the same, even though the strings are it was deemed better to remove the strings from the CDDL than to rewrite all of the text which would have had other problems. Okay, so if I understand it correctly there kty, kid etc. has other numeric label values in other context so to have the string in the CDDL might confuse since it is translated to other numeric values. Not sure I agree with earlier reviewer but okay. Why is it not possible to use the same numeric lable for kty, kid, etc in all places? [JLS] It would be possible to do that for the items assigned in this document. However, these are kept in different registries and could easily diverge in the future. Having a difference today can be thought of as a way of making sure people are prepared for problems in the future. If people really want to harmonize them I would not object. === 17.2. COSE Testing Library I would prefer test vectors in the specification compared to this github link. [JLS] You were complaining earlier about the length of the document already. If you want a printed RFC which contains the broken out examples then argue for that on the list, but I prefer having it outside of the document as it makes things easier to correct if they are wrong. Also if you look at the github link you will see that there are lot of examples which are not in this document as it can be much more complete. Okay, and you have created a great number of examples on the github pages, which is awesome, I have not yet understood exactly how I would use them but I guess I will by spending some time on it. [JLS] If there is anything that I can do to make things clearer, please be sure and let me know. One of the things that should be on my list is to provide a better description of the JSON structure for the examples. I am not sure if it is really self-explanatory or not. Also, please let me know if you think the organization can be improved or if there are missing examples. Jim Jim _______________________________________________ COSE mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
