While this would make the items match, I dont really think that the title you are suggesting is more descriptive than the one I suggested. I am to the point where I am ready to argue with the RFC Editor about the rule of expanding acronyms in the title if the title itself is descriptive of what the document is doing.
Jim From: COSE [mailto:[email protected]] On Behalf Of Mike Jones Sent: Friday, June 10, 2016 4:47 PM To: Jim Schaad <[email protected]>; 'Göran Selander' <[email protected]> Cc: 'Justin Richer' <[email protected]>; [email protected] Subject: Re: [COSE] WGLC, One more week Why not just the title CBOR Object Signing and Encryption (COSE)? Then the title and acronym would match. Mike From: Jim Schaad <mailto:[email protected]> Sent: Friday, June 10, 2016 6:18 PM To: 'Göran Selander' <mailto:[email protected]> Cc: 'Justin Richer' <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [COSE] WGLC, One more week Just this last week I ended up in a situation where somebody used an acronym that I did not understand that highlights one of your points below. Somebody was asking me questions about CEMS and I did not understand until some ways into the conversation that they were referring to "CBOR Encoded Message Syntax". I am reluctant to use CEMS as a short hand for this, in part because it is just too close to CMS and I personally don't want to get confused between the two different specifications when people start asking me questions out of the blue. I have been using the term COSE to refer to this work as a single entity without trying to differentiate between the different structures as JOSE did with the JWS, JWE, JWK, JWE. It is not clear if they use the term JOSE for the overall set of specs within their community or not. I know that I frequently will use it myself when I talk to people. I would like to promulgate the use of COSE as the short hand term for this specification and the follow on work done just like CMS is used for that set of specifications. For that reason, I would like to keep the current set of references to COSE as an item rather than using it as a modifier. I do however think that I need to change the title of the document to make this work. How do people feel about a new title of "COSE: An encryption and signing solution for CBOR". Other notes inline Jim > -----Original Message----- > From: COSE [mailto:[email protected]] On Behalf Of Göran Selander > Sent: Friday, June 10, 2016 9:16 AM > To: Jim Schaad <[email protected] <mailto:[email protected]> > > Cc: Justin Richer <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> > Subject: Re: [COSE] WGLC, One more week > > 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: It is now defined in the introduction. > > 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.) I switch to using COSE object everywhere. > > > 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. I have done a re-write on this > > > > 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. The choice of the word 'ought' was very deliberate. The intention is to say that this is what it is believed should be done, but it is not by any means a statement of requirement. You can violate this without being in violation of the rules, but you should really think about why you are doing it. > > > 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? No they are the same thing. I have harmonized to layers. Jim > > > Göran > > > > > > On 2016-06-04 02:51, "COSE on behalf of Justin Richer" > <[email protected] on behalf of [email protected] <mailto:[email protected]%20on%20behalf%20of%[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] <mailto:[email protected]> > >https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ 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
