Is it the client= ?=A0 The Plasma CMS Processing document, Page 8, describes how the 'Key= Identifier' is a random generated value (Created by the client?).=A0

=A0

Is=A0it the Plasma Server?=A0 On Page 13 the KekIdentifi= er is a value that matches the KEKIdentifier.KeyIdentifier value in the rec= ipient info information (I have read this to mean that the EPS-LockBox vers= ion must match the KeyIdentifier in the envelopedData created by the client= , meaning the KeyIdentifer must be transported between client and plasma se= rver).=A0

=A0

From this I thought=A0the client created the random valu= e and passed=A0it across to the server=A0inside the 'GetCMSToken' r= equest. However, I can't see this described in the request.=A0 Is this = missing from the request documentation, or does this Imply that the client = has to extract the KeyIdentifer from the EPS-KEK returned in the GetCMSToke= n response, but this is encrypted and only the Plasma Server has access to = this.=A0 Or have I mis-read this completely?

=A0

Alan.

=A0

Boldon James.

--047d7b15a8a50ece1b04c5167e05-- From jean-paul.buu-sao@tscp.org Wed Jul 18 02:32:42 2012 Return-Path: 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 1D56C21F8685 for ; Wed, 18 Jul 2012 02:32:42 -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 Th4e-zIOSL3D for ; Wed, 18 Jul 2012 02:32:41 -0700 (PDT) Received: from smtp204.iad.emailsrvr.com (smtp204.iad.emailsrvr.com [207.97.245.204]) by ietfa.amsl.com (Postfix) with ESMTP id CEFE421F8647 for ; Wed, 18 Jul 2012 02:32:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp50.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1E5753707F6; Wed, 18 Jul 2012 05:33:30 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex02.mlsrvr.com (smtp192.mex02.mlsrvr.com [204.232.137.43]) by smtp50.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTPS id 002FF370A93; Wed, 18 Jul 2012 05:33:29 -0400 (EDT) Received: from IAD2MBX12.mex02.mlsrvr.com ([172.23.11.89]) by iad2hub11.mex02.mlsrvr.com ([172.23.10.75]) with mapi; Wed, 18 Jul 2012 05:33:18 -0400 From: Jean-Paul Buu-Sao To: Hal Lockhart , "plasma@ietf.org" Date: Wed, 18 Jul 2012 05:32:10 -0400 Thread-Topic: [plasma] Comments from OASIS XACML TC on Message Access Control Requirements Draft Thread-Index: Ac1H6lbPcMbbyrkOSh6SnxWtQWAXNwc3MQug Message-ID: References: <6aebd3ed-fe64-4f3d-a459-4459dbfd76f9@default> In-Reply-To: <6aebd3ed-fe64-4f3d-a459-4459dbfd76f9@default> 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: Re: [plasma] Comments from OASIS XACML TC 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:32:42 -0000 Greetings, Please find below some additional comments focused on 4.3 Content Creation = and 4.4 Content Consumption, workflows: Section 4.3: Content Creation Workflow "The content creation PEP is configured with the set PIP's and PDP's it tru= sts" (p.39) This assumes that the PEP is directly associated to all (possibly remote) a= pplicable PDPs. This will not scale with a large number of applicable PDPs.= Instead, would you consider a local PDP proxy, which will then be able to = cache information related to remote PDPs when applicable? "The content creation PEP summits a request to all the trusted PDPs for the= set of roles it allows for the subject. The subject is authenticated and a= uthorized for the roles via attributes from the PIP. The PIP attributes can= be obtained by the PDP either via front-end (related to the PDP from the P= IP via the subject) or back-end (direct exchange between the PDP and the PI= P) processing"(p. 39) See comment above about scalability and availability. The result of the req= uest can be locally cached by a local proxy, caching would be impossible ot= herwise. Also, authorization is not always solely based upon subject attributes that= represent set of roles. "The content creation PEP receives a list of roles the PDP can [be] configu= red for the subject" (p.39) The same comment as above applies, regarding roles. Additionally the Conten= t Creation PEP must not evaluate the attributes for authorization decision,= as this is the role of the PDP. So why should it care receiving the list o= f roles that can be configured for the subject? "The PEP submits a request for the policy collection for each role. Additio= nal attributes may be required from the PIP to authorize the release of the= BCPC token" (p. 39) Not necessarily optimal: the list of "roles" may be very large. Why would t= he PEP request the associated policy collection on such a large list, befor= e even considering the intention of the subject? Shouldn't the PEP rather w= ait for the subject to express its intention, that is: explicitly specify t= he subset of the policies that are to be applied to the content to be creat= ed? The general feedback on this workflow is that the Content Creation PEP "boo= tstrap" steps 1 to 4 provided for illustration only, and are implementation= dependent. Also, BCPC is not defined in the document "(i) The user creates the new content (ii) The user select the appropriate business context for the content, then= selects one or more policies applicable to the content (iii) The PEP encrypts the content with one or more locally generated CEKs"= (p. 40) Once policies are selected, I'd like to suggest that the standard XACML flo= w applies: the PEP asks authorization decision to the PDP, who may return "= Permit" with obligation to encrypt the content; encryption is a policy deci= sion, not a unilateral decision from the PEP. "(iv) The PEP submits the CEK, the set of requires policies to be applied a= nd the hash of the encrypted content to the PDP. The CEK can be a raw key o= r a CEK key encrypted by a KEK if the user does not want the PDP to have th= e ability to access the plain text data. (v) The PDP generates the encrypted metadata which contains the list of pol= icies and the CEKs. The metadata is encrypted by the PDP for itself. The PD= P includes a URL for itself and the hash of the protected content as authen= ticated attributes then signs the encrypted metadata." (p. 40) This, IMO, goes well beyond the responsibility of the PEP (as defined in th= e draft and in XACML core spec). This should be either the Creation Content= PEP, or better a specific Data Encryption Point, to be defined. "(vi) The PDP returns the metadata to the PEP (vii) The PEP attaches the PDP metadata to the protected content and distri= butes the content." (p. 40) The general comments about this workflow are: a) The standard XACML flow can be preserved between the Content Creation PE= P and the PDP: content encryption would then be a policy obligation express= ed by the PDP (as part of a permit decision) and enforced by the PEP b) In case of required content encryption, the Content Creation PEP would c= arry on encryption by perhaps interacting with a Data Encryption Point, whi= ch can execute the steps related to encryption as described in the draft. Section 4.4. Content Consumption Workflow "(A) The PEP verifies the certificate in the signed metadata then determine= s via local policy if it want to process the protected information based on= the identity of the PDP" (p. 40) This implies a policy decision, which has to be taken by a local PDP. Also = note that there are potentially multiple policies, hence potentially multip= le associated PDPs. This strengthen the case for a local PDP proxy that nee= ds to take this decision "(B) The PEP verifies the signature on the metadata token and the binding t= o the encrypted data by hashing the encrypted information and comparing it = to the authenticated attribute in the metadata" (p. 40) Surely this is not the role of the PEP but of a Data Decryption Point that = the PEP must be associated with "(C) The PEP forwards the signed metadata and requests a read token from th= e PDP using the location in the authenticated attribute in the metadata" (p= . 40) The PEP role is overloaded. I suggest that it is the local PDP which will r= equest these read token from the remote PDPs=20 "(D) The PDP decrypts the metadata, de-references the policy pointers and d= etermines 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 que= ry attributers about the subject. The list of attributes the PDP is missing= is then returned to the PEP" (p. 40) "(F) Once the PDP has a complete set of attributes, and the attribute value= s match those required under the access policy, the PDP releases the CEK to= the PEP along with a TTL which defines how long the PEP can use the CEK be= fore it must discard the CEK and reapply for access." (p. 40) The PDP role is overloaded with encryption tasks that may be better handled= by encryption points (useful additions to the XACML architecture) Thanks, Jean-Paul Buu-Sao, TSCP -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Hal Lockhart Sent: Monday, June 11, 2012 17:53 To: plasma@ietf.org Subject: [plasma] Comments from OASIS XACML TC on Message Access Control Re= quirements Draft In response to Requirements for Message Access Control (http://tools.ietf.= org/pdf/draft-freeman-plasma-requirements-01.pdf) the OASIS XACML Technical= Committee has agreed to submit the attached comments. The public link to this document is: https://www.oasis-open.org/committees/download.php/46049/Proposed%20respons= e%20to%20Plasma%20v1-3.docx Hal Lockhart Bill Parducci Co-chairs OASIS XACML TC From jimsch@nwlink.com Wed Jul 18 15:22:36 2012 Return-Path: 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 1116611E81C0 for ; Wed, 18 Jul 2012 15:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LXEEphFYUA2X for ; Wed, 18 Jul 2012 15:22:34 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC4211E80BC for ; Wed, 18 Jul 2012 15:22:34 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2A54238F06; Wed, 18 Jul 2012 15:23:25 -0700 (PDT) From: "Jim Schaad" To: "'Alan Borland'" , References: In-Reply-To: Date: Wed, 18 Jul 2012 15:21:59 -0700 Message-ID: <02d101cd6533$c0239fb0$406adf10$@nwlink.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D2_01CD64F9.13C711A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBSHVfCS46jvYtcH0EF1jjoC1EJJfH1m9g Content-Language: en-us Subject: Re: [plasma] Who creates the 'keyIdentifier'? X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime $plasma$ bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:22:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D2_01CD64F9.13C711A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The value is created by the client and passed to the server. If there is no field this is an oversight on my part. I will look at this later today. From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Alan Borland Sent: Wednesday, July 18, 2012 1:32 AM To: plasma@ietf.org Subject: [plasma] Who creates the 'keyIdentifier'? I'm trying to understand who generates the 'KeyIdentifier' element in the 'KEKIdentifier' structure of the 'RecipientInfo' created by the client. Is it the client? The Plasma CMS Processing document, Page 8, describes how the 'KeyIdentifier' is a random generated value (Created by the client?). Is it the Plasma Server? On Page 13 the KekIdentifier is a value that matches the KEKIdentifier.KeyIdentifier value in the recipient info information (I have read this to mean that the EPS-LockBox version must match the KeyIdentifier in the envelopedData created by the client, meaning the KeyIdentifer must be transported between client and plasma server). >From this I thought the client created the random value and passed it across to the server inside the 'GetCMSToken' request. However, I can't see this described in the request. Is this missing from the request documentation, or does this Imply that the client has to extract the KeyIdentifer from the EPS-KEK returned in the GetCMSToken response, but this is encrypted and only the Plasma Server has access to this. Or have I mis-read this completely? Alan. Boldon James. ------=_NextPart_000_02D2_01CD64F9.13C711A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The value is created by the client and passed to the server. If = there is no field this is an oversight on my part. I will look at = this later today.

From:= = plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of = Alan Borland
Sent: Wednesday, July 18, 2012 1:32 = AM
To: plasma@ietf.org
Subject: [plasma] Who creates = the 'keyIdentifier'?

I'm = trying to understand who generates the 'KeyIdentifier' element in = the 'KEKIdentifier' structure of the 'RecipientInfo' created by the = client.

Is it the client? The Plasma CMS Processing = document, Page 8, describes how the 'KeyIdentifier' is a random = generated value (Created by the client?). =

Is it the Plasma Server? On Page 13 the = KekIdentifier is a value that matches the KEKIdentifier.KeyIdentifier = value in the recipient info information (I have read this to mean that = the EPS-LockBox version must match the KeyIdentifier in the = envelopedData created by the client, meaning the KeyIdentifer must be = transported between client and plasma = server).

From this I thought the client created the random = value and passed it across to the server inside the = 'GetCMSToken' request. However, I can't see this described in the = request. Is this missing from the request documentation, or does = this Imply that the client has to extract the KeyIdentifer from the = EPS-KEK returned in the GetCMSToken response, but this is encrypted and = only the Plasma Server has access to this. Or have I mis-read this = completely?

Alan.

Boldon = James.

------=_NextPart_000_02D2_01CD64F9.13C711A0-- From jean-paul.buu-sao@tscp.org Mon Jul 23 01:26:10 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 To: "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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/d= raft-freeman-plasma-requirements-01.pdf: 1) Policy Data Binding Section 4.2.1:=20 "The chief strength of binding by names is once bound to the data the assoc= iation 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 th= at 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 w= ith binding by value or by description. The draft is silent on how the name would be expressed. Can it be any arbit= rary identifier, which precise syntax and semantics could be defined by a c= ommunity of interest defined profile? 2) Closed versus Open environment Section 4.4:=20 "(A) The PEP verifies the certificate in the signed metadata then determine= s <> if it want to process the protected information base= d on the identity of the PDP (D) The PDP decrypts the metadata, de-references the policy pointers and de= termines the set of access rules based on the <>. The PDP then determines the set of subject attributes it needs to evalu= ate 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 miss= ing 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 a= ll referenced policies are necessarily known by the local PDP/PAP ahead of = time. As a related topic, Policy Publication Point (PPP), lightly introduced in t= he Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. In= view of the support for "open environments", TSCP expected to see more req= uirements on PPP. 3) Advanced Policies Section 4.5.2: "Advanced policy is intended to be used where one or more a= rbitrary policies are required on the content. It is intended to target mor= e complex scenarios such as content with regulated information or content s= ubject to other organization and contractual policies. The input set of att= ributes 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 <>. <>." TSCP mandates a support for "advances policies". A typical example is to su= pport documents that must be simultaneously protected under an Export Contr= ol policy (e.g. ITAR Technical Assistance Agreement) and an Intellectual Pr= operty policy (e.g. Proprietary Information Exchange Agreement). In this ca= se of multiple policies, TSCP requires that all the applicable policies are= to be evaluated, with each one of the specified policy allowing the requir= ed access.=20 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 Lan= guages. Is there one in particular that PLASMA mandates (if so, which one),= or is the specification agnostic (if so, what are the baseline requirement= s in terms of expressiveness)? Some organizations have developed and validated a broad set of policies, ex= pressed 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 From ietf@augustcellars.com Mon Jul 23 13:43:01 2012 Return-Path: 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 EE58611E808C for ; Mon, 23 Jul 2012 13:43:00 -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 62sxyr1gRGd4 for ; Mon, 23 Jul 2012 13:43:00 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09B11E808A for ; Mon, 23 Jul 2012 13:43:00 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 02DE638F3E for ; Mon, 23 Jul 2012 13:42:59 -0700 (PDT) From: "Jim Schaad" To: References: <20120706204230.23987.26959.idtracker@ietfa.amsl.com> In-Reply-To: <20120706204230.23987.26959.idtracker@ietfa.amsl.com> Date: Mon, 23 Jul 2012 13:41:35 -0700 Message-ID: <00db01cd6913$8d946460$a8bd2d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCng9bfEz2ExA0xK5Me4KAVzGQSU5mDHz9A Content-Language: en-us X-Mailman-Approved-At: Mon, 23 Jul 2012 13:44:28 -0700 Subject: [plasma] FW: New Version Notification for draft-freeman-plasma-requirements-02.txt X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime $plasma$ bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 20:43:01 -0000 Trevor is having issues sending to the list, so some of you might have = missed seeing that a new version of this document has been published. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 06, 2012 1:43 PM > To: trevorf@microsoft.com > Cc: ppatterson@carillon.ca; ietf@augustcellars.com > Subject: New Version Notification for = draft-freeman-plasma-requirements- > 02.txt >=20 >=20 > A new version of I-D, draft-freeman-plasma-requirements-02.txt > has been successfully submitted by Trevor Freeman and posted to the > IETF repository. >=20 > Filename: draft-freeman-plasma-requirements > Revision: 02 > Title: Requirements for Message Access Control > Creation date: 2012-07-06 > WG ID: Individual Submission > Number of pages: 53 > URL: = http://www.ietf.org/internet-drafts/draft-freeman-plasma- > requirements-02.txt > Status: http://datatracker.ietf.org/doc/draft-freeman-plasma- > requirements > Htmlized: http://tools.ietf.org/html/draft-freeman-plasma- > requirements-02 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-freeman-plasma- > requirements-02 >=20 > Abstract: > There are many situations where organizations want to protect > information with robust access control, either for implementation = of > intellectual property right protections, enforcement of contractual > confidentiality agreements or because of legal regulations. The > Enhanced Security Services (ESS) for S/MIME defines an access = control > mechanism which is enforced by the recipient's client after > decryption of the message. The ESS mechanism therefore is dependent > on the correct access policy configuration of every recipient's > client. This mechanism also provides full access to the data to all > recipients prior to the access control check, this is considered to > be inadequate due to the difficulty in demonstrating policy > compliance. >=20 > This document lays out the deficiencies of the current ESS security > label, and presents requirements for a new model for = doing/providing > access control to messages where the access check is performed = prior > to message content decryption. This new model also does not require > policy configuration on the client to simplify deployment and > compliance verification. >=20 > The proposed model additionally provides a method where non-X.509 > certificate credentials can be used for encryption/decryption of > S/MIME messages. >=20 >=20 >=20 >=20 > The IETF Secretariat From ppatterson@carillon.ca Wed Jul 25 08:08:28 2012 Return-Path: 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 3C62221F84FB for ; Wed, 25 Jul 2012 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 irqCh1Z6+ENl for ; Wed, 25 Jul 2012 08:08:27 -0700 (PDT) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id DD03421F845F for ; Wed, 25 Jul 2012 08:08:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 45B3DA81131; Wed, 25 Jul 2012 11:08:27 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTINj0krgfKJ; Wed, 25 Jul 2012 11:08:26 -0400 (EDT) Received: from [192.168.6.146] (modemcable198.19-37-24.static.videotron.ca [24.37.19.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 4282CA8053D; Wed, 25 Jul 2012 11:08:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Patrick Patterson In-Reply-To: Date: Wed, 25 Jul 2012 11:08:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <537BA3FC-2FCC-4C6F-95E9-D49A4997FABD@carillon.ca> References: To: Jean-Paul Buu-Sao X-Mailer: Apple Mail (2.1084) Cc: plasma@ietf.org Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:08:28 -0000 The following message has been forwarded from Trevor, as he is still = having difficulties posting to the list: ----- BEGIN FORWARDED MESSAGE ----- Hi Jean-Paul, Just catching up from Holiday. I have just posted a new draft of the requirements doc you may want to = check out. We have has a lot of feedback on our terminology so this new = draft has attempted to improve that area. We have changed PEP to be a Decision Requestor to more clearly indicate = it does not enforce decisions. We did not adopt the Access Requestor = name from the XACML model as we have other types of decisions such as = integrity policy decision requests. PDP has changed to Policy Decision and Enforcement Point to emphasize in = the Plasma model these functions are logically one. That does not = preclude implementations from implementing them as separate entities but = that implementations detail would not impact Plasma. You should also read the technical drafts from the implantation details. http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ More inline below Trevor -----Original Message----- From: plasma-bounces@ietf.org = [mailto:plasma-bounces@ietf.org] = On Behalf Of Jean-Paul Buu-Sao Sent: Monday, July 23, 2012 1:25 AM To: plasma@ietf.org Subject: [plasma] Comments on Message Access Control Requirements Draft 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. [TF] Good Point will add this to the draft 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? [TF] If you read the plasma service draft you will see we use a URI. We = believe that has sufficient flexibility to address the requirements you = describe. 2) Closed versus Open environment Section 4.4: "(A) The PEP verifies the certificate in the signed metadata then = determines <> 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 <>. 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. [TF] Since the PAP authors the policies and creates the policy = reference, I don't understand a client can have a policy reference that = a PAP does not know about so can you describe how this would occur. There are a logical sequence of PDEPs in Plasma. These can be physically = the same PDEP or they can be separate PDEPs. * The PDEP which generates the role token * The PDEP which generates the message token * The PDEP which generates the read token Only the first PDEP needs prior knowledge of the policies which is = necessary for it to generate the policy collection in the role token. = All subsequent PDEPs can use the URI to discover the policies. 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 <>. <>." [TF] The text was not intended to indicate only simple logical = relationships would be expressed so I will change to say "AND and/or = ORed together in an arbitrary combination". The technical draft uses a = logic trees so already supports what you describe. TSCP mandates a support for "advances policies". [TF] I understand some communities of interest would require use of = Advances Polices. However I don't want to burden every Plasma client = implementation to support such policies. The basic policy set is aimed a = simple set of scenarios where the Plasma client may well be bundled in = at no charge so any additional complexity would be a tax. A premium = client which supports advanced polices can then be purchased where there = is business value in doing so e.g. a mandate from a community of = interest such as TSCP. 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)? [TF] For the requirements I intend to be language neutral. We do intend = to address PDAP-PAP interaction in a subsequent technical paper where = the topic will have to be addressed. Some communities of interest have = made significant investments in XACML but it has not been universally = adopted so plasma has a tradeoff between mandating a specific language = to improve interoperability and alienating communities to do not use = XACML. I don't know the right answer at this time but that answer does = not impact the current work. We do need to support language negotiation = between PDEP and PAP so at a minimum so we can support communities of = interest and also be forwards compatible. 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 ---- END FORWARDED MESSAGE ----- --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 From Richard.Skedd@baesystems.com Fri Jul 27 02:34:53 2012 Return-Path: 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 049B721F85F6 for ; Fri, 27 Jul 2012 02:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] 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 Ix5z7n6I1ZXK for ; Fri, 27 Jul 2012 02:34:51 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6F89621F85F2 for ; Fri, 27 Jul 2012 02:34:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,666,1336345200"; d="p7s'?scan'208";a="259460351" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Jul 2012 10:34:49 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q6R9YlGw029603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Jul 2012 10:34:49 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Fri, 27 Jul 2012 10:34:48 +0100 From: "Skedd, Richard (UK)" To: "plasma@ietf.org" Thread-Topic: Basic and Advanced Policies Thread-Index: Ac1qfYzEE77XKwr7QLmya2XkWVhuzA== Date: Fri, 27 Jul 2012 09:34:47 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0041_01CD6BE3.713A8060" MIME-Version: 1.0 Subject: [plasma] Basic and Advanced Policies X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime $plasma$ bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:34:53 -0000 ------=_NextPart_000_0041_01CD6BE3.713A8060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A follow-up on comments by Trevor Freeman, kindly forwarded by Patrick Patterson, and Jean-Paul Buu-Sao on the requirements for Basic v Advanced Policies and the update of have draft-freeman-plasma-requirements-02 which now states that: 4.6.1 Basic Policy Basic policy is intended to be universally usable by using a small fixed set of attributes. For example, basic policy is intended to be equivalent to sending encrypted Email with S/MIME today. It is a simple policy that authenticated recipients of the Email get access to the message. Its intended target is simple scenarios involving consumers and small businesses who are using public PIP which issue a limited set of attributes. It is expected that all Plasma clients and commercial IdP would be capable of supporting basic policy due to their simplicity and basic attribute set. 4.6.2 Advanced Policy 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. In my view the terminology proposed does not reflect the capabilities described nor do the capabilities described align with typical use cases. If the intent of the "Basic Policy" is actually to replicate S/MIME functionality then it is an "Object Access Control List Policy". The mechanism of S/MIME combined with the list of addressees effectively limits access to the addressees but without originator control over further use of the content by the addressees. This is a valuable approach as it deals with the "Personal to Addressee" and similar use cases by giving the originator bespoke control over distribution. However, it does not involve a "Basic Policy" as a new policy with a unique ACL will need to be generated for every message. If the intent of the "Basic Policy" is to address " simple scenarios involving consumers and small businesses who are using public PIPs which issue a limited set of attributes" then this must require the ability to create rules which include logical operators (AND, OR etc) to process the attributes. eg "Customer for Product X AND Customer for Product Y", "Customer for Product X OR Retailer of Product X". This is effectively addressing the requirements of an object linked to a "Single Policy" rather than a "Basic Policy". Dealing with "Single Policies" rather than multiple policies would then be consistent with the statement that "Advanced Policy is intended to be used where one or more arbitrary policies are required on the content". Which raises a further question, is the ability to cope with content which references multiple policies an optional capability? The paper refers to a e-mail thread in which the addition of information also adds additional policies. Surely this scenario occurs everywhere all the time. Any request response scenario could involve data that is sensitive to each party eg "Can you quote to supply X, My price for X is $$$" or "Can you come to a meeting about X, No because I need to do Y". It thus seems to me that whilst there are different policy usage scenarios (Bespoke, Single, Multiple) these must all be core PLASMA capabilities supported by all PLASMA clients rather than add-ons for specialist applications by some communities of interest. Regards Richard Skedd Strategy Manager - Office of the CIO T: +44 117 918 8034 (vnet 7658 8034) M: +44 780 171 8260 (vnet 777118260) BAE Systems plc Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in England & Wales No: 1470151 -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Patrick Patterson Sent: 25 July 2012 16:08 To: Jean-Paul Buu-Sao Cc: plasma@ietf.org Subject: Re: [plasma] Comments on Message Access Control Requirements Draft ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- The following message has been forwarded from Trevor, as he is still having difficulties posting to the list: ----- BEGIN FORWARDED MESSAGE ----- Hi Jean-Paul, Just catching up from Holiday. I have just posted a new draft of the requirements doc you may want to check out. We have has a lot of feedback on our terminology so this new draft has attempted to improve that area. We have changed PEP to be a Decision Requestor to more clearly indicate it does not enforce decisions. We did not adopt the Access Requestor name from the XACML model as we have other types of decisions such as integrity policy decision requests. PDP has changed to Policy Decision and Enforcement Point to emphasize in the Plasma model these functions are logically one. That does not preclude implementations from implementing them as separate entities but that implementations detail would not impact Plasma. You should also read the technical drafts from the implantation details. http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ More inline below Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Jean-Paul Buu-Sao Sent: Monday, July 23, 2012 1:25 AM To: plasma@ietf.org Subject: [plasma] Comments on Message Access Control Requirements Draft 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. [TF] Good Point will add this to the draft 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? [TF] If you read the plasma service draft you will see we use a URI. We believe that has sufficient flexibility to address the requirements you describe. 2) Closed versus Open environment Section 4.4: "(A) The PEP verifies the certificate in the signed metadata then determines <> 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 <>. 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. [TF] Since the PAP authors the policies and creates the policy reference, I don't understand a client can have a policy reference that a PAP does not know about so can you describe how this would occur. There are a logical sequence of PDEPs in Plasma. These can be physically the same PDEP or they can be separate PDEPs. * The PDEP which generates the role token * The PDEP which generates the message token * The PDEP which generates the read token Only the first PDEP needs prior knowledge of the policies which is necessary for it to generate the policy collection in the role token. All subsequent PDEPs can use the URI to discover the policies. 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 <>. <>." [TF] The text was not intended to indicate only simple logical relationships would be expressed so I will change to say "AND and/or ORed together in an arbitrary combination". The technical draft uses a logic trees so already supports what you describe. TSCP mandates a support for "advances policies". [TF] I understand some communities of interest would require use of Advances Polices. However I don't want to burden every Plasma client implementation to support such policies. The basic policy set is aimed a simple set of scenarios where the Plasma client may well be bundled in at no charge so any additional complexity would be a tax. A premium client which supports advanced polices can then be purchased where there is business value in doing so e.g. a mandate from a community of interest such as TSCP. 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)? [TF] For the requirements I intend to be language neutral. We do intend to address PDAP-PAP interaction in a subsequent technical paper where the topic will have to be addressed. Some communities of interest have made significant investments in XACML but it has not been universally adopted so plasma has a tradeoff between mandating a specific language to improve interoperability and alienating communities to do not use XACML. I don't know the right answer at this time but that answer does not impact the current work. We do need to support language negotiation between PDEP and PAP so at a minimum so we can support communities of interest and also be forwards compatible. 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 ---- END FORWARDED MESSAGE ----- --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma ------=_NextPart_000_0041_01CD6BE3.713A8060 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIugDCCA6Ew ggKJoAMCAQICECk2R6rjiqyGSiNW8sq3Ya8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCdXMx GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsGA1UECxMERkJDQTEWMBQGA1UEAxMNQ29tbW9u IFBvbGljeTAeFw0wNzEwMTUxNTU4MDBaFw0yNzEwMTUxNjA4MDBaME4xCzAJBgNVBAYTAnVzMRgw FgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBEZCQ0ExFjAUBgNVBAMTDUNvbW1vbiBQ b2xpY3kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXjb0zJ+StW/t4vS9HR27HeOmT nKTeyRz9Lxs5OKxHF8B+dykAOwMfaA/NTaXud7gsYmsx9vpyCX0wKQZ853yjPYQYih2uLJKoH+he T42O6z8a+JwKZ52wZ03wLtAw3sOUsKDPLgo0f1QJ0za9pElXUnPpnf7kSHlGG1uNMuSlSGTzIg2S nQgVv2A8g/dHIiUirSlxt3fvF8mitpReyDCQpBRIXFZXC0FMBdQqTD+uEptZEXVwByJpLSzTMcyS fszNpH6UR6qcCQj2S69S6GpAkcVVvUCxyG1XhpUX5h9zvkcuPotMF7m5JRylUhc2CFnAQr4KK7RW UTwbVcmMkHfrAgMBAAGjezB5MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBQvWJfYqQWYpVYf+9mrde8CPDY0xzASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcV AgQWBBR2t2CW3RRWKax1hdNwY8G8R4YcizANBgkqhkiG9w0BAQUFAAOCAQEAYK7zSBZAcqYIiMm8 RywkS12gkXPtZXiQ8GeQeqW/Cq22KvmZZ9+DxXcfNAk4+X6eQeBIYP7iql2HiOqI/VxFsslq2n2k rbFPvxwNnx6awNUUczgrinhAbjD3YuHNmfxRaWdsEd24EKNo3ialVv02bDeYbPvufDxsa3A/90g3 CY8LQoGtRka4C4MG9Bs4oH9PzQvvg4mHlxyKMGfc/VShA34By4VMsQspw77sfOE/DwlSPC+nmkj+ N+kRBljhNkGKxLa/jt3OSrO8GsDN+hqZ0nGb+s+88sRUo4g1dswbLEZvDLTRw2F2knQR6kuAjRyJ EYvsW/8XyUj85+AGEeKEXjCCBo4wggV2oAMCAQICEEdoCdF50xtCM6sJ63YUtmgwDQYJKoZIhvcN AQEFBQAwZzELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUNlcnRpUGF0aCBMTEMxIjAgBgNVBAsTGUNl cnRpZmljYXRpb24gQXV0aG9yaXRpZXMxHDAaBgNVBAMTE0NlcnRpUGF0aCBCcmlkZ2UgQ0EwHhcN MTIwNTIyMDAwMDAwWhcNMTMwNTI2MjM1OTU5WjB+MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRXhv c3RhciBMTEMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxNTAzBgNVBAMTLEV4 b3N0YXIgRmVkZXJhdGVkIElkZW50aXR5IFNlcnZpY2UgUm9vdCBDQSAxMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvpqr+7HoMvGr/7nVeA7AbnZkezNe8SiIzIhmDxgyJZ1aOGz1C+Bu /FYpwKmFr66OKSPquiZyJlHbD0O4gZZgtwuERnSbGei1L5BmKCxuRv1IdhCI7MgfCbsi3W3pvFa6 EOrnUEf4WhR3Mrvgfr9ZgdmY0OP/gE9L+Xnw/RNZ3ZZ6qS0WEs8XijUi6SVWzJJsLDAX51hZ3d+m +RWE09nb0ygGxc4KzRcrmKKqn7Fs6iWoHDe4HOamLhFMamM7dljN3wSaSom/T1Sz+Q+W8AZuI3mo xQUeTNoOYDH9HB/c7bfiumpgPooInQDNyrypO/jopsQWRrKfH1Tn9VHrjbCGIQIDAQABo4IDHTCC AxkwHQYDVR0OBBYEFC6+kaZ3ajc89f0dtt14yabl9CIgMBIGA1UdEwEB/wQIMAYBAf8CAQEwKQYD VR0gBCIwIDAOBgwrBgEEAYG7UwEBAREwDgYMKwYBBAGBu1MBAQESMIH0BgNVHR8Egewwgekwgeag geOggeCGQ2h0dHA6Ly9jZXJ0aXBhdGgtY3JsLnZlcmlzaWduLmNvbS9DZXJ0aVBhdGhMTENDZXJ0 aVBhdGhCcmlkZ2VDQS5jcmyGgZhsZGFwOi8vY2VydGlwYXRoLWNybC1sZGFwLnZlcmlzaWduLmNv bS9DTj1DZXJ0aVBhdGglMjBCcmlkZ2UlMjBDQSxPVT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRp ZXMsTz1DZXJ0aVBhdGglMjBMTEMsQz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFy eTAOBgNVHQ8BAf8EBAMCAcYwCgYDVR02BAMCAQAwDAYDVR0kBAUwA4EBADCCARMGCCsGAQUFBwEB BIIBBTCCAQEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZXJ0aXBhdGgtYWlhLnZlcmlzaWduLmNvbS9D ZXJ0aVBhdGhCcmlkZ2VSb290Q0EucDdjMIG1BggrBgEFBQcwAoaBqGxkYXA6Ly9jZXJ0aXBhdGgt YWlhLWxkYXAudmVyaXNpZ24uY29tL0NOPUNlcnRpUGF0aCUyMEJyaWRnZSUyMENBLE9VPUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxPPUNlcnRpUGF0aCUyMExMQyxDPVVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFyeTBgBgNVHSEEWTBXMBsGDCsGAQQB gbtTAQEBEQYLKwYBBAHsfAEBAQEwGwYMKwYBBAGBu1MBAQESBgsrBgEEAex8AQEBAjAbBgwrBgEE AYG7UwEBAREGCysGAQQB7HwBAQECMB8GA1UdIwQYMBaAFDUfQeq/kXbBZ6AGGRuA9AbROZPcMA0G CSqGSIb3DQEBBQUAA4IBAQAolComnnxtfpCXVGP1t/pUKZhE51lf7pH01NXxmkorRw0G+BighopM ymnTszXLbe1F/1xQAIjA+LE/j8NvtKABkXPGj0xye6e+kZDYNiUXSctOgXH5/jEgzMvtospBlYP1 jrfYy4t4PJI9hYNazn8Qe3bh59bpFNzLH5Qo+pzAQE6D+dH+/sOb7QH6ERuJ984W8HaYK77z1Y1J WAZ8tCGiFanUKF9gHZzEtpZVKWnHKE1yVE1APXPnYvPCkgs1AkgznWv82zCFhlrxU8cu2uRRUBvE OeOelIJ27WF1WQxcScDAnwgOEo+mNyyMLA4EAGPTMlNR6NZvS0Jvi6xWSIhuMIIGmDCCBYCgAwIB AgIKYVo34gAAAAAAAjANBgkqhkiG9w0BAQUFADB+MQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRXhv c3RhciBMTEMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxNTAzBgNVBAMTLEV4 b3N0YXIgRmVkZXJhdGVkIElkZW50aXR5IFNlcnZpY2UgUm9vdCBDQSAxMB4XDTEwMDUxMDIxMDc1 M1oXDTE2MDUxMDIxMDc1M1owajETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkW CWV2aW5jaWJsZTE4MDYGA1UEAxMvRXhvc3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2VydmljZSBT aWduaW5nIENBIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/1hJ0xVzCnh+QSeHe 9l7AFTQ+tmbcjd2nLoKO7aCBmlPfbwsfEsr6pvUKAJBN1mNfZha+ei2IXz21xmcqd6WboUDNmcBZ 3SlubAn6tl5RGA7avBgV5FiZH0wo8UQOvM6jfLWJAsD1+CGKJWHCwf1Fdse8RQts2VQHveGS1RqR qa6JJJXS7mc6LcZPToTv/oQN3pQ0dlS22E8Eax00ugUiCRV37bsZwMRXdxQmRUyKAtRjbZAJzYxC Mk7gUoKyRFuEQMvBKjW/+Zd0O67/QmfLyjSKGvsPhkd1z+x04TRkSiU8xsKsTHU6lmc2gQNbLD0/ DXA94GUQxXSzbuKiwsJ3AgMBAAGjggMqMIIDJjAdBgNVHQ4EFgQUSivAqriQrio/AlNBuaNsePS1 qaUwDgYDVR0PAQH/BAQDAgHGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAULr6Rpndq Nzz1/R223XjJpuX0IiAwggEwBgNVHR8EggEnMIIBIzCCAR+gggEboIIBF4ZkaHR0cDovL3d3dy5m aXMuZXZpbmNpYmxlLmNvbS9maXMvcHVibGljL0V4b3N0YXIlMjBGZWRlcmF0ZWQlMjBJZGVudGl0 eSUyMFNlcnZpY2UlMjBSb290JTIwQ0ElMjAxLmNybIaBrmxkYXA6Ly9sZGFwLmZpcy5ldmluY2li bGUuY29tL0NOPUV4b3N0YXIlMjBGZWRlcmF0ZWQlMjBJZGVudGl0eSUyMFNlcnZpY2UlMjBSb290 JTIwQ0ElMjAxLE9VPUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxPPUV4b3N0YXIlMjBMTEMs Qz11cz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCCAVIGCCsGAQUFBwEBBIIBRDCC AUAwcAYIKwYBBQUHMAKGZGh0dHA6Ly93d3cuZmlzLmV2aW5jaWJsZS5jb20vZmlzL3B1YmxpYy9F eG9zdGFyJTIwRmVkZXJhdGVkJTIwSWRlbnRpdHklMjBTZXJ2aWNlJTIwUm9vdCUyMENBJTIwMS5w N2MwgcsGCCsGAQUFBzAChoG+bGRhcDovL2xkYXAuZmlzLmV2aW5jaWJsZS5jb20vQ049RXhvc3Rh ciUyMEZlZGVyYXRlZCUyMElkZW50aXR5JTIwU2VydmljZSUyMFJvb3QlMjBDQSUyMDEsT1U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLE89RXhvc3RhciUyMExMQyxDPVVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFyeTA2BgNVHSAELzAtMA0GCysGAQQB 7HwBAQEHMA0GCysGAQQB7HwBAQEBMA0GCysGAQQB7HwBAQECMA0GCSqGSIb3DQEBBQUAA4IBAQC8 3plzCwHwddOvLmgkDw7hle/oGni2ktAv0DMFkuCc1EWtb5KfRDencQ1VP6eO2UhkK31vhYSnwqXR vlCk/ApjxJWzsz2vpT2YM+wYj/suFgHKm0kEfK2a6dtITDMLkIjNwZhl85h4K3gsoWzvwKXEeLFW OcuXv5oAdtl/Vk3yfT7sAJiPH1+7k0RLHJIsTuB5OyAnlElEdmzBYwFKrDgApy8B5i0gXmmC8kxm c7hyeI+ZbrLTDQ5hMejwLpOhr/JeEXABMbcDclVVCBkuNg1MwtCGhOoXG7+hlELTDOeOtnn6gbxb tYMaYHR7rp8t7k623ALN7IXHi4TjGBNdieFCMIIHIDCCBgigAwIBAgICAmIwDQYJKoZIhvcNAQEF BQAwVjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsGA1UECxMERlBL STEeMBwGA1UEAxMVU0hBLTEgRmVkZXJhbCBSb290IENBMB4XDTExMDMwNDE2MzU0OFoXDTE0MDEw MTA0NTk1OVowZzELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUNlcnRpUGF0aCBMTEMxIjAgBgNVBAsT GUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxHDAaBgNVBAMTE0NlcnRpUGF0aCBCcmlkZ2UgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPiZi47tHyfnuERAKvXS2FWJ/cpayh91jf 7uxZbgA/VxgRx4zRmMM2oPokGdUDHDQEqtnI8qDWPKOeJ3wIx890sRVT7wPNfsZFeJT+QTaD0X0e PqOlw2RrjmfSmWpPvwMSUc+rBybGgIJ5FoO8o5JoxHxuaNTZQ8yYs4RpinqyNow8bIzuYDOR0xGx 4LLnDC7a24KCCPHH3iySyUCzR3a7DBJlN01Q6bW/aQCUE4NZmiqckeh1rZk3ioTQJlrMl2N6atNd SYsajKVGy0WISwkMVpdisCFcvfmg3It8I1IKmy9lrqHzOV10EBKk/naJdaI48LCONG8tNB4oLJQ4 vAmdAgMBAAGjggPlMIID4TAPBgNVHRMBAf8EBTADAQH/MIHsBggrBgEFBQcBAQSB3zCB3DBFBggr BgEFBQcwAoY5aHR0cDovL2h0dHAuZnBraS5nb3Yvc2hhMWZyY2EvY2FDZXJ0c0lzc3VlZFRvc2hh MWZyY2EucDdjMIGSBggrBgEFBQcwAoaBhWxkYXA6Ly9sZGFwLmZwa2kuZ292L2NuPVNIQS0xJTIw RmVkZXJhbCUyMFJvb3QlMjBDQSxvdT1GUEtJLG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9jQUNl cnRpZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwgbMGA1UdIQSBqzCB qDAaBgpghkgBZQMCAQMXBgwrBgEEAYG7UwEBAREwGgYKYIZIAWUDAgEDGAYMKwYBBAGBu1MBAQES MBoGCmCGSAFlAwIBAxkGDCsGAQQBgbtTAQEBETAaBgpghkgBZQMCAQMVBgwrBgEEAYG7UwEBARQw GgYKYIZIAWUDAgEDFgYMKwYBBAGBu1MBAQEVMBoGCmCGSAFlAwIBAxgGDCsGAQQBgbtTAQEBEzBx BgNVHR4BAf8EZzBloWMwK6QpMCcxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQwGaQXMBUxEzARBgoJkiaJk/IsZAEZFgNtaWwwGaQXMBUxEzARBgoJkiaJk/IsZAEZFgNnb3Yw TwYDVR0gBEgwRjAMBgpghkgBZQMCAQMXMAwGCmCGSAFlAwIBAxgwDAYKYIZIAWUDAgEDGTAMBgpg hkgBZQMCAQMVMAwGCmCGSAFlAwIBAxYwVwYIKwYBBQUHAQsESzBJMEcGCCsGAQUFBzAFhjtodHRw Oi8vY2VydGlwYXRoLWFpYS52ZXJpc2lnbi5jb20vQ2VydGlQYXRoQnJpZGdlUm9vdENBLnA3YzAO BgNVHQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUhppcYv9zk9Xhin9Kxogun26grhIwgbsGA1UdHwSB szCBsDAwoC6gLIYqaHR0cDovL2h0dHAuZnBraS5nb3Yvc2hhMWZyY2Evc2hhMWZyY2EuY3JsMHyg eqB4hnZsZGFwOi8vbGRhcC5mcGtpLmdvdi9jbiUzZFNIQS0xJTIwRmVkZXJhbCUyMFJvb3QlMjBD QSxvdSUzZEZQS0ksbyUzZFUuUy4lMjBHb3Zlcm5tZW50LGMlM2RVUz9jZXJ0aWZpY2F0ZVJldm9j YXRpb25MaXN0MB0GA1UdDgQWBBQ1H0Hqv5F2wWegBhkbgPQG0TmT3DANBgkqhkiG9w0BAQUFAAOC AQEACNSeOTGdQVxZzLpRTu8WyrDrH4R81Nms3z6ir3dkItpARoWmJqIomES5eNF26zVXJpGcr58I lGrfOmHDNUwsW0lof0pG32i3nLrL8HcUttsn1jv/nVHCbUr0B/w3AgfPNrQFs4M6anFS88cWtCR3 wTq6GrS/Zum1ANU/OEDiCIn1/XstAiR6OfpqK28pquIQFInfRzbGg1RVqPsTZW+1GUg54L08ebD9 wVkCApRMoVh0EsmdkYgL3BwkCMzZo7XtTjZd2Fsgaf/GGUtYY4LuR7TPF2YT8GvXatPYka8zeycL mzvIbl9oVv78mUZT+VpS8NnPgfoyvhXczXe3GxAMvzCCB14wggZGoAMCAQICCjSzdbEAAQAAAHow DQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCdXMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEN MAsGA1UECxMERkJDQTEWMBQGA1UEAxMNQ29tbW9uIFBvbGljeTAeFw0xMTAyMDcyMTUxMzBaFw0x MzEyMzEyMjAxMzBaMFYxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTAL BgNVBAsTBEZQS0kxHjAcBgNVBAMTFVNIQS0xIEZlZGVyYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAKcHngU6XH6x/7CZErplcj7DMj6PigVMMvgxFbqAOfNmYHiut+iO /mr1YFNkMy7mM0DJISPfarEzTnFO8fxy5K6RmSrBKZqNdP+xMjkCcgmbZcgHEa+yOLXGjv2wGMHq EZ0pZI8oMDjpSBR2HEeT7JZAwcpZhVEMVz+74cLEejsKGftglotlbuUpPcA5V7cArhGuqQeF43I4 6bpuMwFQy9S/p0HEP5t4/AGYkfPoLIgiaCLPlEoUWHlDlepAmpCEet1nEwCVSTCUsoUpkKdovX72 NmjTx/mUMVP7ItIrHJKu19ovFX4MY6Dd26VMeILjQ91YgxzD/m5vgfILs2VUkE8CAwEAAaOCBDQw ggQwMA8GA1UdEwEB/wQFMAMBAf8wgewGCCsGAQUFBwELBIHfMIHcMIGSBggrBgEFBQcwBYaBhWxk YXA6Ly9sZGFwLmZwa2kuZ292L2NuPVNIQS0xJTIwRmVkZXJhbCUyMFJvb3QlMjBDQSxvdT1GUEtJ LG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9jQUNlcnRpZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRp ZmljYXRlUGFpcjtiaW5hcnkwRQYIKwYBBQUHMAWGOWh0dHA6Ly9odHRwLmZwa2kuZ292L3NoYTFm cmNhL2NhQ2VydHNJc3N1ZWRCeXNoYTFmcmNhLnA3YzALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFIaa XGL/c5PV4Yp/SsaILp9uoK4SMB8GA1UdIwQYMBaAFC9Yl9ipBZilVh/72at17wI8NjTHMIG5BgNV HR8EgbEwga4wgauggaiggaWGNWh0dHA6Ly9mcGtpYS5nc2EuZ292L0NvbW1vblBvbGljeS9Db21t b25Qb2xpY3koMSkuY3JshmxsZGFwOi8vZnBraWEuZ3NhLmdvdi9jbj1Db21tb24lMjBQb2xpY3ko MSksb3U9RkJDQSxvPVUuUy4lMjBHb3Zlcm5tZW50LGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9u TGlzdDtiaW5hcnkwgdwGCCsGAQUFBwEBBIHPMIHMMEIGCCsGAQUFBzAChjZodHRwOi8vZnBraWEu Z3NhLmdvdi9Db21tb25Qb2xpY3kvQ29tbW9uUG9saWN5Um9vdC5wN2MwgYUGCCsGAQUFBzAChnls ZGFwOi8vZnBraWEuZ3NhLmdvdi9jbj1Db21tb24lMjBQb2xpY3ksb3U9RkJDQSxvPVUuUy4lMjBH b3Zlcm5tZW50LGM9VVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnksY3Jvc3NDZXJ0aWZpY2F0ZVBhaXI7 YmluYXJ5MB0GCSsGAQQBgjcUAgQQHg4AQwByAG8AcwBzAEMAQTCCASUGA1UdIASCARwwggEYMAwG CmCGSAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYK YIZIAWUDAgEDEDAMBgpghkgBZQMCAQMRMAwGCmCGSAFlAwIBAwEwDAYKYIZIAWUDAgEDAjAMBgpg hkgBZQMCAQMOMAwGCmCGSAFlAwIBAw8wDAYKYIZIAWUDAgEDEjAMBgpghkgBZQMCAQMUMAwGCmCG SAFlAwIBAxMwDAYKYIZIAWUDAgEDFTAMBgpghkgBZQMCAQMXMAwGCmCGSAFlAwIBAxYwDAYKYIZI AWUDAgEDGDAMBgpghkgBZQMCAQMZMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzANBgkqhkiG 9w0BAQUFAAOCAQEAJ5tT/JRijc0JZUndvpMysINUwQU6tAkbDEF3WwuFp4ZtNavrmN/wE3zXjO3R fL7fhafysKSCYmpmSn0Aflxgbza6kRbGYD6gqcNTbLLh30hACXibM+yMlPdqjGdak3bqV5YmqmcW aVD4Bwmuog1/yuFe1qqa7XbixXVAP1DkWcHLof3JO5L5hVuluSe3nLgce/Al3GTYiB6RWlugzGFw 4R14LWj82jviyqTQEXDNBVpJNl6Dfn6AKvHiXWE63jSWe6cBfctdfK1ceZhn/BvGuUM1c20iV3JB GN2zwzemh0pvHcOJTRhwnc3OVVoGKgfGU42Sp6dIoLBLQoQVgHWo6TCCB3cwggZfoAMCAQICBz4A AAAAUoUwDQYJKoZIhvcNAQEFBQAwajETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixk ARkWCWV2aW5jaWJsZTE4MDYGA1UEAxMvRXhvc3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2Vydmlj ZSBTaWduaW5nIENBIDEwHhcNMTExMTE2MTYzODQ0WhcNMTQxMTE1MTYzODQ0WjBaMRMwEQYKCZIm iZPyLGQBGRYDQ09NMRowGAYKCZImiZPyLGQBGRYKQkFFU1lTVEVNUzEnMCUGA1UEAwweUmljaGFy ZCBTa2VkZF8wMzY2KEVuY3J5cHRpb24pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 0mTPKSarG6XBGzYAahGwNwO84HrVmO4jqwWuBZFi74kW/EQ0SJrqZE0JwXnpCp5hzwn7moYbbC4j sLldpxrs8SmiGHsrr2nntXGxypaMslUr4nuWfRYKIzJ8z7ikBblckNQA3xg1GeLgWwMVaL5CAnSf IlgYSYsxrPXHEADkfDgw8Nmt0GhW/NIszXqohdn/QUKFwy88s9w6fTuZDw7iHHVswRHBy1L8HEQ4 5TdomuPCts1WZSgAuMpKN1W7mspncByXV+7HOCmPZkvtQ3rXdiTvKWdXj8WXDJkd9svBxdf/5rCx qbgtFVIZJeU4HEkWNtgZlCEs5zIRDg70xTjwWwIDAQABo4IEMDCCBCwwDgYDVR0PAQH/BAQDAgQw MB0GA1UdDgQWBBTV3t1skQ6rFhqI0LrRWeKtQDT3RzBVBgNVHREETjBMgRxyaWNoYXJkLnNrZWRk QGJhZXN5c3RlbXMuY29toCwGCisGAQQBgjcUAgOgHgwccmljaGFyZC5za2VkZEBiYWVzeXN0ZW1z LmNvbTAfBgNVHSMEGDAWgBRKK8CquJCuKj8CU0G5o2x49LWppTCCAY8GA1UdHwSCAYYwggGCMIIB fqCCAXqgggF2hmdodHRwOi8vd3d3LmZpcy5ldmluY2libGUuY29tL2Zpcy9wdWJsaWMvRXhvc3Rh ciUyMEZlZGVyYXRlZCUyMElkZW50aXR5JTIwU2VydmljZSUyMFNpZ25pbmclMjBDQSUyMDEuY3Js hoIBCWxkYXA6Ly9sZGFwLmZpcy5ldmluY2libGUuY29tL0NOPUV4b3N0YXIlMjBGZWRlcmF0ZWQl MjBJZGVudGl0eSUyMFNlcnZpY2UlMjBTaWduaW5nJTIwQ0ElMjAxLENOPWF5c2NhMDJ2LENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPWZpcyxEQz1ldmluY2libGUsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggHFBggrBgEFBQcBAQSC AbcwggGzMHMGCCsGAQUFBzAChmdodHRwOi8vd3d3LmZpcy5ldmluY2libGUuY29tL2Zpcy9wdWJs aWMvRXhvc3RhciUyMEZlZGVyYXRlZCUyMElkZW50aXR5JTIwU2VydmljZSUyMFNpZ25pbmclMjBD QSUyMDEucDdjMIIBAAYIKwYBBQUHMAKGgfNsZGFwOi8vbGRhcC5maXMuZXZpbmNpYmxlLmNvbS9D Tj1FeG9zdGFyJTIwRmVkZXJhdGVkJTIwSWRlbnRpdHklMjBTZXJ2aWNlJTIwU2lnbmluZyUyMENB JTIwMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29u ZmlndXJhdGlvbixEQz1maXMsREM9ZXZpbmNpYmxlLERDPWNvbT9jQUNlcnRpZmljYXRlO2JpbmFy eT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwOAYIKwYBBQUHMAGGLGh0 dHA6Ly9vY3NwLmZpcy5ldmluY2libGUuY29tL29jc3AvcmVzcG9uZGVyMCcGA1UdIAQgMB4wDQYL KwYBBAHsfAEBAQEwDQYLKwYBBAHsfAEBAQcwDQYJKoZIhvcNAQEFBQADggEBALsK94122kQbU9lF 3/nfiS/UiAJqI1LKfilb9VR9fxa1qcc9HjvDYRBPkGGMd5r09YDbRa1eJ9M/UDDwDssF6nGL/+rg qvxYoNPH/857l7d4xSbdh6MCEs1OmJ+lvvPQAQNjtIysE4l6UAtAJLY0CnMkh86yAA6667TTjTXc 9moXMtZOjCy3fFT1WSYmFdn7A9zuJaEvqd4AnkpAFDVlG4y4WMhvGjU+Vqie11ByGOTyqtWiUcjE /pV90V9x7QMtQOhwUBX0CClnwY6pmddUkCKmZtCGTZ4H1Qed4QtJTLJVaBm2C1QTt80pbrSdF9id WZiOzySqxbYgCSNiocTvt4gwggeoMIIGkKADAgECAgc+AAAAAFKEMA0GCSqGSIb3DQEBBQUAMGox EzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFglldmluY2libGUxODA2BgNVBAMT L0V4b3N0YXIgRmVkZXJhdGVkIElkZW50aXR5IFNlcnZpY2UgU2lnbmluZyBDQSAxMB4XDTExMTEx NjE2Mzg0M1oXDTE0MTExNTE2Mzg0M1owWTETMBEGCgmSJomT8ixkARkWA0NPTTEaMBgGCgmSJomT 8ixkARkWCkJBRVNZU1RFTVMxJjAkBgNVBAMMHVJpY2hhcmQgU2tlZGRfMDM2NihTaWduYXR1cmUp MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4kSVXALvXaJmzVysMiU9koWZinw/rkH/ bQuDcolkmUeKCLgXL8IL+riHLyrs2X/PCrA5Ud5AzPupUnnC3Xibou1O+rCyu55EIi005wquIsNL w+eRzlnO9wvatrPtjmsCDJX1/2rLCxFCDIx5gCZYvJWSZEtndKlnFculGu9Sy9ogx7uIocCHvswE j5/D9/G9de+icF0dZ1ERdTfRw5P/dbOEBYupr1jZhPichW4nNh2U+a5ZP3QRXpyohAQk8gVA3nG1 zqcs6DOABUkIxo7Yk/Fp2bqR8OyI0l8+2JUliEU1dX76ksGxxm5frUCg/Mdi9f5XOQDApR/IXbaj C8OcVwIDAQABo4IEYjCCBF4wDgYDVR0PAQH/BAQDAgbAMB0GA1UdDgQWBBQeTYBy2qNz1rn45pdR ubqEoQuIcjBVBgNVHREETjBMgRxyaWNoYXJkLnNrZWRkQGJhZXN5c3RlbXMuY29toCwGCisGAQQB gjcUAgOgHgwccmljaGFyZC5za2VkZEBiYWVzeXN0ZW1zLmNvbTAfBgNVHSMEGDAWgBRKK8CquJCu Kj8CU0G5o2x49LWppTCCAY8GA1UdHwSCAYYwggGCMIIBfqCCAXqgggF2hmdodHRwOi8vd3d3LmZp cy5ldmluY2libGUuY29tL2Zpcy9wdWJsaWMvRXhvc3RhciUyMEZlZGVyYXRlZCUyMElkZW50aXR5 JTIwU2VydmljZSUyMFNpZ25pbmclMjBDQSUyMDEuY3JshoIBCWxkYXA6Ly9sZGFwLmZpcy5ldmlu Y2libGUuY29tL0NOPUV4b3N0YXIlMjBGZWRlcmF0ZWQlMjBJZGVudGl0eSUyMFNlcnZpY2UlMjBT aWduaW5nJTIwQ0ElMjAxLENOPWF5c2NhMDJ2LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2 aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZpcyxEQz1ldmluY2libGUsREM9 Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwggHFBggrBgEFBQcBAQSCAbcwggGzMHMGCCsGAQUFBzAChmdodHRw Oi8vd3d3LmZpcy5ldmluY2libGUuY29tL2Zpcy9wdWJsaWMvRXhvc3RhciUyMEZlZGVyYXRlZCUy MElkZW50aXR5JTIwU2VydmljZSUyMFNpZ25pbmclMjBDQSUyMDEucDdjMIIBAAYIKwYBBQUHMAKG gfNsZGFwOi8vbGRhcC5maXMuZXZpbmNpYmxlLmNvbS9DTj1FeG9zdGFyJTIwRmVkZXJhdGVkJTIw SWRlbnRpdHklMjBTZXJ2aWNlJTIwU2lnbmluZyUyMENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIw S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1maXMsREM9ZXZp bmNpYmxlLERDPWNvbT9jQUNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdENsYXNzPWNlcnRp ZmljYXRpb25BdXRob3JpdHkwOAYIKwYBBQUHMAGGLGh0dHA6Ly9vY3NwLmZpcy5ldmluY2libGUu Y29tL29jc3AvcmVzcG9uZGVyMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCcGA1UdIAQgMB4wDQYLKwYB BAHsfAEBAQEwDQYLKwYBBAHsfAEBAQcwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDANBgkq hkiG9w0BAQUFAAOCAQEAdLGohI12Dogt33ZG/F/+5gLw1dbrdStfhwgw/dAlcxDnr1F28QVgqZLa Jo6kaib0sSZow/AVMJmZcecshWThzq0TrpdhE8ztLOZf26MSqWrZToEwO6CKOROPxKfCZzAK40Hk Qsut4BSk+ODl82tLHd9LOCVPZ7RN+q9NmZtW/ECjdcF3s4UO2Qn+ndjG5g1PT67S2KnKxmdUya9l B3WZBMeQVHk0bI7/MY+mxSJir1r8RDEU9EQ7TZt2SQ/GnTzaA98zmF40sNxrnLF1s0XLM0BkVWTi km4VLEOflFMbpLEbyNdD2yIm2EGFidMNjj3McE1J8u7W6xVy8lXam0l/dzGCA2owggNmAgEBMHUw ajETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCWV2aW5jaWJsZTE4MDYGA1UE AxMvRXhvc3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2VydmljZSBTaWduaW5nIENBIDECBz4AAAAA UoQwCQYFKw4DAhoFAKCCAcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIwNzI3MDkzNDQ2WjAjBgkqhkiG9w0BCQQxFgQUbz0lPrLzWVXEn3tTv1/ItSK9mDEwWwYJ KoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowgYQGCSsGAQQBgjcQBDF3MHUwajETMBEG CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCWV2aW5jaWJsZTE4MDYGA1UEAxMvRXhv c3RhciBGZWRlcmF0ZWQgSWRlbnRpdHkgU2VydmljZSBTaWduaW5nIENBIDECBz4AAAAAUoUwgYYG CyqGSIb3DQEJEAILMXegdTBqMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ ZXZpbmNpYmxlMTgwNgYDVQQDEy9FeG9zdGFyIEZlZGVyYXRlZCBJZGVudGl0eSBTZXJ2aWNlIFNp Z25pbmcgQ0EgMQIHPgAAAABShTANBgkqhkiG9w0BAQEFAASCAQBTstfNJYBzm1/DdyPStOQ7OiY4 zczjqkM/fGzUFQ289jT2gCT1O2LN1EX6b0lCEsQuTRqnEa/XoTmhXPMOdbxvs/Dx5Rrh01fUJ6UK lrZn5X8ziMogU0RRoUbHFncPh2A5+Rvpan2W7VYM2oA5nItdsvONJna+hGeXHmhKVTK6PI4QjNRM DWWwUb8ourx+UL7QjIQNLqn0hokJoOK54q/FUb2lSiscuH6+1kQvCAGP1e8Dv49280CsEZO7S/+J L9R426oeENUn3JnXcWbGmIUYajmzJKXy8WAmxyd7dLBnDBLaE+YvSocTkAPYUkRsap8S55UdyZPC JDiBLp9jc2umAAAAAAAA ------=_NextPart_000_0041_01CD6BE3.713A8060-- From jean-paul.buu-sao@tscp.org Fri Jul 27 03:28:26 2012 Return-Path: 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 5D32021F8637 for ; Fri, 27 Jul 2012 03:28:26 -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 o0dlKRYUTVUg for ; Fri, 27 Jul 2012 03:28:25 -0700 (PDT) Received: from smtp184.iad.emailsrvr.com (smtp184.iad.emailsrvr.com [207.97.245.184]) by ietfa.amsl.com (Postfix) with ESMTP id E487A21F8631 for ; Fri, 27 Jul 2012 03:28:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 4D85EE03B2 for ; Fri, 27 Jul 2012 06:28:24 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex02.mlsrvr.com (smtp192.mex02.mlsrvr.com [204.232.137.43]) by smtp28.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTPS id 3A1B9E03A1 for ; Fri, 27 Jul 2012 06:28:24 -0400 (EDT) Received: from IAD2MBX12.mex02.mlsrvr.com ([172.23.11.89]) by IAD2HUB01.mex02.mlsrvr.com ([172.23.10.65]) with mapi; Fri, 27 Jul 2012 06:28:24 -0400 From: Jean-Paul Buu-Sao To: "plasma@ietf.org" Date: Fri, 27 Jul 2012 06:27:10 -0400 Thread-Topic: [plasma] Open-Environments Thread-Index: Ac1r4hLnx0xLfr9ARjCSuILVzpj/KQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.4152-7.000.1014-19066.004 x-tm-as-result: No--56.232600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [plasma] Open-Environments X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime $plasma$ bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 10:28:26 -0000 Thank you Patrick for forwarding the response from Trevor. Reading at them = I see that there is one remaining comment that needs discussion (given that= Richard Skedd has already created a thread on basic and Advanced Policies,= that I will not re-iterate here). This is the question of Open Environment= s. [JP] .... TSCP expected to see a workflow that could as well support an "op= en environment", whereas not all referenced policies are necessarily known = by the local PDP/PAP ahead of time. [TF] Since the PAP authors the policies and creates the policy reference, I= don't understand a client can have a policy reference that a PAP does not = know about so can you describe how this would occur. [JP] In earlier discussions that we had in TSCP forums, you pushed forward = the capability of PLASMA to operate in environments where not all policies = are known, which you called "open environments". In this context, what I me= ant by " ... not all referenced policies are necessarily known by the local= PDP/PAP ahead of time" is that the local PAP did not author such policy, w= hich was authored by a non-local (remote) PAP in a different domain. Is the= distinction between local PAP and remote PAP useful to the discussion? I t= hink it is, as this difference potentially implies a difference on the trus= t model. I believe that, in order to support open environments, a dedicated= trust model needs to be specified. Is it possible to discover a policy URI= , and dereference it, without ensuring of the trustworthiness of the source= ? Those are some of the issues that, IMO, need to be called out in the docu= ment. Thanks, JP -----Original Message----- From: Patrick Patterson [mailto:ppatterson@carillon.ca]=20 Sent: Wednesday, July 25, 2012 17:08 To: Jean-Paul Buu-Sao Cc: plasma@ietf.org Subject: Re: [plasma] Comments on Message Access Control Requirements Draft The following message has been forwarded from Trevor, as he is still having= difficulties posting to the list: ----- BEGIN FORWARDED MESSAGE ----- Hi Jean-Paul, Just catching up from Holiday. I have just posted a new draft of the requirements doc you may want to chec= k out. We have has a lot of feedback on our terminology so this new draft h= as attempted to improve that area. We have changed PEP to be a Decision Requestor to more clearly indicate it = does not enforce decisions. We did not adopt the Access Requestor name from= the XACML model as we have other types of decisions such as integrity poli= cy decision requests. PDP has changed to Policy Decision and Enforcement Point to emphasize in th= e Plasma model these functions are logically one. That does not preclude im= plementations from implementing them as separate entities but that implemen= tations detail would not impact Plasma. You should also read the technical drafts from the implantation details. http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ More inline below Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasm= a-bounces@ietf.org] On Behalf Of J= ean-Paul Buu-Sao Sent: Monday, July 23, 2012 1:25 AM To: plasma@ietf.org Subject: [plasma] Comments on Message Access Control Requirements Draft Greetings, Please find my comments on the PLASMA draft 01: http://tools.ietf.org/pdf/d= raft-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 assoc= iation 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 th= at 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 w= ith binding by value or by description. [TF] Good Point will add this to the draft The draft is silent on how the name would be expressed. Can it be any arbit= rary identifier, which precise syntax and semantics could be defined by a c= ommunity of interest defined profile? [TF] If you read the plasma service draft you will see we use a URI. We bel= ieve that has sufficient flexibility to address the requirements you descri= be. 2) Closed versus Open environment Section 4.4: "(A) The PEP verifies the certificate in the signed metadata then determine= s <> if it want to process the protected information base= d on the identity of the PDP (D) The PDP decrypts the metadata, de-references the policy pointers and de= termines the set of access rules based on the <>. The PDP then determines the set of subject attributes it needs to evalu= ate 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 miss= ing 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 a= ll referenced policies are necessarily known by the local PDP/PAP ahead of = time. [TF] Since the PAP authors the policies and creates the policy reference, I= don't understand a client can have a policy reference that a PAP does not = know about so can you describe how this would occur. There are a logical sequence of PDEPs in Plasma. These can be physically th= e same PDEP or they can be separate PDEPs. * The PDEP which generates the role token * The PDEP which generates the message token * The PDEP which generates the read token Only the first PDEP needs prior knowledge of the policies which is necessar= y for it to generate the policy collection in the role token. All subsequen= t PDEPs can use the URI to discover the policies. As a related topic, Policy Publication Point (PPP), lightly introduced in t= he Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. In= view of the support for "open environments", TSCP expected to see more req= uirements on PPP. 3) Advanced Policies Section 4.5.2: "Advanced policy is intended to be used where one or more a= rbitrary policies are required on the content. It is intended to target mor= e complex scenarios such as content with regulated information or content s= ubject to other organization and contractual policies. The input set of att= ributes 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 <>. <>." [TF] The text was not intended to indicate only simple logical relationship= s would be expressed so I will change to say "AND and/or ORed together in a= n arbitrary combination". The technical draft uses a logic trees so already= supports what you describe. TSCP mandates a support for "advances policies". [TF] I understand some communities of interest would require use of Advance= s Polices. However I don't want to burden every Plasma client implementatio= n to support such policies. The basic policy set is aimed a simple set of s= cenarios where the Plasma client may well be bundled in at no charge so any= additional complexity would be a tax. A premium client which supports adva= nced polices can then be purchased where there is business value in doing s= o e.g. a mandate from a community of interest such as TSCP. A typical example is to support documents that must be simultaneously prote= cted under an Export Control policy (e.g. ITAR Technical Assistance Agreeme= nt) and an Intellectual Property policy (e.g. Proprietary Information Excha= nge Agreement). In this case of multiple policies, TSCP requires that all t= he 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 Lan= guages. Is there one in particular that PLASMA mandates (if so, which one),= or is the specification agnostic (if so, what are the baseline requirement= s in terms of expressiveness)? [TF] For the requirements I intend to be language neutral. We do intend to = address PDAP-PAP interaction in a subsequent technical paper where the topi= c will have to be addressed. Some communities of interest have made signifi= cant investments in XACML but it has not been universally adopted so plasm= a has a tradeoff between mandating a specific language to improve interoper= ability and alienating communities to do not use XACML. I don't know the ri= ght answer at this time but that answer does not impact the current work. = We do need to support language negotiation between PDEP and PAP so at a min= imum so we can support communities of interest and also be forwards compati= ble. Some organizations have developed and validated a broad set of policies, ex= pressed 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 ---- END FORWARDED MESSAGE ----- --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 From ppatterson@carillon.ca Fri Jul 27 16:01:15 2012 Return-Path: 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 3F57711E80F2 for ; Fri, 27 Jul 2012 16:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 i3kBBZsXlnxM for ; Fri, 27 Jul 2012 16:01:14 -0700 (PDT) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id 59E5511E80C4 for ; Fri, 27 Jul 2012 16:01:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 28440A83FDF for ; Fri, 27 Jul 2012 19:01:17 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6fybs-5lfiJ for ; Fri, 27 Jul 2012 19:01:16 -0400 (EDT) Received: from [192.168.42.129] (modemcable197.107-19-135.mc.videotron.ca [135.19.107.197]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 7052AA80058 for ; Fri, 27 Jul 2012 19:01:16 -0400 (EDT) From: Patrick Patterson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jul 2012 19:01:12 -0400 References: To: plasma@ietf.org Message-Id: <31DE458B-4A7A-40B8-BE11-17D3B0CEA4D4@carillon.ca> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [plasma] Fwd: The PoLicy Augmented S/Mime $plasma$ bof discussion list X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime $plasma$ bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 23:01:15 -0000 =46rom Trevor: Begin forwarded message: > From: Trevor Freeman > Date: July 27, 2012 6:58:56 PM EDT > To: "Patrick Patterson [ppatterson@carillon.ca]" = > Subject: RE: The PoLicy Augmented S/Mime $plasma$ bof discussion = list >=20 >=20 > Hi Hal. >=20 >=20 >=20 > Thanks for the feedback. >=20 >=20 >=20 > The editorial comments (P4 & P7) seem straight forward I have = incorporated those in the 02 draft I just published. In that draft, I = also revised the ABAC definition in line with your comments. We had a = lot of feedback in Paris on the terminology\vocabulary and I have tried = to incorporate that in the new draft. >=20 > * We have changes the name of the Plasma client from a PEP to a = Decision Requestor. This is to more accurately reflect is does not = enforce decisions, and that Plasma supports many types of decision = types, not just access control. >=20 > * We have changes the PDP to be a Policy Decision and = Enforcement Point to reflect that in the Plasma model both functions are = in the single logical entity (this does not require they be implemented = as a single physical entity) >=20 > * We have changed policy set to policy collections to avoid = confusion with the XACML policy sets. In Plasma the policy collection is = used by clients as a means to manage what choices a client has for which = polies can be applied to a message. They don't play a part in the actual = decision itself. >=20 > * >=20 > You have a number of technical questions which I believe are answers = in the following Plasma documents. >=20 >=20 >=20 > http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ >=20 >=20 >=20 > http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ >=20 >=20 >=20 >=20 >=20 > I have added a new scenario for document integrity policy. Plasma is = intended as a general purpose policy enforcement mechanism, not just = access control. I have realized that while we talk about this point a = number of places, the language still assume just access policy so those = changes are causing a bigger ripple through the document as I try to = realign the terminology. >=20 >=20 >=20 > The current work is targeted as a means to make generic policy = decision requests so by design has no dependencies on any specific = language as we want to insulate the client from policy. We plan to = tackle the distribution of policy between the PDEP and PAP as a = subsequent work which is where much of the policy specific dependencies = will be called out. I will clarify the needs for standards in this area = in the generic requirements doc. I understand a lot of large customer = have invested in XACML so I don't doubt XACML will be part of the policy = distribution draft. >=20 >=20 >=20 > Thanks again for taking the time to review our work. >=20 > Trevor >=20 >=20 >=20 > In response to Requirements for Message Access Control = (http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf) the = OASIS XACML Technical Committee has agreed to submit the attached = comments. >=20 >=20 >=20 > The public link to this document is: >=20 >=20 >=20 > = https://www.oasis-open.org/committees/download.php/46049/Proposed%20respon= se%20to%20Plasma%20v1-3.docx >=20 >=20 >=20 > Hal Lockhart >=20 > Bill Parducci >=20 > Co-chairs OASIS XACML TC >=20 --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 From jimsch@nwlink.com Mon Jul 30 15:34:44 2012 Return-Path: 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 7B1E711E80A4 for ; Mon, 30 Jul 2012 15:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 XeKaD3qB356v for ; Mon, 30 Jul 2012 15:34:43 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9E11E809C for ; Mon, 30 Jul 2012 15:34:43 -0700 (PDT) Received: from Tobias (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 60BFE2C9C5; Mon, 30 Jul 2012 15:34:43 -0700 (PDT) From: "Jim Schaad" To: "'Alan Borland'" , References: In-Reply-To: Date: Mon, 30 Jul 2012 15:33:17 -0700 Message-ID: <00bc01cd6ea3$518dbb20$f4a93160$@nwlink.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01CD6E68.A5301BA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBSHVfCS46jvYtcH0EF1jjoC1EJJfatH2A Content-Language: en-us Subject: Re: [plasma] Who creates the 'keyIdentifier'? X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime $plasma$ bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:34:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BD_01CD6E68.A5301BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alan, Sorry for the delay on getting back with a fuller response on this issue. I managed to fall off of my stack of issues. The KeyIdentifier in the CMS KEKIdentifier field is generated by the client and populated by the client. The field originally was not sent to the Plasma server as it was not thought necessary. When doing implementations, for some reason I can no longer remember I thought it was necessary so added it to the schema without also putting in the documentation. Since that point I have gone back to the point of wondering if the field is needed or not. It may be that it is just local to the client and never needs to be sent to the server. Part of the issue is a question on the ability to have two different KEK objects in a single MIME message that is done over multiple CMS objects each with a different KEKIdentifier (or the same one). If this is the case then it might be needed, but it would also require a couple of other changes that I have not completely worked out yet. Jim From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Alan Borland Sent: Wednesday, July 18, 2012 1:32 AM To: plasma@ietf.org Subject: [plasma] Who creates the 'keyIdentifier'? I'm trying to understand who generates the 'KeyIdentifier' element in the 'KEKIdentifier' structure of the 'RecipientInfo' created by the client. Is it the client? The Plasma CMS Processing document, Page 8, describes how the 'KeyIdentifier' is a random generated value (Created by the client?). Is it the Plasma Server? On Page 13 the KekIdentifier is a value that matches the KEKIdentifier.KeyIdentifier value in the recipient info information (I have read this to mean that the EPS-LockBox version must match the KeyIdentifier in the envelopedData created by the client, meaning the KeyIdentifer must be transported between client and plasma server). >From this I thought the client created the random value and passed it across to the server inside the 'GetCMSToken' request. However, I can't see this described in the request. Is this missing from the request documentation, or does this Imply that the client has to extract the KeyIdentifer from the EPS-KEK returned in the GetCMSToken response, but this is encrypted and only the Plasma Server has access to this. Or have I mis-read this completely? Alan. Boldon James. ------=_NextPart_000_00BD_01CD6E68.A5301BA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan,

Sorry for the delay on getting back with a fuller response on this = issue. I managed to fall off of my stack of = issues.

The KeyIdentifier in the CMS KEKIdentifier field is generated by the = client and populated by the client. The field originally was not = sent to the Plasma server as it was not thought necessary. When = doing implementations, for some reason I can no longer remember I = thought it was necessary so added it to the schema without also putting = in the documentation.

Since that point I have gone back to the point of wondering if the = field is needed or not. It may be that it is just local to the = client and never needs to be sent to the server. Part of the issue = is a question on the ability to have two different KEK objects in a = single MIME message that is done over multiple CMS objects each with a = different KEKIdentifier (or the same one). If this is the case = then it might be needed, but it would also require a couple of other = changes that I have not completely worked out = yet.

Jim

I'm = trying to understand who generates the 'KeyIdentifier' element in = the 'KEKIdentifier' structure of the 'RecipientInfo' created by the = client.

Is it the client? The Plasma CMS Processing = document, Page 8, describes how the 'KeyIdentifier' is a random = generated value (Created by the client?). =

Alan.

Boldon = James.

------=_NextPart_000_00BD_01CD6E68.A5301BA0--