[plasma] Comments on Message Access Control Requirements Draft

Jean-Paul Buu-Sao <jean-paul.buu-sao@tscp.org> Mon, 23 July 2012 08:26 UTC

Return-Path: <jean-paul.buu-sao@tscp.org>
X-Original-To: plasma@ietfa.amsl.com
Delivered-To: plasma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBE821F86C3 for <plasma@ietfa.amsl.com>; Mon, 23 Jul 2012 01:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDBK8W5jf+GE for <plasma@ietfa.amsl.com>; Mon, 23 Jul 2012 01:26:09 -0700 (PDT)
Received: from smtp154.iad.emailsrvr.com (smtp154.iad.emailsrvr.com [207.97.245.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1CC21F8687 for <plasma@ietf.org>; Mon, 23 Jul 2012 01:26:09 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp45.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 797FC9024E for <plasma@ietf.org>; Mon, 23 Jul 2012 04:26:08 -0400 (EDT)
X-Virus-Scanned: OK
Received: from smtp192.mex02.mlsrvr.com (smtp192.mex02.mlsrvr.com [204.232.137.43]) by smtp45.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTPS id 6790690237 for <plasma@ietf.org>; Mon, 23 Jul 2012 04:26:08 -0400 (EDT)
Received: from IAD2MBX12.mex02.mlsrvr.com ([172.23.11.89]) by IAD2HUB03.mex02.mlsrvr.com ([172.23.10.67]) with mapi; Mon, 23 Jul 2012 04:25:47 -0400
From: Jean-Paul Buu-Sao <jean-paul.buu-sao@tscp.org>
To: "plasma@ietf.org" <plasma@ietf.org>
Date: Mon, 23 Jul 2012 04:24:36 -0400
Thread-Topic: Comments on Message Access Control Requirements Draft
Thread-Index: Ac1oq3CVME5z2zCFRuOeo2bgsbCo/g==
Message-ID: <AA2F43DF2752504B980D6D4D3DC76A39059F8EAD39@IAD2MBX12.mex02.mlsrvr.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [plasma] Comments on Message Access Control Requirements Draft
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2012 08:26:10 -0000

Greetings,

Please find my comments on the PLASMA draft 01: http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf:

1) Policy Data Binding

Section 4.2.1: 
"The chief strength of binding by names is once bound to the data the association with the policy travels with the data. The chief weakness in binding by name is it requires the reference to be strongly bound to the data [...] This model is choosing to use binding by name because we need to encrypt the data which means we will [be] impacting the storage format anyway which negates the main weakness of binding my name."
TSCP approves of the choice of "binding by name". Another chief strength that you did not quote, and which is key differentiator to TSCP, is to allow policy change, with no impact on the data. This requirement cannot be met with binding by value or by description.
The draft is silent on how the name would be expressed. Can it be any arbitrary identifier, which precise syntax and semantics could be defined by a community of interest defined profile?

2) Closed versus Open environment
Section 4.4: 
"(A) The PEP verifies the certificate in the signed metadata then determines <<via local policy>> if it want to process the protected information based on the identity of the PDP
(D) The PDP decrypts the metadata, de-references the policy pointers and determines the set of access rules based on the <<policy published by the PAP>>. The PDP then determines the set of subject attributes it needs to evaluate the access rules. The PDP can the use PIP is has relationships with to query attributers about the subject. The list of attributes the PDP is missing is then returned to the PEP"
As stated the workflow implies a "closed environment". TSCP expected to see a workflow that could as well support an "open environment", whereas not all referenced policies are necessarily known by the local PDP/PAP ahead of time.
As a related topic, Policy Publication Point (PPP), lightly introduced in the Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. In view of the support for "open environments", TSCP expected to see more requirements  on PPP.

3) Advanced Policies
Section 4.5.2:  "Advanced policy is intended to be used where one or more arbitrary policies are required on the content. It is intended to target more complex scenarios such as content with regulated information or content subject to other organization and contractual policies. The input set of attributes is defined by the policies and can be either primordial or derived attributes or both. Multiple policies have a logical relationship e.g. they can be <<AND or ORed together>>. <<It is not expected that all Plasma clients support advances policy>>."

TSCP mandates a support for "advances policies". A typical example is to support documents that must be simultaneously protected under an Export Control policy (e.g. ITAR Technical Assistance Agreement) and an Intellectual Property policy (e.g. Proprietary Information Exchange Agreement). In this case of multiple policies, TSCP requires that all the applicable policies are to be evaluated, with each one of the specified policy allowing the required access. 
So this cannot just be a simple OR, as the Plasma draft states.

4) Policy Expression Language
The draft is silent on the positioning of PLASMA with Policy Expression Languages. Is there one in particular that PLASMA mandates (if so, which one), or is the specification agnostic (if so, what are the baseline requirements in terms of expressiveness)?
Some organizations have developed and validated a broad set of policies, expressed in a Policy Expression Language of their choosing (e.g. XACML 2.0), and need to be able to reuse them.

Thanks,
Jean-Paul Buu-Sao, TSCP