Subject: [COSE] WGLC, One more week

From: Justin Richer <[email-masked]>
Date: Fri, 3 Jun 2016 20:51:32 -0400

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

---

From: Göran Selander <[email-masked]>
Date: Fri, 10 Jun 2016 16:16:05 +0000

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-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>COSE mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cose

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 10 Jun 2016 16:17:59 -0700

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-masked]] On Behalf Of Göran Selander
> Sent: Friday, June 10, 2016 9:16 AM
> To: Jim Schaad <[email-masked]>
> Cc: Justin Richer <[email-masked]>; [email-masked]
> Subject: Re: [COSE] WGLC, One more week
> 
> 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.

> - It would be nice if the term "COSE" was first defined in terms of what it is,
> rather than what it is not.
> 
> In section 2; title is "Basic COSE Structure" but as is explained it is actually about
> the COSE Message structure.
> 
> 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.”
> 
> 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.”
> 
> 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.

> 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

> >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

---

From: Mike Jones <[email-masked]>
Date: Fri, 10 Jun 2016 23:47:11 +0000

Why not just the title CBOR Object Signing and Encryption (COSE)?  Then the title and acronym would match.

– Mike

From: Jim Schaad<mailto:[email-masked]>
Sent: Friday, June 10, 2016 6:18 PM
To: 'Göran Selander'<mailto:[email-masked]>
Cc: 'Justin Richer'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] WGLC, One more week

Other notes inline

Jim

Jim

---

From: Göran Selander <[email-masked]>
Date: Mon, 13 Jun 2016 07:27:44 +0000

On 2016-06-11 01:17, "Jim Schaad" <[email-masked]> wrote:

>>specify
>>would like to
>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.

Some more thoughts on this.

I understand this is not normative.

It sounds like you say it is not recommended (SHOULD NOT) but is allowed
(MAY) given certain important security considerations are made.

- Why not formulate it like that?

- I didn’t find any security considerations specifically on this, but may
have missed them. If they are not already in, I think some considerations
should be included. Comparing with DTLS, there is essentially a Sender ID
(disregarding IV etc.), no algorithm and no enveloped structure. I assume
that DTLS fulfils those security considerations, so maybe that can serve
as a good example?

Since this may be a special case of no algorithm, some text about the case
in question could be included in Appendix A.

Göran

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 13 Jun 2016 15:31:19 -0700

While this would make the items match, I don’t 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-masked]] On Behalf Of Mike Jones
Sent: Friday, June 10, 2016 4:47 PM
To: Jim Schaad <[email-masked]>; 'Göran Selander'
<[email-masked]>
Cc: 'Justin Richer' <[email-masked]>; [email-masked]
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-masked]> 
Sent: Friday, June 10, 2016 6:18 PM
To: 'Göran Selander' <mailto:[email-masked]> 
Cc: 'Justin Richer' <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
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

> To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
> Cc: Justin Richer <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> 
> For someone that hasn't a clue what this is about, the first encounter
with the

> - It would be nice if the term "COSE" was first defined in terms of what
it is,
> In section 2; title is "Basic COSE Structure" but as is explained it is
actually about
> Section 2 uses the term "COSE object”, is that different from "COSE
Message”?

> nonces, at least not such that are proposed to be integrity protected, but
there

specify
would like to
> 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.

> Appendix B in particular, but also other parts speak of “levels” and
“layers”,

Jim

> <[email-masked] on behalf of [email-masked]
<mailto:[email-masked][email-masked]> > wrote:
> >[email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 

_______________________________________________
COSE mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

---

From: Mike Jones <[email-masked]>
Date: Mon, 13 Jun 2016 22:34:12 +0000

I'd be OK with the title "COSE: An encryption and signing solution for CBOR" if in the abstract and/or introduction you somewhere say that "COSE is an acronym for CBOR Object Signing and Encryption" so readers who weren't familiar with the working group know where the name came from.

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, June 13, 2016 3:31 PM
To: Mike Jones <[email-masked]>; 'Göran Selander' <[email-masked]>
Cc: 'Justin Richer' <[email-masked]>; [email-masked]
Subject: RE: [COSE] WGLC, One more week

While this would make the items match, I don't 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-masked]] On Behalf Of Mike Jones
Sent: Friday, June 10, 2016 4:47 PM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; 'Göran Selander' <[email-masked]<mailto:[email-masked]>>
Cc: 'Justin Richer' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] WGLC, One more week

- Mike

Other notes inline

Jim

> To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
> Cc: Justin Richer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> Section 2 uses the term "COSE object", is that different from "COSE Message"?

> detected."

> ought to be used."

> Appendix B in particular, but also other parts speak of "levels" and "layers",

Jim

> <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:
>
> >Hi everyone,
> >
> >[email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose