[Vcon] Roman Danyliw's No Objection on charter-ietf-vcon-00-02: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 05 October 2023 01:17 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: vcon@ietf.org
Delivered-To: vcon@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D14C151088; Wed, 4 Oct 2023 18:17:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: vcon-chairs@ietf.org, vcon@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.12.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <169646864851.52129.15976734485126936288@ietfa.amsl.com>
Date: Wed, 04 Oct 2023 18:17:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/vcon/haryiVqeIjot5_LRL76AfHcg29U>
Subject: [Vcon] Roman Danyliw's No Objection on charter-ietf-vcon-00-02: (with COMMENT)
X-BeenThere: vcon@ietf.org
X-Mailman-Version: 2.1.39
List-Id: container for conversation data <vcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcon>, <mailto:vcon-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vcon/>
List-Post: <mailto:vcon@ietf.org>
List-Help: <mailto:vcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcon>, <mailto:vcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Oct 2023 01:17:28 -0000

Roman Danyliw has entered the following ballot position for
charter-ietf-vcon-00-02: 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.)



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



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

** Stepping back from the details of the charter text, this work appears to be
trying to define an object security model for a JSON data model for
conversational data.  This is my first exposure to the vCon and I don’t know if
this was discussed prior.  Please let me know if this has been adjudicated
already.  As a starting point for this work, has JOSE’s JWE (RFC7516) been
considered?  The JOSE ecosystem provides a rich sent of container formats in
JSON and associated code points/identifiers for algorithms.  I don’t mean to
invent a solution, but wondering if the use cases or desired security
properties preclude the definition of this domain-specific (conversational
data) JSON data model that can then be secured with an already standardized
JOSE security containers?  I’m trying to ensure that snippet of IETF technology
aren’t reinvented unless it is necessary.

** I concur with Lars that the use cases should be pruned from the charter text.

** Paragraph 2.  Opposing forces are being presented, but I don’t understand
why “privacy of personal data” necessarily conflicts with “integrating data
with multiple sources” or “transitioning from one provider to the next”.

** Paragraph 2.  Per “There are also three open source systems implementing
vCon”, what is this text meant to convey?  Are there already draft
specification for vCon that this WG will adopt? Or, is this “vCon” in the sense
of open source solution generically in the space of conversational data
management?

** There are a few places where security related things are said:
(a) “The work group is to define a JSON-based container for conversational
data, along with mechanisms to protect the integrity and privacy of data in the
container.

(b) “Define/specify a mechanism for proving integrity of the conversation data”

(c) “Define/specify a mechanism for encrypting of the objects enclosed in the
vCon conversation data container to provide confidentiality of the data
independent of transport such that some parts of the vCon may be disclosed to
different parties”

-- “privacy” is mentioned in (a) and “encrypting”/”confidentiality” is
mentioned in (b).  I recommend being precise on the security property, is it
“confidentiality” that is desired?

-- just checking, this scope is really is only “integrity”, that is “no one
modified the bits”.  There is no interest in authenticity, that is “the bits
came from who I expected them to come from”.

** Per the scope paragraph saying:

* Data minimization should be considered for each of the use case

What does this mean in terms of deliverables? Or properties of the container?

** Per out-of-scope paragraph saying:

* The encryption keying.

Can this be clarified?  Is this saying key management is out of scope?  MTI
algorithms?

** In either the milestone or the scope paragraphs describe the status
(Proposed Standard, Informational, etc) of each planned document.