Re: [Cbor] Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)

[Jim Schaad <[e-mail]>]

One response down below.

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[e-mail]> 
Sent: Wednesday, September 18, 2019 4:41 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Jim Schaad <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cbor-sequence-01: Yes

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-cbor-sequence/



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

Section 2

   o  Otherwise, decode a single CBOR data item from the bytes of the
      CBOR sequence, and insert the resulting CBOR data model value at
      the start of the result of decoding the rest of the bytes as a
      CBOR sequence.  (A streaming decoder would therefore simply
      deliver zero or more CBOR data model values, each of which as soon
      as the bytes making it up are available.)

nit: I think s/each of which/each of which is delivered/, or just take Barry's suggestion that addresses the nit differently.

Section 3

   The use case for the "+cbor-seq" structured syntax suffix is the same
   as for "+cbor": It SHOULD be used by a media type when parsing the

nit: if the use case is literally "the same as" for "+cbor" then there would seem to be literally no value in having "+cbor-seq".  So perhaps "essentially the same as" or similar would be more appropriate?

Section 5

I might note that when COSE is applied to the elements of a sequence, the cryptographic protection is on a per-element basis, and thus there is no guarantee of relationship between level of protection, source authentication, time of generation, etc., across members of the sequence.

[JLS] I don't believe that there is any requirement that there be only a single element of a sequence inside of a COSE wrapper.  If three elements are generated at the same time then all three could be placed into a single encryption.  Thus I am not sure how to say that the protection is on a per-element basis.  

While it is true there is not necessarily a relationship between each COSE object, each COSE object does have the ability to provide that information for each element of the sequence.  You have more than what you started with, where you had none of that, and now you have it for each element.  You just need to do key validation on each decryption.  That might be a better way to say things in that a stream could have multiple sources and thus multiple keys.

Jim


Section 6.1

It's probably best to treat the following as a side note and thus not an actionable comment, but couldn't the URL fragment fairly easily be used to extract numbered elements of the sequence?