Subject: [secdir] secdir review of cose-msg-18

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Sep 2016 10:26:36 -0400

SECDIR review of draft-ietf-cose-msg-18

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.These comments were written with the intent of improving security 
requirements and considerations in IETF drafts.Comments not addressed in 
last call may be included in AD reviews during the IESG review.Document 
editors and WG chairs should treat these comments just like any other 
last call comments.

This document defines formats for signing and/or encryption of data 
encoded using CBOR (RFC7049). The signing/encryption approach adopted 
here is based on the standards developed in JOSE (RFCs 7515-18), since 
CBOR is based on JSON.

This is a large document: about 90 pages plus almost 30 pages of 
appendices (providing useful examples). Close to half of the 
(non-appendix portion) document is devoted to specifications for a set 
of algorithms for encryption, signatures, message authentication, and 
key distribution. Only when the reader reaches page 73 is it made clear 
that the algorithm descriptions are not MTI; they define a set from 
which application developers must (?) choose when creating a profile for 
COSE use in a specific application context. Given the long-standing IETF 
policy to trying to facilitate algorithm agility,

I think it preferable to extract these descriptions and publish them as 
separate RFCs, a practice often employed in documenting many other 
security protocols (including JOSE, from which this work is based).

The document begins with a brief explanation of how COSE differs from 
JOSE, an excellent preface to the document. The cited design differences 
all seem very appropriate for CBOR, e.g., using binary encoding instead 
of base64url, shedding some of the odd constraints adopted in JOSE 
because of pre-existing work in the area, and updating the list of 
algorithms.

Since there is no standard grammar for CBOR, the author adopted the 
primitive types defined in an I-D (draft-ietf- 
greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of 
COSE formats. I recommend that this document be held for publication 
until that I-D is approved. I also note that the cited I-D is 
Informational, but this document is Standards Track. the cited I-D is 
listed as informative, but the syntax it defines is used extensively 
throughout this document, thus I believe it really is normative.

Section 2 defines the basic COSE data structure. The description seems 
clear and logical, but the list of message types is a bit puzzling 
(absent information that is provided later, in Sections 4 and 5). For 
example, there is a Single Signer data Object, and a Signed Data Object. 
If the latter accommodates multiple signers, why not make that part of 
the name? The same nomenclature confusion arises for encrypted objects 
directed to a single recipient vs. multiple recipients.

Section 3 Describes the header parameters. It provides generally good, 
detailed descriptions of the common header elements and explains why 
certain conventions are adopted. It clearly describes requirements 
imposed on senders and recipients.

Section 4 describes the objects used to convey one or more signatures 
for objects. The description here is a bit confusing when it discusses 
one vs. multiple signatures. The format that allows carriage of multiple 
signatures does not necessarily imply that there are multiple signers, 
e.g., the multiple signatures may be present to accommodate different 
algorithm capabilities for different recipients. The introduction to 4.2 
says:

“The COSE_Sign1 signature structure is used when only one signer is 
going to be placed on a message.”

Perhaps it would be clearer to say that this structure is used when only 
one _signature is to be placed in_ a message.

Overall this section is well written and provides useful details about 
how to compute signatures and counter signatures.

Section 5 describes the COSE encryption objects. I disagree with one 
choice of terminology adopted here: “recipient algorithm classes” which 
is described in 5.1.1. This is really a discussion of classes of key 
distribution/management algorithms, focusing on how each recipient of an 
encrypted message acquires the CEK used to decrypt the message. I’d 
prefer a less obscure name for this sub-section. Otherwise this section 
is well written and provide lots of useful details about how to encrypt 
and decrypt messages for two classes of encryption algorithms.

Section 6 describes the MAC objects. Here too there are two types of 
structures, depending on whether a recipient implicitly knows what key 
to use to verify the MAC, or whether an ID for one or more MAC keys must 
be communicated. The text here closely parallels that of Section 5 and 
is very good.

Section 7 describes the COSE key structure. It is designed to 
accommodate the data needed by a wide range of key distribution 
mechanisms and encryption techniques.

Section 8 defines two classes of signature algorithms that can be used 
with COSE, specifies an algorithm of each type, and provides security 
guidance for each algorithm. I think it would be preferable to remove 
the detailed algorithm descriptions (Sections 8.1 and 8.2) and 
associated security considerations (which are well written) from this 
document. The comments below apply to sections 9, 10, 11 and 12.

I have several concerns about including the algorithm (vs. algorithm 
class) descriptions here. For many security protocols (and 
security-focused data formats), we usually (though not always) specify 
mandatory and optional to implement algorithms in separate documents, to 
facilitate algorithm agility. I think we should follow that model for 
COSE. Also, the text here does not mandate support for these algorithms; 
it merely provides details for a set of algorithms that a sender and/or 
receive may choose to implement. One has to read the final sentence of 
the opening paragraph of Section 15 to learn that this is the intent, 
i.e., that selection of specific algorithms is deferred to the each 
application that makes use of COSE. Given that later statement, it 
appears that the algorithms specified in Sections 8-12 ate intended to 
define the set from which application developer MUST choose, but that 
too is not clearly stated. I think this makes it even more appropriate 
to remove the detailed algorithm discussions from this document.

Section 12 describes the “recipient algorithm classes” aka key 
distribution/management methods. Most of this section is analogous to 
the preceding sections (9-11) where specific algorithms are described 
for use with COSE, and thus my comments about undue bundling of 
algorithms with a protocol specs apply here too. I do not object to 
describing key transport, key wrapping and key agreement methods in 
general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem 
inappropriate here, for the reasons noted above.

Section 13 describes parameters for key objects used by COSE. The specs 
here are sufficiently generic that they do not suffer from the problems 
I noted for Sections 8-12.

Section 15 provides guidance for application developers making use of 
COSE. This is where a reader finally discovers that the algorithms 
described in Sections 8-12 are not MTI, and that each application is 
expected to specify which algorithms are MTI in that context, to 
facilitate interoperability.

Section 16 (IANA Considerations) describes the registries that need to 
be created for COSE, and extensions to the CoAP registry to support 
COSE. It seem to be well written and comprehensive.

Section 18 (Security Considerations) is a good adjunct to the already 
well-written security considerations discussions provided for the 
algorithms in Sections 8-12.

*Typos and suggested rewording.*

Section 2:

The COSE object structure is designed so that there can be a large 
amount of common code when parsing and processing the different

security messages.

-> The COSE object structure is designed so that there can be a large 
amount of common code when parsing and processing the different types of 
security messages.

COSE messages are also built using the concept of using layers to …

-> COSE messages are built using the concept of layers to …

Section 3:

The integer and string values for labels has been divided …

-> The integer and string values for labels have been divided …

Applications SHOULD perform the same checks that the same label …

-> Applications SHOULD verify that the same label …

Applications should have a statement if the label can be omitted.

-> Applications SHOULD (?) have a statement if the label can be omitted.

Integers are from the "CoAP Content-Formats" IANA registry table. (no 
reference)

As the IV is authenticated by the encryption process, it can be placed 
in the unprotected header bucket. (in general, an encryption process 
will not “authenticate” an IV, but use of a modified IV will yield 
mangled plaintext, which can be detected by an integrity check or a 
signature. the same comment applies to the similar statement in the 
“partial IV” description.)

Section 4:

Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with 
the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm.

-> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the 
Elliptic Curve Digital Signature Algorithm (ECDSA) (cite).

One of the features supplied in the COSE document is the ability…

-> One of the features offered by the COSE format is the ability …

This algorithm takes in the body information …

-> The signing and verification processes take in the body information …

Counter signatures provide a method of having a different signature 
occur on some piece of content.

-> Counter signatures provide a method of associating different 
signatures generated by different signers with some piece of content.

Section 5

Other:The key is randomly generated.

-> Other:The key is randomly or pseudo-randomly generated.

Section 6

(This knowledge of sender assumes that there are only two parties 
involved and you did not send the message yourself.)

-> (This knowledge of sender assumes that there are only two parties 
involved and you did not send the message to yourself.)

Section 15:

It is intended that a profile of this document be created that

defines the interopability

-> It is intended that a profile of this document be created that

defines the interoperability

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Sep 2016 12:40:40 -0400

Hi Steve,

Thank you very much for your detailed review, it's helpful.  I'll
respond on the normative/informative question, the chairs and/or Jim
should respond on your other questions as some (like removing text)
may not be done as I believe it was WG consensus to have the content
you mention in this draft.  The nits are helpful too, so Jim will add
those into the next revision.

On Wed, Sep 21, 2016 at 10:26 AM, Stephen Kent <[email-masked]> wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving security requirements and
> considerations in IETF drafts.  Comments not addressed in last call may be
> included in AD reviews during the IESG review.  Document editors and WG
> chairs should treat these comments just like any other last call comments.
>
>
>
> This document defines formats for signing and/or encryption of data encoded
> using CBOR (RFC7049). The signing/encryption approach adopted here is based
> on the standards developed in JOSE (RFCs 7515-18), since CBOR is based on
> JSON.
>
>
>
> This is a large document: about 90 pages plus almost 30 pages of appendices
> (providing useful examples).  Close to half of the (non-appendix portion)
> document is devoted to specifications for a set of algorithms for
> encryption, signatures, message authentication, and key distribution. Only
> when the reader reaches page 73 is it made clear that the algorithm
> descriptions are not MTI; they define a set from which application
> developers must (?) choose when creating a profile for COSE use in a
> specific application context. Given the long-standing IETF policy to trying
> to facilitate algorithm agility,
>
> separate RFCs, a practice often employed in documenting many other security
> protocols (including JOSE, from which this work is based).
>
>
>
>
>
> The document begins with a brief explanation of how COSE differs from JOSE,
> an excellent preface to the document. The cited design differences all seem
> very appropriate for CBOR, e.g., using binary encoding instead of base64url,
> shedding some of the odd constraints adopted in JOSE because of pre-existing
> work in the area, and updating the list of algorithms.
>
>
>
> greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of COSE
> formats. I recommend that this document be held for publication until that
> I-D is approved. I also note that the cited I-D is Informational, but this
> document is Standards Track. the cited I-D is listed as informative, but the
> syntax it defines is used extensively throughout this document, thus I
> believe it really is normative.

The reference is fine as informative IMO as it is clearly stated in
the draft in Section 1.3:

       "The CDDL grammar is informational, the prose description is normative."

This is common and we've seen many drafts using UML descriptions and
other formats similarly.

Thank you,
Kathleen

>
>
>
>
>
> Section 2 defines the basic COSE data structure. The description seems clear
> and logical, but the list of message types is a bit puzzling (absent
> information that is provided later, in Sections 4 and 5). For example, there
> is a Single Signer data Object, and a Signed Data Object. If the latter
> accommodates multiple signers, why not make that part of the name? The same
> nomenclature confusion arises for encrypted objects directed to a single
> recipient vs. multiple recipients.
>
>
>
>
>
> detailed descriptions of the common header elements and explains why certain
> conventions are adopted. It clearly describes requirements imposed on
> senders and recipients.
>
>
>
>
>
> Section 4 describes the objects used to convey one or more signatures for
> objects. The description here is a bit confusing when it discusses one vs.
> multiple signatures. The format that allows carriage of multiple signatures
> does not necessarily imply that there are multiple signers, e.g., the
> multiple signatures may be present to accommodate different algorithm
> capabilities for different recipients. The introduction to 4.2 says:
>
> Perhaps it would be clearer to say that this structure is used when only one
> signature is to be placed in a message.
>
>
>
> Overall this section is well written and provides useful details about how
> to compute signatures and counter signatures.
>
>
>
>
>
> Section 5 describes the COSE encryption objects. I disagree with one choice
> of terminology adopted here: “recipient algorithm classes” which is
> described in 5.1.1. This is really a discussion of classes of key
> encrypted message acquires the CEK used to decrypt the message. I’d prefer a
> less obscure name for this sub-section. Otherwise this section is well
> written and provide lots of useful details about how to encrypt and decrypt
> messages for two classes of encryption algorithms.
>
>
>
>
>
> structures, depending on whether a recipient implicitly knows what key to
> use to verify the MAC, or whether an ID for one or more MAC keys must be
> communicated. The text here closely parallels that of Section 5 and is very
> good.
>
>
>
>
>
> Section 7 describes the COSE key structure. It is designed to accommodate
> the data needed by a wide range of key distribution mechanisms and
> encryption techniques.
>
>
>
>
>
> Section 8 defines two classes of signature algorithms that can be used with
> COSE, specifies an algorithm of each type, and provides security guidance
> for each algorithm. I think it would be preferable to remove the detailed
> algorithm descriptions (Sections 8.1 and 8.2) and associated security
> considerations (which are well written) from this document. The comments
> below apply to sections 9, 10, 11 and 12.
>
>
>
> I have several concerns about including the algorithm (vs. algorithm class)
> descriptions here. For many security protocols (and security-focused data
> formats), we usually (though not always) specify mandatory and optional to
> implement algorithms in separate documents, to facilitate algorithm agility.
> I think we should follow that model for COSE. Also, the text here does not
> mandate support for these algorithms; it merely provides details for a set
> of algorithms that a sender and/or receive may choose to implement. One has
> to read the final sentence of the opening paragraph of Section 15 to learn
> that this is the intent, i.e., that selection of specific algorithms is
> deferred to the each application that makes use of COSE. Given that later
> statement, it appears that the algorithms specified in Sections 8-12 ate
> intended to define the set from which application developer MUST choose, but
> that too is not clearly stated. I think this makes it even more appropriate
> distribution/management methods. Most of this section is analogous to the
> preceding sections (9-11) where specific algorithms are described for use
> with COSE, and thus my comments about undue bundling of algorithms with a
> protocol specs apply here too. I do not object to describing key transport,
> key wrapping and key agreement methods in general, but the detailed specs in
> 12.2.1, 12.4.1 and 12.5.1 seem inappropriate here, for the reasons noted
> above.
>
>
>
>
>
> Section 13 describes parameters for key objects used by COSE. The specs here
> are sufficiently generic that they do not suffer from the problems I noted
> for Sections 8-12.
>
>
>
>
>
> Section 15 provides guidance for application developers making use of COSE.
> This is where a reader finally discovers that  the algorithms described in
> Sections 8-12 are not MTI, and that each application is expected to specify
> which algorithms are MTI in that context, to facilitate interoperability.
>
>
>
> Section 16 (IANA Considerations) describes the registries that need to be
> created for COSE, and extensions to the CoAP registry to support COSE. It
> seem to be well written and comprehensive.
>
>
>
> well-written security considerations discussions provided for the algorithms
> in Sections 8-12.
>
>
>
>
>
> Typos and suggested rewording.
>
>
>
> Section 2:
>
>
>
> The COSE object structure is designed so that there can be a large amount of
> common code when parsing and processing the different
>
> security messages.
>
> As the IV is authenticated by the encryption process, it can be placed in
> the unprotected header bucket. (in general, an encryption process will not
> “authenticate” an IV, but use of a modified IV will yield mangled plaintext,
> which can be detected by an integrity check or a signature. the same comment
> applies to the similar statement in the “partial IV” description.)
>
>
>
>
>
> Section 4:
>
>
>
> Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with the
> Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm.
>
> -> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the Elliptic
> Curve Digital Signature Algorithm (ECDSA) (cite).
>
>
>
> Counter signatures provide a method of having a different signature occur on
> some piece of content.
>
> -> Counter signatures provide a method of associating different signatures
> generated by different signers with some piece of content.
>
>
>
>
>
> Section 5
>
>
>
> Other:  The key is randomly generated.
>
> -> Other:  The key is randomly or pseudo-randomly generated.
>
>
>
>
>
> Section 6
>
>
>
> (This knowledge of sender assumes that there are only two parties involved
> and you did not send the message yourself.)
>

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Wed, 21 Sep 2016 16:19:42 -0400

Hi Steve,

Thank you for the thorough review of the specification. Speaking for the 
COSE chairs, I want to confirm that it was WG consensus to keep 
everything in a single document. This was partially in reaction to 
community dissatisfaction with the document arrangement of JOSE, from 
which this work originally grew.

Additionally, there was WG discussion and consensus around the use of 
CDDL in the document. The CDDL is used throughout the document in a 
non-normative example fashion. The normative requirements in terms of 
data structures and construction of COSE objects is in the surrounding 
text. The editor and WG could have adopted an arbitrary description 
language, or invented one out of whole cloth for this purpose, but a 
simple one had already been written down and was available. Due to it 
being still in draft and an informational document, the WG decided to 
not have a normative requirement on CDDL and to not rely on the CDDL 
listings in a normative fashion.

Hopefully this clears up those two issues, and I'll let Jim answer the 
remainder.

Thank you,

  -- Justin Richer

---

From: Jim Schaad <[email-masked]>
Date: Wed, 21 Sep 2016 16:42:48 -0700

Hi Steve,

Good to hear from you again.  I will be doing a second message on the nits so that I can make them at the same time that I do the response.

It is always good to have a comprehensive and useful review and one with action items. Thanks for that

Comments in line

jim

From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, September 21, 2016 7:27 AM
To: secdir <[email-masked]>; Jim Schaad <[email-masked]>; Justin Richer <[email-masked]>; Kepeng Li <[email-masked]>; Kathleen Moriarty <[email-masked]>
Subject: secdir review of cose-msg-18

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
 
This document defines formats for signing and/or encryption of data encoded using CBOR (RFC7049). The signing/encryption approach adopted here is based on the standards developed in JOSE (RFCs 7515-18), since CBOR is based on JSON. 
 
This is a large document: about 90 pages plus almost 30 pages of appendices (providing useful examples).  Close to half of the (non-appendix portion) document is devoted to specifications for a set of algorithms for encryption, signatures, message authentication, and key distribution. Only when the reader reaches page 73 is it made clear that the algorithm descriptions are not MTI; they define a set from which application developers must (?) choose when creating a profile for COSE use in a specific application context. Given the long-standing IETF policy to trying to facilitate algorithm agility,  
I think it preferable to extract these descriptions and publish them as separate RFCs, a practice often employed in documenting many other security protocols (including JOSE, from which this work is based). 

[JLS] This was the approach that I had originally intended to take, breaking the document in two pieces towards the end when things were settled.  My memory is that this was discussed in the working group, and it was determined that one document was preferable to having two different documents.  I believe that this practice started with CMS and it was done there to deal with the question of how to advance to standards track for the format document and still allow the algorithm document to be updated.  This has not seemed to be how things have worked in practice, or has been necessary as protocol documents such as S/MIME is where the implementation requirements on algorithms are specified rather than in the format draft (CMS).  I therefore have less problems with the fact that this is one draft from that standpoint.  It would have been nicer just from a length prospective, but people thought that being able to reference back and forth in a single HTML page to be better than flipping between different pages.

Since there is no standard grammar for CBOR, the author adopted the primitive types defined in an I-D (draft-ietf- greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of COSE formats. I recommend that this document be held for publication until that I-D is approved. I also note that the cited I-D is Informational, but this document is Standards Track. the cited I-D is listed as informative, but the syntax it defines is used extensively throughout this document, thus I believe it really is normative.

[JLS]  There was a long discussion about what to do with the CDDL grammar portions of the document.  Like me, it would appear that you are a strong advocate of doing formal languages and making them normative rather than making descriptive text normative.  Given the state of CDDL making it a normative reference would be difficult since it is still being transformed.  I have argued with the authors to try and get what is there published but have not been successful.

During the discussion there were several versions where presented as alternatives.
* The current mixing of CDDL and text
* Moving the CDDL to the end of the section that it relates to 
* Moving the CDDL to an appendix
* Removing the CDDL entirely.

I argued against the last option as I find formal language to be useful.  As I placed the CDDL in line to start with as it makes it easier to validate the language and the text as being the same that became somewhat of the baseline, however at least one version of the document moved all of the CDDL to the end of the section so people did have a change to see what that would look like.  After much discussion, the group decided that it wanted to keep the current format as they did not like having it at the end of the section.  

The draft is cited as informative because the document states that the text description is to be normative and there is a full duplication of the CDDL in the text.  One can remove the CDDL and a complete description of how to encode things is still I the document.

Section 2 defines the basic COSE data structure. The description seems clear and logical, but the list of message types is a bit puzzling (absent information that is provided later, in Sections 4 and 5). For example, there is a Single Signer data Object, and a Signed Data Object. If the latter accommodates multiple signers, why not make that part of the name? The same nomenclature confusion arises for encrypted objects directed to a single recipient vs. multiple recipients.

[JLS] I thought about making this change in the past but had an issue with the fact that this might make people think that the Signed Data object version could only be used if there were two or more signers.  It allows for one or more signers so it is a bit of a misnomer to say that it is a multiple signer version.  The structures are build in such a way that one cannot switch between the versions so you cannot just go from the Single Signer to the Multiple Signer when a second signature is added.

I can understand the issue you are raising, but the solution has similar issues.  The term "One or More Signer Data Object" seems to be a bit unwieldy.  Other suggestions would be welcome.

Section 4 describes the objects used to convey one or more signatures for objects. The description here is a bit confusing when it discusses one vs. multiple signatures. The format that allows carriage of multiple signatures does not necessarily imply that there are multiple signers, e.g., the multiple signatures may be present to accommodate different algorithm capabilities for different recipients. The introduction to 4.2 says: 
	“The COSE_Sign1 signature structure is used when only one signer is going to be placed on a message.”
Perhaps it would be clearer to say that this structure is used when only one signature is to be placed in a message.

[JLS] Makes sense - done.

Section 5 describes the COSE encryption objects. I disagree with one choice of terminology adopted here: “recipient algorithm classes” which is described in 5.1.1. This is really a discussion of classes of key distribution/management algorithms, focusing on how each recipient of an encrypted message acquires the CEK used to decrypt the message. I’d prefer a less obscure name for this sub-section. Otherwise this section is well written and provide lots of useful details about how to encrypt and decrypt messages for two classes of encryption algorithms.

[JLS] I agree that the term is not optimal.  There was a long discussion about this in the WG on the mailing list.  The original term used was "key management classes" (if memory serves) and there were issues raised because this is not key management in the world of how does a client get a symmetric or public key.  The fact that the term was ambiguous as to the problem being solved was thought to be an issue.  After a long discussion the term "recipient algorithm classes" was adopted.

Section 6 describes the MAC objects. Here too there are two types of structures, depending on whether a recipient implicitly knows what key to use to verify the MAC, or whether an ID for one or more MAC keys must be communicated. The text here closely parallels that of Section 5 and is very good.

Section 8 defines two classes of signature algorithms that can be used with COSE, specifies an algorithm of each type, and provides security guidance for each algorithm. I think it would be preferable to remove the detailed algorithm descriptions (Sections 8.1 and 8.2) and associated security considerations (which are well written) from this document. The comments below apply to sections 9, 10, 11 and 12. 
 
I have several concerns about including the algorithm (vs. algorithm class) descriptions here. For many security protocols (and security-focused data formats), we usually (though not always) specify mandatory and optional to implement algorithms in separate documents, to facilitate algorithm agility. I think we should follow that model for COSE. Also, the text here does not mandate support for these algorithms; it merely provides details for a set of algorithms that a sender and/or receive may choose to implement. One has to read the final sentence of the opening paragraph of Section 15 to learn that this is the intent, i.e., that selection of specific algorithms is deferred to the each application that makes use of COSE. Given that later statement, it appears that the algorithms specified in Sections 8-12 ate intended to define the set from which application developer MUST choose, but that too is not clearly stated. I think this makes it even more appropriate to remove the detailed algorithm discussions from this document.  

[JLS] There is discussion on making things a separate document up above.

Section 15 was placed to be near the other "Considerations" sections and so that it would not need to do any clarification language about the issues.  This section could just as easily be placed immediately following Section 1 (Introduction) which would allow people to understand that not only are the algorithms presented as not MTI but the same thing is true on the structures.   Would that alleviate some of your concerns?

Section 12 describes the “recipient algorithm classes” aka key distribution/management methods. Most of this section is analogous to the preceding sections (9-11) where specific algorithms are described for use with COSE, and thus my comments about undue bundling of algorithms with a protocol specs apply here too. I do not object to describing key transport, key wrapping and key agreement methods in general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem inappropriate here, for the reasons noted above.

Section 15 provides guidance for application developers making use of COSE. This is where a reader finally discovers that  the algorithms described in Sections 8-12 are not MTI, and that each application is expected to specify which algorithms are MTI in that context, to facilitate interoperability.

[JLS] See above question

---

From: Jim Schaad <[email-masked]>
Date: Wed, 21 Sep 2016 18:57:10 -0700

Changes marked 'done' have been integrated on github.

Jim

 
Section 2: 
 
The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different
security messages.
 -> The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different types of security messages.

done

done
 
Section 3:

done

done

[JLS] I believe that lower case is correct here.  This would not be a requirement on the COSE protocol, but on the application that is using COSE.  It does not make sense to me to have 2119 language for this type of statement.  (Partly from an initial brow beating from Russ.)
 
Integers are from the "CoAP Content-Formats" IANA registry table. (no reference)

[JLS] What do you think should be referenced here?  Are you looking for a URL to iana.org?  Not sure that this makes sense.
 
As the IV is authenticated by the encryption process, it can be placed in the unprotected header bucket. (in general, an encryption process will not “authenticate” an IV, but use of a modified IV will yield mangled plaintext, which can be detected by an integrity check or a signature. the same comment applies to the similar statement in the “partial IV” description.)
 
[JLS] Does this work?

The IV can be placed in the unprotected header as modifying the IV will cause the decryption of the plaintext to fail.

Section 4:
 
Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm.
-> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the Elliptic Curve Digital Signature Algorithm (ECDSA) (cite).

[JLS] I think it is excessive, but done.

done

done
 
Counter signatures provide a method of having a different signature occur on some piece of content.
-> Counter signatures provide a method of associating different signatures generated by different signers with some piece of content.

done

Section 5

done
 
Section 6
 
(This knowledge of sender assumes that there are only two parties involved and you did not send the message yourself.)
-> (This knowledge of sender assumes that there are only two parties involved and you did not send the message to yourself.)
 
done
 
Section 15:

done

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Sep 2016 13:54:25 -0400

Jim,

Thanks for making the changes you describe as done. Comments below on 
the few remaining items.

> [JLS] I believe that lower case is correct here.  This would not be a requirement on the COSE protocol, but on the application that is using COSE.  It does not make sense to me to have 2119 languag…
OK.
> [JLS] What do you think should be referenced here?  Are you looking for a URL to iana.org?  Not sure that this makes sense.
When you refer to IANA registries defined in the doc you cite the 
relevant section of the doc. Since this registry already exists I think 
it would be appropriate to include a pointer to it: 
http://www.iana.org/assignments/core-parameters/core-parameters.xhtml
> The IV can be placed in the unprotected header as modifying the IV will cause the decryption of the plaintext to fail.
How about:

The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled.

The decryption process will not, itself, detect any error, so it will 
not "fail" per se.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Sep 2016 13:55:00 -0400

Jim,

How's harvest going?

> [JLS] This was the approach that I had originally intended to take, breaking the document in two pieces towards the end when things were settled.  My memory is that this was discussed in the workin…
I hear from you and others that this is what the WG wanted. So, please 
add text at the beginning of the algs discussion noting that when it 
becomes necessary to add or remove algs the plan is to ...
> [JLS]  There was a long discussion about what to do with the CDDL grammar portions of the document.  Like me, it would appear that you are a strong advocate of doing formal languages and making the…
I reread Section 1.3 and I see that you did say that the text describing 
COSE structures, not the CDDL, is normative. Since CDDL might change, do 
you feel that 1.3 provides enough background so that a reader need not 
refer the CDDL I-D? What's the plan if the RFC version of CDDL differs 
from the current version in a way that causes the descriptions in this 
document to no longer be accurate descriptions of COSE structures?
> I can understand the issue you are raising, but the solution has similar issues.  The term "One or More Signer Data Object" seems to be a bit unwieldy.  Other suggestions would be welcome.
Multi-signer Data Object seems concise to me ;-)
> [JLS] I agree that the term is not optimal.  There was a long discussion about this in the WG on the mailing list.  The original term used was "key management classes" (if memory serves) and there…
I think "content key distribution methods" is the right title for this, 
having re-read section 13. That's what you're describing.

Steve

---

From: Jim Schaad <[email-masked]>
Date: Fri, 23 Sep 2016 12:20:30 -0700

> -----Original Message-----
> Sent: Friday, September 23, 2016 10:54 AM
> To: Jim Schaad <[email-masked]>; 'secdir' <[email-masked]>; 'Justin
> Richer' <[email-masked]>; 'Kepeng Li' <[email-masked]>; 'Kathleen
> Moriarty' <[email-masked]>
> Subject: Re: secdir review of cose-msg-18
> 
> Jim,
> 
> Thanks for making the changes you describe as done. Comments below on the
> few remaining items.
> 
> > [JLS] I believe that lower case is correct here.  This would not be a
> > requirement on the COSE protocol, but on the application that is using
> > COSE.  It does not make sense to me to have 2119 language for this
> > type of statement.  (Partly from an initial brow beating from Russ.)
> OK.
> > [JLS] What do you think should be referenced here?  Are you looking for a URL
> to iana.org?  Not sure that this makes sense.
> When you refer to IANA registries defined in the doc you cite the relevant
> section of the doc. Since this registry already exists I think it would be
> appropriate to include a pointer to it:

I am not overwhelmed, but I will do this

> The IV can be placed in the unprotected header as modifying the IV will cause
> the decryption to yield plaintext that is readily detectable as garbled.

That works for me.  Will do

> 
> 
> The decryption process will not, itself, detect any error, so it will not "fail" per
> se.
> 
> Steve

---

From: Jim Schaad <[email-masked]>
Date: Mon, 26 Sep 2016 17:43:02 -0700

> Sent: Friday, September 23, 2016 10:55 AM

We now have 75% of the fruit picked, and Tom says that this is the hump day for harvest this year.  From here on how we are no longer totally at the mercy of the weather and timing of doing things is more negotiable.  A lot of people are seeing high Brix numbers so am expecting to see some high alcohol wine unless the Jesus effect is put into place.  Flavors are a bit thin on the wines that have been pressed out from others in the building.  I haven't pressed anything yet.

> 
> 
> > [JLS] This was the approach that I had originally intended to take, breaking the
> document in two pieces towards the end when things were settled.  My memory
> is that this was discussed in the working group, and it was determined that one
> document was preferable to having two different documents.  I believe that this
> practice started with CMS and it was done there to deal with the question of
> how to advance to standards track for the format document and still allow the
> algorithm document to be updated.  This has not seemed to be how things have
> worked in practice, or has been necessary as protocol documents such as
> S/MIME is where the implementation requirements on algorithms are specified
> rather than in the format draft (CMS).  I therefore have less problems with the
> fact that this is one draft from that standpoint.  It would have been nicer just
> from a length prospective, but people thought that being able to reference back
> and forth in a single HTML page to be better than flipping between different
> pages.
> I hear from you and others that this is what the WG wanted. So, please add text
> at the beginning of the algs discussion noting that when it becomes necessary to
> add or remove algs the plan is to ...

My first response was this was a reasonable request and should not present any problems.  Then I tried to actually do it.  In the end the text I wrote looked a great deal like saying that one needs to follow standard IETF procedures to update a document.  Write a draft, update a registry, get it approved.  The fact that the algorithms are in this document as opposed to a separate document does not change any of the procedures about doing updates.  The only thing that it would affect is the documents status as a standard.  If the document is modified it would be reset to a lower point.  This is a reasonable discussion if and when that process step is made but should not affect things now.

I therefore would decline to make the requested change.

> > [JLS]  There was a long discussion about what to do with the CDDL grammar
> portions of the document.  Like me, it would appear that you are a strong
> advocate of doing formal languages and making them normative rather than
> making descriptive text normative.  Given the state of CDDL making it a
> normative reference would be difficult since it is still being transformed.  I have
> argued with the authors to try and get what is there published but have not been
> successful.
> I reread Section 1.3 and I see that you did say that the text describing COSE
> structures, not the CDDL, is normative. Since CDDL might change, do you feel
> that 1.3 provides enough background so that a reader need not refer the CDDL I-
> D? What's the plan if the RFC version of CDDL differs from the current version in
> a way that causes the descriptions in this document to no longer be accurate
> descriptions of COSE structures?

Two things, one we are referencing a specific version of the draft and drafts never go away so people will always be able to see what it was written to.  Additionally, I am involved in the effort to get CDDL standardized and would object to anything that is too incompatible with what is used here.  They are mostly trying to do bells and whistles which could just as easily go into a version 2 of the document.  Perfect being the enemy of the adequate.

I would also expect that if the CDDL changes too much, I would want to do a revision of the document to deal with that.

> > [JLS] I thought about making this change in the past but had an issue with the
> fact that this might make people think that the Signed Data object version could
> only be used if there were two or more signers.  It allows for one or more
> signers so it is a bit of a misnomer to say that it is a multiple signer version.  The
> structures are build in such a way that one cannot switch between the versions
> so you cannot just go from the Single Signer to the Multiple Signer when a
> second signature is added.
> >
> > I can understand the issue you are raising, but the solution has similar issues.
> The term "One or More Signer Data Object" seems to be a bit unwieldy.  Other
> suggestions would be welcome.

Again - I have a problem with trying to get people not to jump to the wrong conclusion for Single vs Multi.  While you do not have a problem, that does not mean that others will not see this and misconstrue the titles.

> > Section 5 describes the COSE encryption objects. I disagree with one choice of
> terminology adopted here: “recipient algorithm classes” which is described in
> 5.1.1. This is really a discussion of classes of key distribution/management
> algorithms, focusing on how each recipient of an encrypted message acquires
> the CEK used to decrypt the message. I’d prefer a less obscure name for this sub-
> section. Otherwise this section is well written and provide lots of useful details
> about how to encrypt and decrypt messages for two classes of encryption
> algorithms.
> >
> > [JLS] I agree that the term is not optimal.  There was a long discussion about
> this in the WG on the mailing list.  The original term used was "key management
> classes" (if memory serves) and there were issues raised because this is not key
> management in the world of how does a client get a symmetric or public key.
> The fact that the term was ambiguous as to the problem being solved was
> thought to be an issue.  After a long discussion the term "recipient algorithm
> classes" was adopted.
> I think "content key distribution methods" is the right title for this, having re-
> read section 13. That's what you're describing.

That is a good title, I will run that past the WG, but expect no issues with it.

Jim