Subject: [Cose] Review of draft-schaad-cose-msg-01

From: Mike Jones <[email-masked]>
Date: Sat, 27 Jun 2015 09:06:40 +0000

In response to the call for adoption, I'm submitting the following review feedback on draft-schaad-cose-msg-01<http://tools.ietf.org/html/draft-schaad-cose-msg-01>.  Most of the major comments are motivated by the goal of "keeping simple things simple".  Particularly in constrained environments, it's likely to be normal for implementations to use only the parts of COSE they their application needs.  I believe that we should therefore optimize the representations we define for the common cases, while making it possible to also gracefully accommodate less common, if possibly more general cases as well.

Also, given my role as a designer and editor of the JOSE specs, I'll say explicitly that it's not my goal to try to have all the decisions in COSE exactly mirror those in JOSE.  Some things can clearly be simplified for COSE, and I'm all for that.  I plan to consider each issue on its individual merits.  That said, here's my review...

MAJOR ISSUES

1.  Representations should be optimized for the single recipient case.

In JOSE, going into IESG review, "signatures" or "recipients" arrays were required for the JSON Serializations, with only general multi-signature/multi-recipient representations being defined for JWS and JWE.  Based on feedback from numerous developers who were using JOSE for use cases that only ever used a single signature or recipient, Richard Barnes asked that the Flattened serializations be added to optimize for the common single signature/recipient cases.  Based on this developer feedback, we did this.

Unless we do the same for COSE, I'm sure we'll receive the same feedback that requiring the "recipients" array in use cases where it will always contain one element is unnecessarily complicated.  We should do this now.

While the argument against this could be made that "it's even more complicated to support both the flattened and general serializations than just the general one", I believe that in practice, this is a mostly specious argument.  Applications will choose or build an implementation that fits their use case - either one that supports single or multiple recipients.  Application profiles will choose one or the other representation and will generally not call for both.

The way to achieve this is to define a flattened representation as JOSE did, in which header parameters about both the payload and the recipient are carried in the top level "unprotected" and "protected" elements.

2.  HMACs should be optimized for the no-key-management case.

Particularly for constrained devices, it is unlikely that applications will want to pay the performance penalty of generating and encrypting a key management key to perform a MAC operation.  Heck, they may not have credible random number generation in the first place!  And they are likewise unlikely to want to pay the message size penalty of carrying the encrypted key.

I'm fine with the optional ability to have key management for MACs, but the default should be that no key management information is present in the representation.  The only algorithm represented by default should be the MAC algorithm - not even "dir" (direct).  I suspect that this can be cleanly done by omitting the key management layer entirely when it's not used, rather than explicitly using "dir" (direct).

3.  Wrapped keys should be able to be represented as simply the wrapped key value - not as an encrypted data structure with unnecessary information.

Key management keys are by definition ephemeral and so no metadata needs to be carried about them.  Yes, the algorithm used to wrap the key needs to be represented, but this is already represented separately from the wrapped key.

A simple way to achieve this is to define an encrypted_key field to represent the wrapped key, when appropriate for the algorithm.  Among other benefits, this will enable the use of the standard RFC 3394 AES Key Wrap algorithms, in the same way that JOSE uses "A128KW", etc.

Note that if the working group chooses to, the ability to represent encrypted keys as data structures can also be retained in parallel to this simpler approach.  Applications can then choose which method works best for them.

4.  Simpler and more comprehensible examples are needed.

I would include examples for the simplest and likely most common use cases:

*        HMAC without key management

*        Single signature

*        Encryption using AES Key Wrap for key management and AES GCM for content encryption

Also, to be comprehensible to most readers, the examples need to include both symbolic and numeric identifiers for all fields.  Also, decoded representations for encoded values need to be shown.

For instance, the Direct MAC example in C.1 should be changed from beginning like this:

   {
     1: 3,
     2: h'a10104',
     4: h'546869732069732074686520636f6e74656e742e',
     10: h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857
   6ad9930',

to beginning like this:

   {
     1 (msg_type): 3 (MACed message),
     2 (protected): h'a10104' (alg:HS256),
     4 (payload): h'546869732069732074686520636f6e74656e742e',
     10 (tag): h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857
   6ad9930',

MINOR ISSUES

These issues are organized by section number, providing comments on the spec text in the order of appearance.  27 issues are described, labeled a, b, c, ... aa.  The section numbers and names in which they appear are included in the write-up.

2.  The COSE_MSG structure

a.  Change:
   Implementations MUST be prepared to find an integer under this label
   which does not correspond to the values 1 to 3.  If this is found
   then the client MUST stop attempting to parse the structure and fail.
to:
   Implementations MUST be prepared to find an integer under this label
   which does not correspond to the values 1 to 3.  If this is found
   then the client MUST stop attempting to parse the structure and fail,
   unless it understands and implements the extension label value.

b.  This syntax needs more explanation:
   COSE_Tagged_MSG = #6.999(COSE_MSG)   ; Replace 999 with TBD1

I assume that this is a use of http://tools.ietf.org/html/rfc7049#section-2.4 (Optional Tagging of Items), but you should explicitly say that.

c.  Change:
   | ciphertext  | 4      | TODO: Should we re-use the same as payload |
   |             |        | or not?                                    |
to:
   | ciphertext  | 7      | For COSE_encrypt                           |

It's cleaner not to reuse the same label value for different semantic meanings.  If we do that, we might come to regret it as the spec evolves.  Besides, it's not like using another short integer value here will cause us to run out of them in this context.

d.  Change:
  These two buckets
   are available for use in all of the structures in this document
   except for keys.  While these buckets can be present, they may not
   all be usable in all instances.
to:
  These two buckets
   are defined for use in all of the structures in this document
   except for keys.  While these buckets are defined, they may not
   be usable or used in all instances.

The new text makes it clearer that "protected" and "unprotected" can't be included where their values can't be used.

3.1.  COSE Headers

e.  Change:
  The field is used to indicate which protected header keys
      an application which is processing a message is required to
      understand.
to:
  The field is used to indicate which protected header keys
      defined by extensions to this specification that
      an application that is processing a message is required to
      understand.

The language should make it clear that "crit" is only for defining behavior of critical extensions - not for making header parameters defined by this spec critical.

f.  In Table 2, change:
   | jku      | *     | tstr     |           | URL to COSE key object  |
   |          |       |          |           |                         |
   | jwk      | *     | COSE_Key |           | contains a COSE key not |
   |          |       |          |           | a JWK key               |
   |          |       |          |           |                         |
to:
   | jku      | *     | tstr     |           | URL to JWK [RFC 7517]   |
   |          |       |          |           |                         |
  | cku      | *     | tstr     |           | URL to COSE key object  |
   |          |       |          |           |                         |
   | ck       | *     | COSE_Key |           | contains a COSE key     |
   |          |       |          |           |                         |

It still makes sense to be able to represent URLs to JWK and COSE Key objects.  But we shouldn't call the COSE Key passed by value "jwk", since that's misleading.

g.     Open Issue 1.  Which of the following items do we want to have standardized in
       this document: jku, jwk, x5c, x5t, x5t#S256, x5u, zip?

I would keep all of them, other than changing "jku" and "jwk" to "jku", "cku", and "ck" per (f) above.

h.  Open Issue 2.  I am currently torn on the question "Should epk and iv/nonce be
       algorithm specific or generic headers?"

I would define common labels for them since they are commonly used across multiple algorithms.

4.  Signing Structure

i.  The description of "protected" says "The field MUST NOT hold attributes about the payload being signed".  Assuming that a flattened syntax is added, this would then become something like "The field MUST NOT hold attributes about the payload being signed unless the flattened serialization is being used".  Other related statements throughout the document would likewise need to be similarly updated.

j.  The end of the signing section says:
   In addition to performing the signature verification, one must also
   perform the appropriate checks to ensure that the key is correctly
   paired with the signing identity and that the appropriate
   authorization is done.

There needs to be a reference to a place where the process of verifying the key's association with the signing identity is described.  Particular methods are clearly beyond the scope of this specification but saying this little about the process will likely just leave many people confused.

5.  Encryption Object

k.  The introduction to this section says:
   In this section we describe the structure and methods to be used when
   doing an encryption in COSE.  In COSE, we use the same techniques and
   structures for encrypting both the plain text and the keys used to
  protect the text.  This is different from the approach used by both
   [RFC5652] and [RFC7516] where different structures are used for the
   plain text and for the different key management techniques.

I'll note that if issue 3 is resolved (Wrapped keys should be able to be represented as simply the wrapped key value), this paragraph will have to be revised accordingly.

l.  A generic "iv" (initialization vector) field should also be defined in the list of parameters for the encryption object.  Yes, not all algorithms will use it, but many will.

m.  A "tag" (authentication tag) field should be defined in the list of parameters for the encryption object.  Yes, not all the algorithms will use it, but many will.

5.1.1.  Direct Encryption

n.  The spec says:
   o  At a minimum, the 'unprotected' field MUST contain the 'alg'
      parameter and SHOULD contain a parameter identifying the shared
      secret.

SHOULD is too strong here because in some protocols, the shared secret will already be known by methods other than an included "kid" or other key selection value.  A "SHOULD ... unless ..." construct like was used in similar JOSE descriptions is probably the right thing to use here.

6.  MAC Objects

o.  The "How to compute a MAC" instructions say:
   5.  Encrypt and encode the MAC key for each recipient of the message.

This is not correct when direct key management or no key management is used.  Please revise to accurately include these cases as well.

7.  Key Structure

p.  The spec says:
   The "key_ops" element is preferred over the "use" element as the
   information provided that way is more finely detailed about the
   operations allowed.  It is strongly suggested that this element be
   present for all keys.

Like in (n), the application may know the key usage from application context, rendering the inclusion of "key_ops" unnecessary.  Language something like "It is strongly suggested that this element be present for all keys unless this information is already know to the application through other means" should be used to capture this.

The working group should also discuss whether it wants to carry forward "use" for JWK compatibility, even if it is deprecated.  I personally would be in favor of doing so.

q.  I would define short numeric values that correspond to the defines "key_ops" string values.  I'd do the same for the "use" values.

8.  CBOR Encoder Restrictions

r.  The spec says:
   o  All parsers used SHOULD fail on both parsing and generation if the
      same label is used twice as a key for the same map.

I would strongly prefer that the "SHOULD" be changed to "MUST".  CBOR doesn't have the same legacy of lax parsers that we inherited from JavaScript/ECMAscript for JSON.  Let's not open the door to them!

9.5  COSE Algorithm Registry

s.  I would add an additional "JOSE algorithm name" field to this registry, whose value is the corresponding "Algorithm Name" entry in the IANA JSON Web Signature and Encryption Algorithms registry at http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms, if such an entry exists.  This will tie the two registries together so that definitions of algorithms already defined by JOSE need not be repeated for COSE.

In many cases then, the COSE algorithms draft (or section) can just cite the definition in RFC 7518 and register the corresponding short numeric label for COSE use.

9.8.1  COSE Security Message

t.  Besides registering the MIME type "application/cose", I would also register one for a base64url encoded COSE message - an idea first described to me by Joe Hildebrand.  It could be called "application/cose+base64url" or something of that ilk.

9.8.2  COSE Key Media Type

u.  "application/jwk+json" should be changed to something like "application/cose-key" and "application/jwk-set+json" should be changed to something like "application/cose-key-set".

11.2.  Informative References

v.  The date on the AES-GCM reference (SP 800-38D) should be November 2007 - not June 2015.

Appendix A.  AEAD and AE Algorithms

w.  The spec says:
  This authentication value may be:
   o  A separately generated tag computed by both the encrypter and
      decrypter and then compared by the decryptor.  This tag value may
      be either placed at the end of the cipher text (the decision we
      made) or kept separately (the decision made by the JOSE working
      group).  This is the approach followed by AES-GCM [AES-GCM] and
      AES-CCM [RFC3610].

The last sentence is not true, as written.  The AES-GCM spec describes "the ciphertext and tag outputs" - not a single combined output.  Common implementations correspond to this, such as the implementation of GCM in .NET.

The CCM description in RFC 3610 Section 2.4 describes the output using the text "The final result c consists of the encrypted message followed by the encrypted authentication value U", which admits either implementation.  Likewise, at least the .NET CCM implementation produces separate ciphertext and authentication tag values.

Whether the tag should be separate or automatically appended to the ciphertext isn't a hill I'm going to die on (although the working group should discuss this and make an explicit decision in this regard), but the text describing the decision should at least be changed to be accurate.

Appendix C.  Examples

x.  The uses of strings and corresponding labels such as those that follow are confusing - especially since key ID values are binary in COSE.  A fragment of such an example that confused me was:
         3: {
           5: "[email-masked]"
         },

There are similar strings in some of the other examples that I also couldn't wrap my head around.

Appendix D.  COSE Header Algorithm Label Table

y.  I would change the term "Header Algorithm" to "Header Parameter".  (I suspect this was a cut-and-paste error.)

z.  In Appendix D and Appendix E, I would call out that the names in the "name" columns correspond to names defined in RFC 7518.

Appendix F.  COSE General Values

aa.  This seems confused, as it mixes "kty" values (EC=1, RSA=2, oct=3) with curve values (P256=4, P521=5).  I would keep these separate.  Also, wherever the curve names are defined, I would also include P384, as JOSE did.

NITS

I will be submitting spelling and grammar corrections as a GitHub pull request against the spec repository rather than detail them here.  I'll post the pull request link once it's been created.

CONCLUSIONS

I'd like to thank Jim for doing the work to produce a well-thought-out initial draft.  I believe it provides a solid starting point for the COSE work.

I'd be willing to produce specific proposed edits for any/all of the above issues and comments, should the editors find that useful.

                                                            Best wishes,
                                                            -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 27 Jun 2015 08:25:09 -0700

From: Cose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Saturday, June 27, 2015 2:07 AM
To: [email-masked]
Subject: [Cose] Review of draft-schaad-cose-msg-01

In response to the call for adoption, I'm submitting the following review
feedback on draft-schaad-cose-msg-01
<http://tools.ietf.org/html/draft-schaad-cose-msg-01> .  Most of the major
comments are motivated by the goal of "keeping simple things simple".
Particularly in constrained environments, it's likely to be normal for
implementations to use only the parts of COSE they their application needs.
I believe that we should therefore optimize the representations we define
for the common cases, while making it possible to also gracefully
accommodate less common, if possibly more general cases as well.

Also, given my role as a designer and editor of the JOSE specs, I'll say
explicitly that it's not my goal to try to have all the decisions in COSE
exactly mirror those in JOSE.  Some things can clearly be simplified for
COSE, and I'm all for that.  I plan to consider each issue on its individual
merits.  That said, here's my review.

MAJOR ISSUES

In JOSE, going into IESG review, "signatures" or "recipients" arrays were
required for the JSON Serializations, with only general
multi-signature/multi-recipient representations being defined for JWS and
JWE.  Based on feedback from numerous developers who were using JOSE for use
cases that only ever used a single signature or recipient, Richard Barnes
asked that the Flattened serializations be added to optimize for the common
single signature/recipient cases.  Based on this developer feedback, we did
this.

Unless we do the same for COSE, I'm sure we'll receive the same feedback
that requiring the "recipients" array in use cases where it will always
contain one element is unnecessarily complicated.  We should do this now.

While the argument against this could be made that "it's even more
complicated to support both the flattened and general serializations than
just the general one", I believe that in practice, this is a mostly specious
argument.  Applications will choose or build an implementation that fits
their use case - either one that supports single or multiple recipients.
Application profiles will choose one or the other representation and will
generally not call for both.

The way to achieve this is to define a flattened representation as JOSE did,
in which header parameters about both the payload and the recipient are
carried in the top level "unprotected" and "protected" elements.

[JLS] This was discussed on the mailing list.  There are a number of
trade-offs that were discussed.  Please review that discussion and see if
you have something new to add.  Please remember that we are looking at both
the message size and the code size as criteria when making decisions.

Particularly for constrained devices, it is unlikely that applications will
want to pay the performance penalty of generating and encrypting a key
management key to perform a MAC operation.  Heck, they may not have credible
random number generation in the first place!  And they are likewise unlikely
to want to pay the message size penalty of carrying the encrypted key.

I'm fine with the optional ability to have key management for MACs, but the
default should be that no key management information is present in the
representation.  The only algorithm represented by default should be the MAC
algorithm - not even "dir" (direct).  I suspect that this can be cleanly
done by omitting the key management layer entirely when it's not used,
rather than explicitly using "dir" (direct).

[JLS] See above.

3.  Wrapped keys should be able to be represented as simply the wrapped key
value - not as an encrypted data structure with unnecessary information.

Key management keys are by definition ephemeral and so no metadata needs to
be carried about them.  Yes, the algorithm used to wrap the key needs to be
represented, but this is already represented separately from the wrapped
key.

A simple way to achieve this is to define an encrypted_key field to
represent the wrapped key, when appropriate for the algorithm.  Among other
benefits, this will enable the use of the standard RFC 3394 AES Key Wrap
algorithms, in the same way that JOSE uses "A128KW", etc.

Note that if the working group chooses to, the ability to represent
encrypted keys as data structures can also be retained in parallel to this
simpler approach.  Applications can then choose which method works best for
them.

[JLS] I don't understand this comment.  This is not what the document says.

*        Single signature

*        Encryption using AES Key Wrap for key management and AES GCM for
content encryption

Also, to be comprehensible to most readers, the examples need to include
both symbolic and numeric identifiers for all fields.  Also, decoded
representations for encoded values need to be shown.

For instance, the Direct MAC example in C.1 should be changed from beginning
like this:

   {

     1: 3,

     2: h'a10104',

   6ad9930',

to beginning like this:

   {

   6ad9930',

[JLS] More examples are on the way in the future.

MINOR ISSUES

These issues are organized by section number, providing comments on the spec
text in the order of appearance.  27 issues are described, labeled a, b, c,
. aa.  The section numbers and names in which they appear are included in
the write-up.

a.  Change:

to:

[JLS] I do not believe that this is required.  If you implement a new item,
then you don't have a pure implementation of this document and the clause is
implicit.

I assume that this is a use of
http://tools.ietf.org/html/rfc7049#section-2.4 (Optional Tagging of Items),
but you should explicitly say that.

[JLS]  This falls in to the question of normative reference on CDDL.  If it
is a normative reference, this is not necessary as you are expected to
understand CDDL.  If CDDL is informational, then it would be required.

c.  Change:

   |             |        | or not?                                    |

to:

It's cleaner not to reuse the same label value for different semantic
meanings.  If we do that, we might come to regret it as the spec evolves.
Besides, it's not like using another short integer value here will cause us
to run out of them in this context.

[JLS]  The TODO is a marker for future discussion - There are both
advantages and disadvantages to re-using the same label.  On one hand, it is
easy for programs to always look in the same location for the content
independent of what type of content it is.  This may make things easier for
items which have detached content depending on how the API handles this.  On
the other hand, an API might want to have them separate.   I don't know what
the answer for this is yet.

d.  Change:

  These two buckets

to:

  These two buckets

The new text makes it clearer that "protected" and "unprotected" can't be
included where their values can't be used.

[JLS] That text does not make it any clearer to me.

3.1.  COSE Headers

e.  Change:

      understand.

to:

      understand.

The language should make it clear that "crit" is only for defining behavior
of critical extensions - not for making header parameters defined by this
spec critical.

[JLS] This does not make things clearer tome.

f.  In Table 2, change:

   |          |       |          |           |                         |

   |          |       |          |           | a JWK key               |

   |          |       |          |           |                         |

to:

   |          |       |          |           |                         |

   |          |       |          |           |                         |

   |          |       |          |           |                         |

It still makes sense to be able to represent URLs to JWK and COSE Key
objects.  But we shouldn't call the COSE Key passed by value "jwk", since
that's misleading.

[JLS] Thus the open issue marker.

g.     Open Issue 1.  Which of the following items do we want to have
standardized in

I would keep all of them, other than changing "jku" and "jwk" to "jku",
"cku", and "ck" per (f) above.

[JLS] This will be a discussion issue.

h.  Open Issue 2.  I am currently torn on the question "Should epk and
iv/nonce be

I would define common labels for them since they are commonly used across
multiple algorithms.

4.  Signing Structure

i.                 The description of "protected" says "The field MUST NOT
hold attributes about the payload being signed".  Assuming that a flattened
syntax is added, this would then become something like "The field MUST NOT
hold attributes about the payload being signed unless the flattened
serialization is being used".  Other related statements throughout the
document would likewise need to be similarly updated.

[JLS] But it is not current added - so this is not currently an actionable
statement.

   authorization is done.

There needs to be a reference to a place where the process of verifying the
key's association with the signing identity is described.  Particular
methods are clearly beyond the scope of this specification but saying this
little about the process will likely just leave many people confused.

[JLS] What do you think this should reference?

5.  Encryption Object

I'll note that if issue 3 is resolved (Wrapped keys should be able to be
represented as simply the wrapped key value), this paragraph will have to be
revised accordingly.

[JLS] But currently not an actionable statement.

l.  A generic "iv" (initialization vector) field should also be defined in
the list of parameters for the encryption object.  Yes, not all algorithms
will use it, but many will.

m.  A "tag" (authentication tag) field should be defined in the list of
parameters for the encryption object.  Yes, not all the algorithms will use
it, but many will.

[JLS] Maybe true for 'iv', however 'tag' is part of the ciphertext.

5.1.1.  Direct Encryption

n.  The spec says:

      secret.

SHOULD is too strong here because in some protocols, the shared secret will
already be known by methods other than an included "kid" or other key
selection value.  A "SHOULD . unless ." construct like was used in similar
JOSE descriptions is probably the right thing to use here.

[JLS] The .unless. clause is confusing as hell so I do not plan to include
it.  The definition of SHOULD means that put it there unless you have a good
reason not to do so.

6.  MAC Objects

This is not correct when direct key management or no key management is used.
Please revise to accurately include these cases as well.

[JLS} This is correct for the current document.

7.  Key Structure

p.  The spec says:

   present for all keys.

Like in (n), the application may know the key usage from application
context, rendering the inclusion of "key_ops" unnecessary.  Language
something like "It is strongly suggested that this element be present for
all keys unless this information is already know to the application through
other means" should be used to capture this.

The working group should also discuss whether it wants to carry forward
"use" for JWK compatibility, even if it is deprecated.  I personally would
be in favor of doing so.

[JLS] If you think this, then please open it as a discussion issue.  I don't
see any good use for it that is not better served by 'key_ops'.  This is
doubly true given that the W3C Crypto group

q.  I would define short numeric values that correspond to the defines
"key_ops" string values.  I'd do the same for the "use" values.

[JLS] Yes this will be happening going forward.

r.  The spec says:

I would strongly prefer that the "SHOULD" be changed to "MUST".  CBOR
doesn't have the same legacy of lax parsers that we inherited from
JavaScript/ECMAscript for JSON.  Let's not open the door to them!

s.  I would add an additional "JOSE algorithm name" field to this registry,
whose value is the corresponding "Algorithm Name" entry in the IANA JSON Web
Signature and Encryption Algorithms registry at
http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-alg
orithms, if such an entry exists.  This will tie the two registries together
so that definitions of algorithms already defined by JOSE need not be
repeated for COSE.

In many cases then, the COSE algorithms draft (or section) can just cite the
definition in RFC 7518 and register the corresponding short numeric label
for COSE use.

[JLS] Do we have a reason to believe that COSE implementers are going to
have a larger overlap with JOSE implementers?

t.  Besides registering the MIME type "application/cose", I would also
register one for a base64url encoded COSE message - an idea first described
to me by Joe Hildebrand.  It could be called "application/cose+base64url" or
something of that ilk.

[JLS]  I would expect the media-type reviewers to object to that because
this is a transport encoding not a content encoding.  Do you have a reason
to believe otherwise?

u.  "application/jwk+json" should be changed to something like
"application/cose-key" and "application/jwk-set+json" should be changed to
something like "application/cose-key-set".

v.  The date on the AES-GCM reference (SP 800-38D) should be November 2007 -
not June 2015.

w.  The spec says:

      AES-CCM [RFC3610].

The last sentence is not true, as written.  The AES-GCM spec describes "the
ciphertext and tag outputs" - not a single combined output.  Common
implementations correspond to this, such as the implementation of GCM in
.NET.

The CCM description in RFC 3610 Section 2.4 describes the output using the
text "The final result c consists of the encrypted message followed by the
encrypted authentication value U", which admits either implementation.
Likewise, at least the .NET CCM implementation produces separate ciphertext
and authentication tag values.

Whether the tag should be separate or automatically appended to the
ciphertext isn't a hill I'm going to die on (although the working group
should discuss this and make an explicit decision in this regard), but the
text describing the decision should at least be changed to be accurate.

[JLS] Wrong reference -will correct.

Appendix C.  Examples

x.  The uses of strings and corresponding labels such as those that follow
are confusing - especially since key ID values are binary in COSE.  A
fragment of such an example that confused me was:

         3: {

           5: " <mailto:[email-masked]>
[email-masked]"

         },

There are similar strings in some of the other examples that I also couldn't
wrap my head around.

[JLS] My code does not match the spec here.  Originally they were strings.

y.  I would change the term "Header Algorithm" to "Header Parameter".  (I
suspect this was a cut-and-paste error.)

[JLS] I have not settled on a consistent set of terms for this yet.  I need
to do so and then make a pass to correct them all.  I don't think that some
of the terms I am currently using are sufficiently distinct to make it easy
to figure things out.

z.  In Appendix D and Appendix E, I would call out that the names in the
"name" columns correspond to names defined in RFC 7518.

[JLS] These tables are disappearing as part of the add the algorithms to the
document exercise.

aa.  This seems confused, as it mixes "kty" values (EC=1, RSA=2, oct=3) with
curve values (P256=4, P521=5).  I would keep these separate.  Also, wherever
the curve names are defined, I would also include P384, as JOSE did.

[JLS] That may happen in the future.  I just needed a table to put things in
for now.

NITS

I will be submitting spelling and grammar corrections as a GitHub pull
request against the spec repository rather than detail them here.  I'll post
the pull request link once it's been created.

CONCLUSIONS

I'd like to thank Jim for doing the work to produce a well-thought-out
initial draft.  I believe it provides a solid starting point for the COSE
work.

I'd be willing to produce specific proposed edits for any/all of the above
issues and comments, should the editors find that useful. 

                                                            Best wishes,

                                                            -- Mike

---

From: Dick Hardt <[email-masked]>
Date: Tue, 30 Jun 2015 09:13:57 -0700

On Sat, Jun 27, 2015 at 8:25 AM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Cose [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *Sent:* Saturday, June 27, 2015 2:07 AM
> *To:* [email-masked]
> *Subject:* [Cose] Review of draft-schaad-cose-msg-01
>
>
>
> In response to the call for adoption, I’m submitting the following review
> <http://tools.ietf.org/html/draft-schaad-cose-msg-01>.  Most of the major
> comments are motivated by the goal of “keeping simple things simple”.
> Particularly in constrained environments, it’s likely to be normal for
> implementations to use only the parts of COSE they their application
> needs.  I believe that we should therefore optimize the representations we
> define for the common cases, while making it possible to also gracefully
> Also, given my role as a designer and editor of the JOSE specs, I’ll say
> explicitly that it’s not my goal to try to have all the decisions in COSE
> COSE, and I’m all for that.  I plan to consider each issue on its
> individual merits.  That said, here’s my review…
>
>
>
> *MAJOR ISSUES*
>
>
>
> *1.  Representations should be optimized for the single recipient case.*
>
>
>
> In JOSE, going into IESG review, “signatures” or “recipients” arrays were
> JWE.  Based on feedback from numerous developers who were using JOSE for
> use cases that only ever used a single signature or recipient, Richard
> Barnes asked that the Flattened serializations be added to optimize for the
> common single signature/recipient cases.  Based on this developer feedback,
> we did this.
>
>
>
> Unless we do the same for COSE, I’m sure we’ll receive the same feedback
> that requiring the “recipients” array in use cases where it will always
> While the argument against this could be made that “it’s even more
> just the general one”, I believe that in practice, this is a mostly
> specious argument.  Applications will choose or build an implementation
> that fits their use case – either one that supports single or multiple
> recipients.  Application profiles will choose one or the other
> representation and will generally not call for both.
>
>
>
> The way to achieve this is to define a flattened representation as JOSE
> did, in which header parameters about both the payload and the recipient
> are carried in the top level “unprotected” and “protected” elements.
>
>
>

I searched the mailing list for this WG and could not find this discussion.
JLS: would you please provide a pointer to the discussion on this WG list
so I can understand the tradeoffs? Thanks!

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Jun 2015 09:22:36 -0700

From: Dick Hardt [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 9:14 AM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: [Cose] Review of draft-schaad-cose-msg-01

On Sat, Jun 27, 2015 at 8:25 AM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

From: Cose [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Mike Jones
Sent: Saturday, June 27, 2015 2:07 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Cose] Review of draft-schaad-cose-msg-01

In response to the call for adoption, I’m submitting the following review feedback on draft-schaad-cose-msg-01 <http://tools.ietf.org/html/draft-schaad-cose-msg-01> .  Most of the major comments are motivated by the goal of “keeping simple things simple”.  Particularly in constrained environments, it’s likely to be normal for implementations to use only the parts of COSE they their application needs.  I believe that we should therefore optimize the representations we define for the common cases, while making it possible to also gracefully accommodate less common, if possibly more general cases as well.

Also, given my role as a designer and editor of the JOSE specs, I’ll say explicitly that it’s not my goal to try to have all the decisions in COSE exactly mirror those in JOSE.  Some things can clearly be simplified for COSE, and I’m all for that.  I plan to consider each issue on its individual merits.  That said, here’s my review…

MAJOR ISSUES

In JOSE, going into IESG review, “signatures” or “recipients” arrays were required for the JSON Serializations, with only general multi-signature/multi-recipient representations being defined for JWS and JWE.  Based on feedback from numerous developers who were using JOSE for use cases that only ever used a single signature or recipient, Richard Barnes asked that the Flattened serializations be added to optimize for the common single signature/recipient cases.  Based on this developer feedback, we did this.

Unless we do the same for COSE, I’m sure we’ll receive the same feedback that requiring the “recipients” array in use cases where it will always contain one element is unnecessarily complicated.  We should do this now.

While the argument against this could be made that “it’s even more complicated to support both the flattened and general serializations than just the general one”, I believe that in practice, this is a mostly specious argument.  Applications will choose or build an implementation that fits their use case – either one that supports single or multiple recipients.  Application profiles will choose one or the other representation and will generally not call for both.

The way to achieve this is to define a flattened representation as JOSE did, in which header parameters about both the payload and the recipient are carried in the top level “unprotected” and “protected” elements.

[JLS] This was discussed on the mailing list.  There are a number of trade-offs that were discussed.  Please review that discussion and see if you have something new to add.  Please remember that we are looking at both the message size and the code size as criteria when making decisions.

I searched the mailing list for this WG and could not find this discussion. JLS: would you please provide a pointer to the discussion on this WG list so I can understand the tradeoffs? Thanks!

[JLS]  Look for the subject “[Cose] Issue: Encoding for a single recipient or structure”

---

From: Dick Hardt <[email-masked]>
Date: Tue, 30 Jun 2015 10:09:36 -0700

Thanks Jim. I concur with always using an array.

On Tue, Jun 30, 2015 at 9:22 AM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Dick Hardt [mailto:[email-masked]]
> *Sent:* Tuesday, June 30, 2015 9:14 AM
> *To:* Jim Schaad
> *Cc:* Mike Jones; [email-masked]
> *Subject:* Re: [Cose] Review of draft-schaad-cose-msg-01
>
>
>
>
>
>
>
> I searched the mailing list for this WG and could not find this
> discussion. JLS: would you please provide a pointer to the discussion on
> this WG list so I can understand the tradeoffs? Thanks!
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 30 Jun 2015 21:54:01 +0000

Jim, is the discussion you're referring to for my issue 2 the thread "Key management in the World of COSE" or is there an additional thread you're referring to?

From: Jim Schaad [mailto:[email-masked]]
Sent: Saturday, June 27, 2015 8:25 AM
To: Mike Jones; [email-masked]
Subject: RE: [Cose] Review of draft-schaad-cose-msg-01

From: Cose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Saturday, June 27, 2015 2:07 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Cose] Review of draft-schaad-cose-msg-01

MAJOR ISSUES

[JLS] See above.

*        Single signature

   {
     1: 3,
     2: h'a10104',

to beginning like this:

   {

MINOR ISSUES

a.  Change:

[JLS] I do not believe that this is required.  If you implement a new item, then you don't have a pure implementation of this document and the clause is implicit.

[JLS]  This falls in to the question of normative reference on CDDL.  If it is a normative reference, this is not necessary as you are expected to understand CDDL.  If CDDL is informational, then it would be required.

c.  Change:

[JLS]  The TODO is a marker for future discussion - There are both advantages and disadvantages to re-using the same label.  On one hand, it is easy for programs to always look in the same location for the content independent of what type of content it is.  This may make things easier for items which have detached content depending on how the API handles this.  On the other hand, an API might want to have them separate.   I don't know what the answer for this is yet.

d.  Change:
  These two buckets

3.1.  COSE Headers

e.  Change:

f.  In Table 2, change:

4.  Signing Structure

i.                 The description of "protected" says "The field MUST NOT hold attributes about the payload being signed".  Assuming that a flattened syntax is added, this would then become something like "The field MUST NOT hold attributes about the payload being signed unless the flattened serialization is being used".  Other related statements throughout the document would likewise need to be similarly updated.
[JLS] But it is not current added - so this is not currently an actionable statement.

5.  Encryption Object

5.1.1.  Direct Encryption

n.  The spec says:

SHOULD is too strong here because in some protocols, the shared secret will already be known by methods other than an included "kid" or other key selection value.  A "SHOULD ... unless ..." construct like was used in similar JOSE descriptions is probably the right thing to use here.
[JLS] The ...unless... clause is confusing as hell so I do not plan to include it.  The definition of SHOULD means that put it there unless you have a good reason not to do so.

6.  MAC Objects

7.  Key Structure

p.  The spec says:

The working group should also discuss whether it wants to carry forward "use" for JWK compatibility, even if it is deprecated.  I personally would be in favor of doing so.
[JLS] If you think this, then please open it as a discussion issue.  I don't see any good use for it that is not better served by 'key_ops'.  This is doubly true given that the W3C Crypto group

r.  The spec says:

In many cases then, the COSE algorithms draft (or section) can just cite the definition in RFC 7518 and register the corresponding short numeric label for COSE use.
[JLS] Do we have a reason to believe that COSE implementers are going to have a larger overlap with JOSE implementers?

t.  Besides registering the MIME type "application/cose", I would also register one for a base64url encoded COSE message - an idea first described to me by Joe Hildebrand.  It could be called "application/cose+base64url" or something of that ilk.
[JLS]  I would expect the media-type reviewers to object to that because this is a transport encoding not a content encoding.  Do you have a reason to believe otherwise?

w.  The spec says:

Appendix C.  Examples

x.  The uses of strings and corresponding labels such as those that follow are confusing - especially since key ID values are binary in COSE.  A fragment of such an example that confused me was:
         3: {
           5: "[email-masked]<mailto:[email-masked]>"
         },

y.  I would change the term "Header Algorithm" to "Header Parameter".  (I suspect this was a cut-and-paste error.)
[JLS] I have not settled on a consistent set of terms for this yet.  I need to do so and then make a pass to correct them all.  I don't think that some of the terms I am currently using are sufficiently distinct to make it easy to figure things out.

z.  In Appendix D and Appendix E, I would call out that the names in the "name" columns correspond to names defined in RFC 7518.
[JLS] These tables are disappearing as part of the add the algorithms to the document exercise.

aa.  This seems confused, as it mixes "kty" values (EC=1, RSA=2, oct=3) with curve values (P256=4, P521=5).  I would keep these separate.  Also, wherever the curve names are defined, I would also include P384, as JOSE did.
[JLS] That may happen in the future.  I just needed a table to put things in for now.

NITS

CONCLUSIONS

                                                            Best wishes,
                                                            -- Mike