CBOR Object Signing and Encryption (COSE)
draft-ietf-cose-msg-24

Thank you for addressing my earlier comments. I have one small issue that resulted in a recent change:

This is a well written document, despite its length. Thank you for that.

Some specific comments:

content type:  This parameter is used to indicate the content type of
      the data in the payload or cipher text fields.  Integers are from
      the "CoAP Content-Formats" IANA registry table [COAP.Formats].
      Text values following the syntax of Content-Type defined in
      Section 4.2 of [RFC6838] omitting the prefix string "Content-
      Type:".

This is not quite right, as Section 4.2 of [RFC6838] doesn't define Content-Type header field. It defines:

     type-name = restricted-name
     subtype-name = restricted-name

     restricted-name = restricted-name-first *126restricted-name-chars
     restricted-name-first  = ALPHA / DIGIT
     restricted-name-chars  = ALPHA / DIGIT / "!" / "#" /
                              "$" / "&" / "-" / "^" / "_"
     restricted-name-chars =/ "." ; Characters before first dot always
                                  ; specify a facet name
     restricted-name-chars =/ "+" ; Characters after last plus always
                                  ; specify a structured syntax suffix

So you should say something like this instead:

      Text values following the syntax "<type-name>/<subtype-name>",
      where <type-name> and <subtype-name> are defined in
      Section 4.2 of [RFC6838].

A few minor comments:

Substantive:

-1.3, definition of "int": Is that really _unsigned_ or negative?  Or is it a signed integer than can be negative or non-negative? (contrasting with uint?)  (Or is int merely a parent of nint and uint?)

-3: What is the scope of uniqueness for map labels? I expected it to be the map, but the text immediately aftewards suggests the scope may be the whole message. Whatever the answer, it would help to be explicit.

- Informative References: [I-D.irtf-cfrg-eddsa]: Other algorithm references are normative. Why not this one?

Editorial:

"Contributing to this Memo" section: Is this intended to stay in the final RFC? If not, it might be worth a note to the RFC editor.

-1, first paragraph, last sentence: Comma splice.

-1, 2nd paragraph: MAC usually expands to Message Authentication _Code_.

-2, 6th paragraph, last sentence: s/method/methods  (assuming the following list is a list of methods, and not steps in a method.

-3, definition of protected: 

-4.1,  "COSE_Sign_Tagged = #6.991(COSE_Sign) ; Replace 991 with TBD1": Is the comment intended as a note to the RFC editor? If so, it might be helpful to label it as such.

-4.3, first bullet: "If multiple items are included, care needs to be taken that data
      cannot bleed between the items."
Is this talking about data framing, or something else?

I'm going to be a No Objection for this doc no matter what, so it's safe to answer my question :-)

This is for use with CoAP, right? Would you rely on CoAP for fragmentation, if that's required?