CBOR Object Signing and Encryption (COSE)
RFC 8152

Note: This ballot was opened for revision 18 and is now closed.

(Stephen Farrell) (was Discuss) Yes

Comment (2016-11-22)
No email
send info
Thanks all for the discussion and resolution of the mandatory 
alg-id issue. I think we've ended up in a better place. (Well, I at 
least hope so:-).

While I'm clearing the discuss now, it might be no harm to just
check with the set of folks who commented recently on this topic
before sending this to the RFC editor in case there're any other
non-problematic tweaks that might be beneficial. (I forget if
that was already done or not, sorry;-)

(Kathleen Moriarty) Yes

Comment (2016-09-29 for -19)
No email
send info
IANA comments need to be addressed and a possible revision of the IANA section:

 "Also, this is the document where
> registries are composed of multiple tables, and at least two tables don’t
> have the same columns. In one case a registry is made of 12 tables that are
> listed out of order. It would be good if they could just provide the
> consolidated registries in the IANA Considerations section.  I think this
> will require a new IANA Considerations section."

A decision is needed on the CDDL reference as well.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2016-09-27 for -18)
No email
send info
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?

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2016-09-27 for -18)
No email
send info
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?

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2016-10-17 for -22)
No email
send info
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].

Alvaro Retana No Objection