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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 18 Sep 2019 16:41:02 -0700

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.

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?

---

From: Jim Schaad <[email-masked]>
Date: Wed, 18 Sep 2019 19:27:29 -0700

One response down below.

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

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

Section 2

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

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?

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Sep 2019 21:40:14 -0500

> [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 coul…

Perhaps (presumably?) this is just a question of semantics, but from where
I sit, the output of a COSE operation is a CBOR array (that has at least
three elements and maybe more depending on context, but that's not really
relevant for the point I want to make).  If I'm using COSE to protect
(some) elements of a CBOR sequence, then what goes into the sequence is the
CBOR array resulting from the COSE operation.  Undoing that COSE operation
may or may not produce more than one CBOR object, but those objects are not
elements of the CBOR sequence in question; they are contained within an
element of the CBOR sequence in question.  So, to me, the elements of the
sequence are necessarily a single COSE output, even if the consuming
application may assign different semantics to them.

> 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 mor…

Sure, making positive statements about what can be done is preferrable to
just making statements about what is not guaranteed (though perhaps both
would be needed; I haven't thought about what the text would look like very
much).

-Ben

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 Sep 2019 14:21:26 +0200

> would be needed; I haven't thought about what the text would look like very

I have tried to address this in https://github.com/cbor-wg/seq/commit/0dcd3cf9e442a793a30a2093c6e42260f0fc6d80

Grüße, Carsten

> 
> -Ben
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 Sep 2019 14:53:53 +0200

Hi Benjamin,

thank you for your review and your Yes vote.

> On Sep 19, 2019, at 01:41, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> […]
> 
> 
> ———————————————————————————————————
> On Sep 19, 2019, at 01:40, IETF Secretariat <[email-masked]> wrote:
> 
> Section 2
> 

I went for Barry’s suggestion (with a small addition).

Now in
https://github.com/cbor-wg/seq/commit/ffa99b279f6ba91176b1af418388873f57390585

> “essentially the same as" or similar would be more appropriate?

I went for “analogous”, because this really is an analogy.

Now in
https://github.com/cbor-wg/seq/commit/25c5337e9d7363c4db670eaff8b6d71be314db3a

> authentication, time of generation, etc., across members of the

(See previous message.)

> to extract numbered elements of the sequence?

This is indeed a possibility.  However, I think this subject should better be addressed again when we have a “JSON pointer”/“JSON path” like way to reach into CBOR data structures, which we could use as a fragment identifier syntax for CBOR data items as well.  We can then treat the CBOR sequence similar to a top level array in a CBOR data item (and this also allows us to reach into specific items of the sequence).

(The original reason we don’t have a fragment syntax is that we simply copied json-seq, which doesn’t have one either.)

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Sep 2019 17:16:50 -0700

> I have tried to address this in https://github.com/cbor-wg/seq/commit/0dcd3cf9e442a793a30a2093c6e42260f0fc6d80

I think that works; thanks.
Just to confirm my understanding: since COSE wraps the plaintext content in
a bstr, there's no change needed to allow for the sequence to be present?

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Wed, 25 Sep 2019 17:43:12 -0700

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Wednesday, September 25, 2019 5:17 PM
To: Carsten Bormann <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked];
[email-masked]; The IESG <[email-masked]>;
[email-masked]
Subject: Re: [Cbor] Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01:
(with COMMENT)

On Wed, Sep 25, 2019 at 02:21:26PM +0200, Carsten Bormann wrote:
> >> Cc: [email-masked]; Jim Schaad 
> >> <[email-masked]>; [email-masked]; 
> >> [email-masked]; [email-masked]
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.  
> > 
> > Perhaps (presumably?) this is just a question of semantics, but from 
> > where I sit, the output of a COSE operation is a CBOR array (that 
> > has at least three elements and maybe more depending on context, but 
> > that's not really relevant for the point I want to make).  If I'm 
> > using COSE to protect
> > (some) elements of a CBOR sequence, then what goes into the sequence 
> > is the CBOR array resulting from the COSE operation.  Undoing that 
> > COSE operation may or may not produce more than one CBOR object, but 
> > those objects are not elements of the CBOR sequence in question; 
> > they are contained within an element of the CBOR sequence in 
> > question.  So, to me, the elements of the sequence are necessarily a 
> > single COSE output, even if the consuming application may assign
different semantics to them.
> > 
> >> 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.
> > 
> > Sure, making positive statements about what can be done is 
> > preferrable to just making statements about what is not guaranteed 
> > (though perhaps both would be needed; I haven't thought about what 
> > the text would look like very much).
> 
> I have tried to address this in 
> https://github.com/cbor-wg/seq/commit/0dcd3cf9e442a793a30a2093c6e42260
> f0fc6d80

[JLS] That is completely correct.

-Ben