Subject: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt

From: "Jim Schaad" <[email-masked]>
Date: Sun, 7 Feb 2016 20:29:09 -0800

This version should address all of the open issues in the tracker except for the optional algorithm pair of items (#51 and #52).
There are two issues that are still  unmarked as resolved that are probably not of great importance

#54 is only important to the OSCoAP people if they are not planning to use the CBOR content type option
#53 went out for comment at the start of January and gathered crickets (except for a comment of that would be nice from Stephen Ferrell).

Ilari - Once upon a time you made a comment about the context structure and the header fields that can optionally be used for population of it.  I have since done a couple of passes trying to do a re-write on it to make things clearer.  Can you please check if your issue (current CREF2) has been resolve?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, February 07, 2016 8:22 PM
> To: Jim Schaad <[email-masked]>
> Subject: New Version Notification for draft-ietf-cose-msg-10.txt
> 
> 
> A new version of I-D, draft-ietf-cose-msg-10.txt has been successfully submitted
> by Jim Schaad and posted to the IETF repository.
> 
> Name:		draft-ietf-cose-msg
> Revision:	10
> Title:		CBOR Encoded Message Syntax
> Document date:	2016-02-07
> Group:		cose
> Pages:		105
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-10.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-cose-msg/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-cose-msg-10
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-10
> 
> Abstract:
>    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.  This document specifies processing for signatures, message
>    authentication codes, and encryption using CBOR.  This document also
>    specifies a representation for cryptographic keys using CBOR.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Justin Richer <[email-masked]>
Date: Mon, 8 Feb 2016 08:19:06 -0500

Hello everybody,

Please review the list of completed issues in the tracker against the 
new version of the document:

https://github.com/cose-wg/cose-issues/issues?q=is%3Aissue+is%3Aopen+label%3AComplete

We will close all issues marked as "Complete" in one week if there is no 
contention on the issue.

  -- Justin, your COSE chair

On 2/7/2016 11:29 PM, Jim Schaad wrote:
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 8 Feb 2016 17:32:59 +0200

On Sun, Feb 07, 2016 at 08:29:09PM -0800, Jim Schaad wrote:
> 
> Ilari - Once upon a time you made a comment about the context
> structure and the header fields that can optionally be used for
> population of it.  I have since done a couple of passes trying
> to do a re-write on it to make things clearer.  Can you please
> check if your issue (current CREF2) has been resolve?

Looks decent... Maybe table 13 could be moved up just under the
reference to it, so the CBOR encoding description isn't between
table and reference to it?

-Ilari

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 12 Feb 2016 16:16:58 +0000

Hi Jim and all,

I have quickly reviewed the last version of the draft and I have a couple of remarks.
Most of them are editorial and typos I noticed, but I also have some more important questions.

Starting with the Important Stuff:

In our Object Security implementation, we use an identifier that identifies a set of parameters related to protection of the message, as for example algorithm, replay protection parameters, keys (possibly more than one) and others. We call this "Context Identifier". This parameter is sent in the message.
Following many discussion (live and by mail), we agreed on using the COSE "kid" parameter to contain this identifier, and we haven't gotten any objection for it.
Now, while reviewing the last version of the draft, I noticed in the kid definition (Section 3.1):

"The value of this parameter is matched against the 'kid' member in a COSE_Key structure."

This is clearly non-compliant with our use of the "kid" header field. I see three solutions to solve this:
-	Have a new parameter that complies with our context identifier (more general identifier for security related set of parameters)
-	"Soften" the definition of "kid": in practical terms, modify this sentence so to have what was the previous version:

"The value of this parameter _can be_ matched against the 'kid' member in a COSE_Key structure."

-	Add an appendix about the use of the "kid", explaining that it can be used in other ways (although this is not the "default" use).

Second question: I didn't see any decision about alg. Is there finally going to be an appendix considering the case where alg is omitted from the COSE message and following considerations about it?

The editorials comments:

Section 2: 
point 4: consider replacing "in a CoAP message" with "in a CoAP payload" if you mean Content-Format by content type parameter.

Section 3: 
"[...] most of the algorithms that are used for recipients do not provide for authenticated data and thus the bucket should not be used." Missing word(s)?

Section 3.1:
"This parameter one of the ways that can be used to find the key to be used." Missing word(s)?

Section 4.1:
"[...] and a counter- signature." Shouldn't it be "and the counter- signature" (if it is an example of parameter about the signature)? Otherwise it is unclear.

Section 4.3:
"so that if they cannot be modified in transit it can be detected." Replace "cannot be" with "are".

signing and verification = very clear
Section 4.4:
    point 4. of signing: consider adding the sentence: "(See Section 4.3 for application guidance on constructing this field.)" as it is done in section 5.2 point 4.
    point 4. of verifying: about the text "Place the resulting signature value in the 'signature' field of the map.", this is correct for COSE_Signature, but COSE_Sign1 is not a map.

Section 4.5:
"This means that the Sig_structure can be used for in a uniform manner to get the byte stream for processing a signature." Delete first "for"?

Section 5.2: 
"Examples of encrypted messages can be found in Appendix C.3." Should be C.4

Section 5.3
Is it possible to get section 5.3 similar in structure to 4.4 and 6.3? I would like the numbered list to be the order of the fields in the array (take out the text in point 1.)
    Point 5. "Encode the Enc_structure using a CBOR Canonical encoding Section 14 to get the AAD value."  Reference in parenthesis?
There is no "decryption/verification" section following encryption. Can you add some specification about that? (Analogous to the verification part of Section 4.4)

Section 6.3:
Same here, there is no verification section for MAC either. Can you add some specification about that?

Section 15: 
"Applications need to determine the set of messages defined in this document that it will be using." replace "it" with "they" (or "An application needs ..."
"When applications use externally defined authenticated data, they need to define how that data is to be defined." Consider replace "is to be defined" with "is to be constructed" (sounds better to me)

Section 17:
"While some considerations have been highlighted here, additional considerations may be found in the documents referred to that have full details of the algorithm." Not very clear to me, maybe add a comma after "referred to"? Or consider rephrasing.
"Using a the same key for two different algorithms can leak" Remove "a".
"A number of factors are assoicated with this trust decision." I think you meant "associated"
"What are the permissions assoicated with the key owner?" Same here.
"been checked are are correct?" Probably "and are correct"

General:
Consider adding references to examples in Appendix C.2 and C.6 (There is no reference to these examples in the text).

Otherwise, closed issues are OK.

Best regards,
Francesca

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: den 8 februari 2016 14:19
To: [email-masked]
Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt

Hello everybody,

Please review the list of completed issues in the tracker against the new version of the document:

We will close all issues marked as "Complete" in one week if there is no contention on the issue.

On 2/7/2016 11:29 PM, Jim Schaad wrote:
>> A new version of I-D, draft-ietf-cose-msg-10.txt has been 
>> successfully submitted by Jim Schaad and posted to the IETF repository.
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 12 Feb 2016 11:32:19 -0800

> From: COSE [mailto:[email-masked]] On Behalf Of Francesca Palombini
> Sent: Friday, February 12, 2016 8:17 AM
> To: Justin Richer <[email-masked]>; [email-masked]; Jim Schaad
> <[email-masked]>
> I have quickly reviewed the last version of the draft and I have a couple
of
> remarks.
> In our Object Security implementation, we use an identifier that
identifies a set
> of parameters related to protection of the message, as for example
algorithm,
> replay protection parameters, keys (possibly more than one) and others. We
call
> this "Context Identifier". This parameter is sent in the message.
> Following many discussion (live and by mail), we agreed on using the COSE
"kid"
> parameter to contain this identifier, and we haven't gotten any objection
for it.
> Now, while reviewing the last version of the draft, I noticed in the kid
definition
> (Section 3.1):
> 
> "The value of this parameter is matched against the 'kid' member in a
COSE_Key
> structure."
> 
> This is clearly non-compliant with our use of the "kid" header field. I
see three
> solutions to solve this:
> -	Have a new parameter that complies with our context identifier (more
> general identifier for security related set of parameters)
> -	"Soften" the definition of "kid": in practical terms, modify this
sentence
> so to have what was the previous version:
> 
> "The value of this parameter _can be_ matched against the 'kid' member in
a
> COSE_Key structure."

I don't see this as a problem.  We can easily relax the

> 
> -	Add an appendix about the use of the "kid", explaining that it can
be
> used in other ways (although this is not the "default" use).
> 
> Second question: I didn't see any decision about alg. Is there finally
going to be
> an appendix considering the case where alg is omitted from the COSE
message
> and following considerations about it?

As noted in the last mail I sent out, I am working on this as we speak.

> 
> The editorials comments:
> 
> Section 2:
> point 4: consider replacing "in a CoAP message" with "in a CoAP payload"
if you
> mean Content-Format by content type parameter.
> 
> Section 3:
> "[...] most of the algorithms that are used for recipients do not provide
for
> authenticated data and thus the bucket should not be used." Missing
word(s)?
> 
> Section 3.1:
> "This parameter one of the ways that can be used to find the key to be
used."
> Missing word(s)?
> 
> Section 4.1:
> "[...] and a counter- signature." Shouldn't it be "and the counter-
signature" (if it
> is an example of parameter about the signature)? Otherwise it is unclear.
> 
> Section 4.3:
> "so that if they cannot be modified in transit it can be detected."
Replace
> "cannot be" with "are".
>     point 4. of signing: consider adding the sentence: "(See Section 4.3
for
> application guidance on constructing this field.)" as it is done in
section 5.2 point
> 4.
>     point 4. of verifying: about the text "Place the resulting signature
value in the
> 'signature' field of the map.", this is correct for COSE_Signature, but
COSE_Sign1
> is not a map.
> 
> Section 4.5:
> "This means that the Sig_structure can be used for in a uniform manner to
get
> the byte stream for processing a signature." Delete first "for"?
> 
> Section 5.2:
> Is it possible to get section 5.3 similar in structure to 4.4 and 6.3? I
would like the
> numbered list to be the order of the fields in the array (take out the
text in point
> 1.)
>     Point 5. "Encode the Enc_structure using a CBOR Canonical encoding
Section
> 14 to get the AAD value."  Reference in parenthesis?
> There is no "decryption/verification" section following encryption. Can
you add
> some specification about that? (Analogous to the verification part of
Section
> 4.4)
> 
> Section 6.3:
> Same here, there is no verification section for MAC either. Can you add
some
> specification about that?
> 
> Section 15:
> "Applications need to determine the set of messages defined in this
document
> that it will be using." replace "it" with "they" (or "An application needs
..."
> "When applications use externally defined authenticated data, they need to
> define how that data is to be defined." Consider replace "is to be
defined" with
> "is to be constructed" (sounds better to me)
> 
> Section 17:
> "While some considerations have been highlighted here, additional
> considerations may be found in the documents referred to that have full
details
> of the algorithm." Not very clear to me, maybe add a comma after "referred
> to"? Or consider rephrasing.
> "A number of factors are assoicated with this trust decision." I think you
meant
> "associated"
> Consider adding references to examples in Appendix C.2 and C.6 (There is
no
> reference to these examples in the text).
> 

I will go through the rest of these over the weekend.

Jim

> Please review the list of completed issues in the tracker against the new
version
> of the document:
> 
> https://github.com/cose-wg/cose-
> issues/issues?q=is%3Aissue+is%3Aopen+label%3AComplete
> 
> > This version should address all of the open issues in the tracker except
for the
> optional algorithm pair of items (#51 and #52).
> > #53 went out for comment at the start of January and gathered crickets
> (except for a comment of that would be nice from Stephen Ferrell).
> >
> > Ilari - Once upon a time you made a comment about the context structure
and
> the header fields that can optionally be used for population of it.  I
have since
> done a couple of passes trying to do a re-write on it to make things
clearer.  Can
> you please check if your issue (current CREF2) has been resolve?
> >
> > Jim
> >
> >
> >> URL:
https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-10.txt
> >> Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-10

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Feb 2016 22:04:36 -0800

Except for the issue of the new appendix A the pull request @
https://github.com/cose-wg/cose-spec/pull/140  

There are a couple of notes below, but I did not comment on anything that
was not odd.

Jim

of
identifies a set
algorithm,
call
"kid"
for it.
definition
COSE_Key
see three
sentence
a
> COSE_Key structure."

I have modified this.

be
> used in other ways (although this is not the "default" use).

I don't think an appendix is a reasonable option for this.  I have added an
application specific comment to the description of 'kid' instead

going to be
message
if you
for
word(s)?
used."
signature" (if it
> is an example of parameter about the signature)? Otherwise it is unclear.

I have been going back and forth on the question of counter signatures.
There is no reason, in theory, that there cannot be more than one counter
signature and the current syntax allows for this (oops - only in one place)
but I did change the sentence.

Replace
for
section 5.2 point
value in the
COSE_Sign1
> is not a map.

Actually, map is wrong for both of them.

get
would like the
text in point
Section
you add
Section
some
document
..."
defined" with
details
meant
no
version
for the
and
have since
clearer.  Can