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

From: Mike Jones <[email-masked]>
Date: Tue, 7 Jul 2015 19:50:32 +0000

Jim, I hadn't seen an answer to this question.  If the thread you're referring to is "Key management in the World of COSE", my impression is that some people talked about use cases, but there were no actual conclusions drawn.

Also, could you answer Brian Campbell's question in the related thread "Key management for MACs (was Re: [Cose] Review of draft-schaad-cose-msg-01)"?  As I said in my reply, I completely understand the value of key management for encryption, in which there are secrets to protect, but not for MACs, where there are not.

                                                                Thanks,
                                                                -- Mike

From: Mike Jones
Sent: Tuesday, June 30, 2015 2:54 PM
To: 'Jim Schaad'; [email-masked]
Subject: RE: [Cose] Review of draft-schaad-cose-msg-01

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]<mailto:[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

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.

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

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

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

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

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

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.

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

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.

[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:
   | 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.

[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
   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.
[JLS] That text does not make it any clearer to me.

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.
[JLS] This does not make things clearer tome.

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.
[JLS] Thus the open issue marker.

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.
[JLS] This will be a discussion issue.

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.
[JLS] But it is not current added - so this is not currently an actionable statement.

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.
[JLS] What do you think this should reference?

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.
[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:
   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.
[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

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.
[JLS} This is correct for the current document.

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

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.
[JLS] Do we have a reason to believe that COSE implementers are going to have a larger overlap with JOSE implementers?

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.
[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?

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.

[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: "[email-masked]<mailto:[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.

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.)
[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.

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.
[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: Justin Richer <[email-masked]>
Date: Tue, 7 Jul 2015 15:54:34 -0400

Perhaps I’m missing something, but as chair I feel the need to point out this line in our current charter for you all to consider:

Key management and binding of keys to identities are out of scope for the
working group.

 — Justin

> On Jul 7, 2015, at 3:50 PM, Mike Jones <[email-masked]> wrote:
> 
> Jim, I hadn’t seen an answer to this question.  If the thread you’re referring to is “Key management in the World of COSE”, my impression is that some people talked about use cases, but there were no actual conclusions drawn.
>  
> Also, could you answer Brian Campbell’s question in the related thread “Key management for MACs (was Re: [Cose] Review of draft-schaad-cose-msg-01)”?  As I said in my reply, I completely understand the value of key management for encryption, in which there are secrets to protect, but not for MACs, where there are not.
>  
>                                                                 Thanks,
>                                                                 -- Mike
>  
> From: Mike Jones 
> 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] <mailto:[email-masked]>] 
> To: Mike Jones; [email-masked] <mailto:[email-masked]>
> From: Cose [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Mike Jones
> To: [email-masked] <mailto:[email-masked]>
> 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.
>  
> 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.
>  
> 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.
>  
> [JLS] I don’t understand this comment.  This is not what the document says.
>  
> ·        HMAC without key management
> ·        Single signature
> ·        Encryption using AES Key Wrap for key management and AES GCM for content encryption
>  
> 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.
>  
> [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 <http://tools.ietf.org/html/rfc7049#section-2.4> (Optional Tagging of Items), but you should explicitly say that.
>  
> 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
> The new text makes it clearer that “protected” and “unprotected” can’t be included where their values can’t be used.
> 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.
> 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.
> I would keep all of them, other than changing “jku” and “jwk” to “jku”, “cku”, and “ck” per (f) above.
> 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.
>  
> 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.
> 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.
> [JLS] Maybe true for ‘iv’, however ‘tag’ is part of the ciphertext.
>  
> 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
>  
> o.  The “How to compute a MAC” instructions say:
> 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.
> 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-algorithms <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.
>  
> 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.
> 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.
>  
> 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: "[email-masked] <mailto:[email-masked]>"
>          },
>  
> There are similar strings in some of the other examples that I also couldn’t wrap my head around.
> 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.
> 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.
> 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
>  
> _______________________________________________
> Cose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Jul 2015 22:24:26 +0200

There is a difference between 1) “key management” (one of the least useful words I know in the field of security) and 2) the packing and unpacking of keying material into data structures for transmission, in a way that makes use of certain cryptographic functions.  I indeed hope we are doing the latter, but not the former.  Similarly, I hope that the concept of an “identity” does not exist at the COSE level, and I also hope that COSE can be used to ship around keys and other information that may be used in protocols that establish or employ what could be called “identity”.

If we, however, have to make sure COSE cannot be used at all for “key management” or “binding keys to identities” (whatever these things mean in an application of COSE), this is not a useful activity.

Grüße, Carsten

On 7 Jul 2015 at 21:55:04, Justin Richer ([email-masked]) wrote:

---

From: Brian Campbell <[email-masked]>
Date: Tue, 7 Jul 2015 14:35:49 -0600

[wearing my cowboy hat from Dallas:)]

I think the term "key management" has gotten a little overloaded here.

I believe the charter uses the term in the broader and traditional sense
that Wikipedia <https://en.wikipedia.org/wiki/Key_management>, for example,
talks about it, like "dealing with the generation, exchange, storage, use,
and replacement of keys" including "key servers [and] user procedures."

Whereas the term seemed to get somewhat co-opted in JOSE as a catch all to
cover all the message level key encryption, key encapsulation, and key
agreement bits that are needed to convey and protect a content encryption
key for encryption. And that usage has carried over into COSE.

COSE needs "key management" in the latter sense of the word. Maybe it
should be called something else but it's a necessity for encryption. My
question the other day was about the what value there is in doing it for
MAC keys.

I suspect the "Key management and binding of keys to identities are out of
scope" in the former sense in the charter is intended to keep COSE scope
reasonably constrained.

On Tue, Jul 7, 2015 at 1:54 PM, Justin Richer <[email-masked]> wrote:

> Perhaps I’m missing something, but as chair I feel the need to point out
> this line in our current charter for you all to consider:
>
>  Jim, I hadn’t seen an answer to this question.  If the thread you’re
> referring to is “Key management in the World of COSE”, my impression is
> that some people talked about use cases, but there were no actual
> conclusions drawn.
>
>
>
> Also, could you answer Brian Campbell’s question in the related thread
> “Key management for MACs (was Re: [Cose] Review of
> draft-schaad-cose-msg-01)”?  As I said in my reply, I completely understand
> the value of key management for encryption, in which there are secrets to
> protect, but not for MACs, where there are not.
>
>
>
>                                                                 Thanks,
>
>                                                                 -- Mike
>
>
>
> *From:* Mike Jones
> *Sent:* Tuesday, June 30, 2015 2:54 PM
> *To:* 'Jim Schaad'; [email-masked]
> *Subject:* RE: [Cose] Review of draft-schaad-cose-msg-01
>
>
>
> 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] <[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] <[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*
>
>
>
> *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.
>
>
>
> [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.
>
>
>
> *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).
>
>
>
> [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.
>
>
>
> *4.  Simpler and more comprehensible examples are needed.*
>
>
>
> 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.
>
>
>
> *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.
>
>
>
> [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:
>
> 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
>
> The new text makes it clearer that “protected” and “unprotected” can’t be
> included where their values can’t be used.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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-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.
>
> [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”.
>
>
>
> 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.
>
>
>
> 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]"
>
>          },
>
>
>
> [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.
>
> 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: Tue, 7 Jul 2015 15:40:33 -0700

I am more than willing to have a different term for “Key Management”.  However, I have inherited the term from CMS (RFC 2630) where section 12.3 talks about key management algorithms.

What you re referring to below, I generally put under the term of key life cycle

Jim

From: Brian Campbell [mailto:[email-masked]] 
Sent: Tuesday, July 07, 2015 1:36 PM
To: Justin Richer
Cc: Mike Jones; Jim Schaad; [email-masked]
Subject: Re: [Cose] Review of draft-schaad-cose-msg-01

I believe the charter uses the term in the broader and traditional sense that Wikipedia <https://en.wikipedia.org/wiki/Key_management> , for example, talks about it, like "dealing with the generation, exchange, storage, use, and replacement of keys" including "key servers [and] user procedures." 

Whereas the term seemed to get somewhat co-opted in JOSE as a catch all to cover all the message level key encryption, key encapsulation, and key agreement bits that are needed to convey and protect a content encryption key for encryption. And that usage has carried over into COSE. 

COSE needs "key management" in the latter sense of the word. Maybe it should be called something else but it's a necessity for encryption. My question the other day was about the what value there is in doing it for MAC keys. 

I suspect the "Key management and binding of keys to identities are out of scope" in the former sense in the charter is intended to keep COSE scope reasonably constrained.  

On Tue, Jul 7, 2015 at 1:54 PM, Justin Richer <[email-masked] <mailto:[email-masked]> > wrote:

 — Justin

On Jul 7, 2015, at 3:50 PM, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

                                                                Thanks,

                                                                -- Mike

From: Mike Jones 
Sent: Tuesday, June 30, 2015 2:54 PM
To: 'Jim Schaad'; [email-masked] <mailto:[email-masked]> 
Subject: RE: [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.

MAJOR ISSUES

[JLS] See above.

*        Single signature

   {

     1: 3,

     2: h'a10104',

   6ad9930',

to beginning like this:

   {

   6ad9930',

MINOR ISSUES

a.  Change:

to:

c.  Change:

   |             |        | or not?                                    |

to:

d.  Change:

  These two buckets

to:

  These two buckets

3.1.  COSE Headers

e.  Change:

      understand.

to:

      understand.

f.  In Table 2, change:

   |          |       |          |           |                         |

   |          |       |          |           | a JWK key               |

   |          |       |          |           |                         |

to:

   |          |       |          |           |                         |

   |          |       |          |           |                         |

   |          |       |          |           |                         |

4.  Signing Structure

   authorization is done.

5.  Encryption Object

5.1.1.  Direct Encryption

n.  The spec says:

      secret.

6.  MAC Objects

7.  Key Structure

p.  The spec says:

   present for all keys.

r.  The spec says:

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.

w.  The spec says:

      AES-CCM [RFC3610].

Appendix C.  Examples

         3: {

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

         },

NITS

CONCLUSIONS

                                                            Best wishes,

                                                            -- Mike

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

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Jul 2015 22:57:17 +0000

Re-asking Brian’s question, what do you see as the purpose of key management for MACs, Jim (where “key management” is being used in the same way that CMS §12.3 used the term)?

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, July 07, 2015 3:41 PM
To: 'Brian Campbell'; 'Justin Richer'
Cc: Mike Jones; [email-masked]
Subject: RE: [Cose] Review of draft-schaad-cose-msg-01

Jim

From: Brian Campbell [mailto:[email-masked]]
Sent: Tuesday, July 07, 2015 1:36 PM
To: Justin Richer
Cc: Mike Jones; Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Review of draft-schaad-cose-msg-01

I believe the charter uses the term in the broader and traditional sense that Wikipedia<https://en.wikipedia.org/wiki/Key_management>, for example, talks about it, like "dealing with the generation, exchange, storage, use, and replacement of keys" including "key servers [and] user procedures."

On Tue, Jul 7, 2015 at 1:54 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps I’m missing something, but as chair I feel the need to point out this line in our current charter for you all to consider:

working group.

 — Justin

On Jul 7, 2015, at 3:50 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                Thanks,
                                                                -- Mike

From: Mike Jones
Sent: Tuesday, June 30, 2015 2:54 PM
To: 'Jim Schaad'; [email-masked]<mailto:[email-masked]>
Subject: RE: [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.

MAJOR ISSUES

[JLS] See above.

•        HMAC without key management

•        Single signature

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

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

to beginning like this:

   {

MINOR ISSUES

a.  Change:

c.  Change:

d.  Change:
  These two buckets

3.1.  COSE Headers

e.  Change:

f.  In Table 2, change:

4.  Signing Structure

5.  Encryption Object

5.1.1.  Direct Encryption

n.  The spec says:

6.  MAC Objects

7.  Key Structure

p.  The spec says:

r.  The spec says:

w.  The spec says:

Appendix C.  Examples

NITS

CONCLUSIONS

                                                            Best wishes,
                                                            -- Mike

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

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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 9 Jul 2015 10:50:31 -0600

I wasn't necessarily suggesting that a new/different term be used (and
apologize for a general ignorance about CMS). I just wanted to reconcile
how “key management” could be explicitly out of scope in the charter while
unavoidably in scope for the document.

On Tue, Jul 7, 2015 at 4:40 PM, Jim Schaad <[email-masked]> wrote:

> I am more than willing to have a different term for “Key Management”.
> However, I have inherited the term from CMS (RFC 2630) where section 12.3
> talks about key management algorithms.
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Tuesday, July 07, 2015 1:36 PM
> *To:* Justin Richer
> *Cc:* Mike Jones; Jim Schaad; [email-masked]
> *Subject:* Re: [Cose] Review of draft-schaad-cose-msg-01
>
>
>
> that Wikipedia <https://en.wikipedia.org/wiki/Key_management>, for
> example, talks about it, like "dealing with the generation, exchange,
> storage, use, and replacement of keys" including "key servers [and] user
> procedures."
>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 9 Jul 2015 10:46:11 -0700

It may be that it needs to be a different term, others might raise the same issue.  I feel off at the moment because I think I probably wrote that sentence in the charter as was not being consistent.

Jim

From: Brian Campbell [mailto:[email-masked]] 
Sent: Thursday, July 09, 2015 9:51 AM
To: Jim Schaad
Cc: Justin Richer; Mike Jones; [email-masked]
Subject: Re: [Cose] Review of draft-schaad-cose-msg-01

I wasn't necessarily suggesting that a new/different term be used (and apologize for a general ignorance about CMS). I just wanted to reconcile how “key management” could be explicitly out of scope in the charter while unavoidably in scope for the document. 

On Tue, Jul 7, 2015 at 4:40 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Jim

From: Brian Campbell [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, July 07, 2015 1:36 PM
To: Justin Richer
Cc: Mike Jones; Jim Schaad; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Cose] Review of draft-schaad-cose-msg-01

    

 — Justin

                                                                Thanks,

                                                                -- Mike

From: Mike Jones 

 

MAJOR ISSUES

[JLS] See above.

*        Single signature

   {

     1: 3,

     2: h'a10104',

   6ad9930',

to beginning like this:

   {

   6ad9930',

MINOR ISSUES

a.  Change:

to:

c.  Change:

   |             |        | or not?                                    |

to:

d.  Change:

  These two buckets

to:

  These two buckets

3.1.  COSE Headers

e.  Change:

      understand.

to:

      understand.

f.  In Table 2, change:

   |          |       |          |           |                         |

   |          |       |          |           | a JWK key               |

   |          |       |          |           |                         |

to:

   |          |       |          |           |                         |

   |          |       |          |           |                         |

   |          |       |          |           |                         |

4.  Signing Structure

   authorization is done.

5.  Encryption Object

5.1.1.  Direct Encryption

n.  The spec says:

      secret.

6.  MAC Objects

7.  Key Structure

p.  The spec says:

   present for all keys.

r.  The spec says:

w.  The spec says:

      AES-CCM [RFC3610].

Appendix C.  Examples

         3: {

         },

NITS

CONCLUSIONS

                                                            Best wishes,

                                                            -- Mike

---

From: Brian Campbell <[email-masked]>
Date: Thu, 9 Jul 2015 12:03:55 -0600

Yeah, maybe so. Kathleen (cc'd) just cited "management [being] explicitly
out-of-scope for COSE as stated in the charter" at
http://www.ietf.org/mail-archive/web/jose/current/msg05169.html

So perhaps the charter needs to be clarified or a new term used in the
draft.

On Thu, Jul 9, 2015 at 11:46 AM, Jim Schaad <[email-masked]> wrote:

> It may be that it needs to be a different term, others might raise the
> same issue.  I feel off at the moment because I think I probably wrote that
> sentence in the charter as was not being consistent.
>
>
>
> Jim
>
>
>
>
>
> *Sent:* Thursday, July 09, 2015 9:51 AM
> *To:* Jim Schaad
> *Cc:* Justin Richer; Mike Jones; [email-masked]
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 09 Jul 2015 23:00:31 +0200

We just had a discussion at the IoT directorate that maybe we need a
document explaining terms that historically have been causing confusion,
because of their widely varying meanings.

"Key management" was one of the terms cited -- it certainly qualifies.

Grüße, Carsten

Jim Schaad wrote:
> same issue.  I feel off at the moment because I think I probably wrote
> that sentence in the charter as was not being consistent.