Only a few comments, and with one exception only comments on readability. For someone that hasn't a clue what this is about, the first encounter with the term "COSE" (apart from "COSE Working Group" in the header") is just before 1.1:
o "COSE is not a direct copy of the JOSE specification. " - It would be nice if the term "COSE" was first defined in terms of what it is, rather than what it is not. - Should the term "COSE" be used independently at all, or instead always together with some noun as in "COSE Message", "cose type", etc.? In section 2; title is "Basic COSE Structure" but as is explained it is actually about the COSE Message structure. Similarly in section 3 :"The structure of COSE has been designed . . ." Section 2 uses the term "COSE object”, is that different from "COSE Message”? (When referencing the constructs of this draft we consistently used the term "COSE object", since there is often other data included in the actual message being sent.) Section 4.3 "The primary reason for supporting this can be seen by looking at the CoAP message structure [RFC7252] where the facility exists for options to be carried before the payload. An example of data that can be placed in this location would be CoAP options for transaction ids and nonces to check for replay protection. If the data is in the options section, then it is available for routers to help in performing the replay detection and prevention. However, it may also be desired to protect these values so that if they are be modified in transit it can be detected.” To my knowledge, there are no proposed CoAP options for transaction id or nonces, at least not such that are proposed to be integrity protected, but there may be other CoAP options that needs to be integrity protected only. Section 5.2 "The COSE_Encrypt1 encrypted structure does not have the ability to specify recipients of the message. The structure assumes that the recipient of the object will already know the identity of the key to be used in order to decrypt the message. If a key needs to be identified to the recipient, the enveloped structure ought to be used.” One type of compact encryption formats we have looked at has been, essentially: [key identifier, cipher text] (disregarding IV etc.). We would like to use COSE_Encrypt1 which essentially is: [algorithm, cipher text] (disregarding IV etc.). Making algorithm optional is covered in Appendix A. But I read the text above as using this format with a kid header is not possible, is that the intention? I can maybe understand this from a level/layer structure point of, but not really from a security point of view. Section 12.4.1, new bullet is fine, forgot to acknowledge that. Appendix B in particular, but also other parts speak of “levels” and “layers”, which seems like synonyms, or is there a difference? Göran On 2016-06-04 02:51, "COSE on behalf of Justin Richer" <[email protected] on behalf of [email protected]> wrote: >Hi everyone, > >Just a gentle reminder that the WGLC on the COSE Messages draft closes a >week from today, on June 10 2016. Due to timezones, schedules, and the >black art of SMTP delivery, we can't guarantee any particular time >during the day that the call will close. Therefore, if you've got >something to say about the draft, please do so earlier in the week >rather than later. No time like the present! > >The latest draft (12) is here: > >https://tools.ietf.org/html/draft-ietf-cose-msg-12 > >The issue tracker is here (but we'd prefer comments to the list in this >period): > >https://github.com/cose-wg/cose-issues/issues > >Please read and review, and we're even looking for "yup, it looks good >to me" from people if that's your take on things. > >Thanks everyone, > > -- Justin, your COSE chair > >_______________________________________________ >COSE mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
