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

Jim Schaad <ietf@augustcellars.com> Thu, 26 September 2019 00:43 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70FC120251; Wed, 25 Sep 2019 17:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ1dKndjlc4T; Wed, 25 Sep 2019 17:43:22 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081CB1201C6; Wed, 25 Sep 2019 17:43:22 -0700 (PDT)
Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 25 Sep 2019 17:43:15 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Benjamin Kaduk' <kaduk@mit.edu>, 'Carsten Bormann' <cabo@tzi.org>
CC: cbor@ietf.org, draft-ietf-cbor-sequence@ietf.org, 'The IESG' <iesg@ietf.org>, cbor-chairs@ietf.org
References: <156885006199.4487.4211790094945761661.idtracker@ietfa.amsl.com> <008401d56e91$caf513f0$60df3bd0$@augustcellars.com> <20190919024014.GC14253@kduck.mit.edu> <F6D5F6AA-BDA4-4D50-93C1-6CF35132E89D@tzi.org> <20190926001650.GT6424@kduck.mit.edu>
In-Reply-To: <20190926001650.GT6424@kduck.mit.edu>
Date: Wed, 25 Sep 2019 17:43:12 -0700
Message-ID: <01df01d57403$624f3660$26eda320$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEizBJKGRp1vGdGTbmCKwQZxgn0ogGKu41ZAy+q73YCxFaH3gHaJWP0qFeneIA=
Content-Language: en-us
X-Originating-IP: [192.168.1.159]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/c1aZTBaWPLxQ63la7veaiOFYjUM>
Subject: Re: [Cbor] Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 00:43:25 -0000


-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu> 
Sent: Wednesday, September 25, 2019 5:17 PM
To: Carsten Bormann <cabo@tzi.org>
Cc: Jim Schaad <ietf@augustcellars.com>; cbor@ietf.org;
draft-ietf-cbor-sequence@ietf.org; The IESG <iesg@ietf.org>;
cbor-chairs@ietf.org
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:
> On Sep 19, 2019, at 04:40, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> > 
> > On Wed, Sep 18, 2019 at 07:27:29PM -0700, Jim Schaad wrote:
> >> One response down below.
> >> 
> >> -----Original Message-----
> >> From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
> >> Sent: Wednesday, September 18, 2019 4:41 PM
> >> To: The IESG <iesg@ietf.org>
> >> Cc: draft-ietf-cbor-sequence@ietf.org; Jim Schaad 
> >> <ietf@augustcellars.com>; cbor-chairs@ietf.org; 
> >> ietf@augustcellars.com; cbor@ietf.org
> >> Subject: Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with 
> >> COMMENT)
> >> 
> >>> 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.  
> > 
> > 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

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?

[JLS] That is completely correct.

-Ben