Subject: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 27 Sep 2016 20:39:36 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-cose-msg-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-msg/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Jim Schaad <[email-masked]>
Date: Wed, 28 Sep 2016 22:39:31 -0700

Changes are in https://github.com/cose-wg/cose-spec/pull/181

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Tuesday, September 27, 2016 8:40 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
draft-
> [email-masked]
> Subject: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18:
(with
> COMMENT)
email
> addresses included in the To and CC lines. (Feel free to cut this
introductory
> paragraph, however.)
it a signed
> integer than can be negative or non-negative? (contrasting with uint?)
(Or is int
> merely a parent of nint and uint?)

Using the terminology of CDDL, this is really unsigned or negative.
Specifically, it would be the union of uint (unsigned - 0 and above) and
nint (negative integer strictly less than 0).  Both of these types have
different major types so they are coded differently.

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

I kind of thought that it was sufficiently explicit.  Does it work better
for you if the first sentence reads:

If a label is used in one of the maps, it MUST appear only once in that map
and it MUST NOT appear in the other map.

Then leave the rest of the text in the paragraph alone.

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

I plead the 5th.  It would be because I pasted it in the wrong place and
missed the fact.  I have been acting as if this was a normative reference.
Kathleen, is there a problem if I just move this reference?

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

The not already exists in the XML.

> -1, first paragraph, last sentence: Comma splice.
Changed in response to the Gen-Art review already.

> -1, 2nd paragraph: MAC usually expands to Message Authentication _Code_.
Yeah, Changed in response to the Gen-Art review already

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

> -3, definition of protected:
Did you lose some text at this point?

> -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.
Added as a note to the XML

taken that data
> Is this talking about data framing, or something else?

That is probably not the term that I would use for this, but it is similar.
The requirement is to make sure that data from one item is separated from
another item so that when the hash string is constructed the same hash
string cannot be constructed for two different pairs of items.

Jim

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Sep 2016 18:06:55 -0600

> Using the terminology of CDDL, this is really unsigned or negative.

(This is actually CBOR terminology that CDDL just inherits.  These terms
would be in use even without using CDDL.)

> different major types so they are coded differently.

Exactly.

Grüße, Carsten

(CBOR background: unsigned numbers are much more frequent in constrained
environments than signed ones, so they are major type 0.  Signed numbers
are coded similar to the way they are in protobuf, except that we got
rid of the shifting to put the sign bit somewhere and instead just added
major type 1 to indicate a negative.  So we have unsigned (0..) and
negative (..-1) as separate major types.)